> You are suggesting that end_of_early_data and close_notify will be marked 
> "fatal".

Yes, technically they would have no alert level (since alert level is 
deprecated), but as far as bytes on the wire changes with this PR, that's 
correct.

> could you expand on why it's a problem?

Alert level is not conveying any additional information since there is one (and 
only one) alert level each alert type must be sent as. Having a separate field 
that does not convey additional information is only providing an opportunity 
for implementations to misuse it and create subtle bugs (for example if one 
implementation ignores warning level alerts, while another incorrectly sends 
alerts defined as fatal at warning level).

> This list is already missing the warning-level "unrecognized_name" alert, and 
> such a change would imply that all new/unrecognized alerts are going to be 
> treated as fatal forever (i.e. that no new warning-level alerts can ever be 
> defined).

That alert is currently defined as a fatal alert (see section 6.2 in the 
current draft). RFC 6066 also states "It is NOT RECOMMENDED to send a 
warning-level unrecognized_name(112) alert, because the client's behavior in 
response to warning-level alerts is unpredictable.", which I think illustrates 
the problem. Allowing new non-fatal alerts to be added later would require that 
existing clients ignore unknown warning alerts, which I think is somewhat 
dangerous.

-----Original Message-----
From: Martin Thomson [mailto:martin.thom...@gmail.com] 
Sent: Sunday, October 16, 2016 5:53 AM
To: Kyle Nekritz <knekr...@fb.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Deprecating alert levels

I'm sympathetic to this, but just to be clear...

You are suggesting that end_of_early_data and close_notify will be marked 
"fatal".

WFM.

On 15 October 2016 at 08:07, Kyle Nekritz <knekr...@fb.com> wrote:
> After PR #625 all alerts are required to be sent with fatal AlertLevel 
> except for close_notify, end_of_early_data, and user_canceled. Since 
> those three alerts all have separate specified behavior, the 
> AlertLevel field is not serving much purpose, other than providing 
> potential for misuse. We
> (Facebook) currently receive a number of alerts at incorrect levels 
> from clients (internal_error warning alerts, etc.). I propose 
> deprecating this field to simplify implementations and require that any 
> misuse be ignored.
>
>
>
> PR: https://github.com/tlswg/tls13-spec/pull/693
>
>
>
> Kyle
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_tls&d=DQIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2
> z7jPw&m=D6vgejwavMxoWSed2ANWwkecWIlc1MnHfgXfiejFS8Y&s=-fFwoxaS4TZXNkoZ
> M04oEUCKz283dy6QYRuhlOK0mQo&e=
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to