Re: [TLS] Deprecating alert levels

2016-10-26 Thread Olivier Levillain
Sent: Wednesday, October 19, 2016 10:18 PM > To: Eric Rescorla <e...@rtfm.com> > Cc: tls@ietf.org > Subject: Re: [TLS] Deprecating alert levels > > On 20 October 2016 at 05:28, Eric Rescorla <e...@rtfm.com> wrote: >>> 2. Are there cases, such as unrecogn

Re: [TLS] Deprecating alert levels

2016-10-24 Thread Kyle Nekritz
Rescorla <e...@rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] Deprecating alert levels On 20 October 2016 at 05:28, Eric Rescorla <e...@rtfm.com> wrote: >> 2. Are there cases, such as unrecognized name. where it is useful to >> indicate that an alert is not fatal? If

Re: [TLS] Deprecating alert levels

2016-10-19 Thread Martin Thomson
On 20 October 2016 at 13:18, Martin Thomson wrote: > In NSS is to tolerate it *(Learn to write fool) In NSS we tolerate warning alerts ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Deprecating alert levels

2016-10-19 Thread Martin Thomson
On 20 October 2016 at 05:28, Eric Rescorla wrote: >> 2. Are there cases, such as unrecognized name. where it is useful to >> indicate that an alert is not fatal? If so how should this case be handled? > > > I think this alert was a mistake :) In NSS is to tolerate it, but it's

Re: [TLS] Deprecating alert levels

2016-10-19 Thread Eric Rescorla
On Wed, Oct 19, 2016 at 11:24 AM, Joseph Salowey wrote: > It does not look like we have sufficient consensus to adopt this PR. > While there is some support for simplifying alerts by removing the alert > level, the current discussion raises some issues about the general >

Re: [TLS] Deprecating alert levels

2016-10-19 Thread Joseph Salowey
It does not look like we have sufficient consensus to adopt this PR. While there is some support for simplifying alerts by removing the alert level, the current discussion raises some issues about the general approach. 1. Is it appropriate for all unknown alerts to be treated as fatal? (the

Re: [TLS] Deprecating alert levels

2016-10-19 Thread Martin Rex
Kyle Nekritz wrote: > >> 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

Re: [TLS] Deprecating alert levels

2016-10-17 Thread Hubert Kario
On Monday, 17 October 2016 17:34:05 CEST Kyle Nekritz wrote: > Allowing new non-fatal alerts to be added later > would require that existing clients ignore unknown warning alerts, which I > think is somewhat dangerous. but the standard doesn't say that you need to ignore unknown warning level

Re: [TLS] Deprecating alert levels

2016-10-17 Thread Hubert Kario
On Monday, 17 October 2016 13:26:09 CEST Dave Garrett wrote: > On Monday, October 17, 2016 01:04:18 pm Martin Rex wrote: > > 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

Re: [TLS] Deprecating alert levels

2016-10-17 Thread Kyle Nekritz
s. -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

Re: [TLS] Deprecating alert levels

2016-10-17 Thread Dave Garrett
On Monday, October 17, 2016 01:04:18 pm Martin Rex wrote: > 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

Re: [TLS] Deprecating alert levels

2016-10-17 Thread Eric Rescorla
This would actually simplify our implementation slightly because then we would simply not look at the field at all, even for the closure alerts. -Ekr On Mon, Oct 17, 2016 at 12:19 PM, Hubert Kario wrote: > On Monday, 17 October 2016 11:11:43 CEST Benjamin Kaduk wrote: > >

Re: [TLS] Deprecating alert levels

2016-10-17 Thread Hubert Kario
On Monday, 17 October 2016 11:11:43 CEST Benjamin Kaduk wrote: > On 10/17/2016 06:20 AM, Hubert Kario wrote: > > On Friday, 14 October 2016 21:07:30 CEST Kyle Nekritz wrote: > >> After PR #625 all alerts are required to be sent with fatal AlertLevel > >> except for close_notify, end_of_early_data,

Re: [TLS] Deprecating alert levels

2016-10-17 Thread Benjamin Kaduk
On 10/17/2016 06:20 AM, Hubert Kario wrote: > On Friday, 14 October 2016 21:07:30 CEST Kyle Nekritz 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

Re: [TLS] Deprecating alert levels

2016-10-17 Thread Hubert Kario
On Friday, 14 October 2016 21:07:30 CEST Kyle Nekritz 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

Re: [TLS] Deprecating alert levels

2016-10-16 Thread Eric Rescorla
This seems like a good change. I'll merge this on Monday (pre draft-17) unless I hear objections On Sun, Oct 16, 2016 at 2:53 AM, Martin Thomson wrote: > I'm sympathetic to this, but just to be clear... > > You are suggesting that end_of_early_data and close_notify

Re: [TLS] Deprecating alert levels

2016-10-16 Thread Martin Thomson
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 wrote: > After PR #625 all alerts are required to be sent with fatal AlertLevel > except for

[TLS] Deprecating alert levels

2016-10-14 Thread Kyle Nekritz
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