Sent: Wednesday, October 19, 2016 10:18 PM
> To: Eric Rescorla
> Cc: tls@ietf.org
> Subject: Re: [TLS] Deprecating alert levels
>
> On 20 October 2016 at 05:28, Eric Rescorla wrote:
>>> 2. Are there cases, such as unrecognized name. where it is useful to
>>> in
Rescorla
Cc: tls@ietf.org
Subject: Re: [TLS] Deprecating alert levels
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?
>
&
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
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 an exception. I'
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
> approach.
>
> 1. Is it
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
curr
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 curren
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
ale
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 fa
ewhat
dangerous.
-Original Message-
From: Martin Thomson [mailto:martin.thom...@gmail.com]
Sent: Sunday, October 16, 2016 5:53 AM
To: Kyle Nekritz
Cc: tls@ietf.org
Subject: Re: [TLS] Deprecating alert levels
I'm sympathetic to this, but just to be clear...
You are suggesting that e
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 defi
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.
This list is already missing the warning-level "unrecognized_name" alert,
and such a change would imply that all new/unrecognized alerts a
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:
> > On 10/17/2016 06:20 A
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,
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 specif
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 servi
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 will be
> marked "fatal".
>
>
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 close_notify, end_of_ea
18 matches
Mail list logo
