Re: [TLS] Deprecating alert levels

2016-10-26 Thread Olivier Levillain 
Hi list,

I recently saw a related CVE regarding OpenSSL on oss-security mailing
list: CVE-2016-8610. The original mail is
http://seclists.org/oss-sec/2016/q4/224. As I understand it, the idea is
to send a continuous flow of unauthenticated, warning-level alerts in
the middle of the initial handshake. This leads OpenSSL to keep the
connection open (and apparently to consume some CPU).

Even if this might not be the attack of the century, it may also be
another reason to reconsider how a TLS stack should handle
[multiple|warning|unauthenticated] alerts.

olivier


Le 25/10/2016 03:14, Kyle Nekritz a écrit :
> +1 to both Martin and ekr, I think simplifying these alerts with clearly 
> defined behavior for each alert description is the best way forward.
>
> Kyle 
>
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson
> 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 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'm happier with a lone 
> exception than with atrophied and redundant alert levels continuing as they 
> are.  I'd prefer to take the PR, with a minor amendment noting the hazard 
> caused by unrecognized_name(112).  Clients that intend to accept TLS 1.2 and 
> lower probably have to ignore warning alerts until they see that the server 
> is doing TLS 1.3 or higher.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=DQICAg=5VD0RTtNlTh3ycd41b3MUw=l2j4BjkO0Lc3u4CH2z7jPw=1svSdxAuionbHyrUN4ThSCRLZ1pCQuLaO0qtgQ8Dk7A=jWxxDB9uWwT6kP_7TcZ4isUa_Z5LNWOhgMX_O1s3oaw=
>  
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Deprecating alert levels

2016-10-24 Thread Kyle Nekritz 
+1 to both Martin and ekr, I think simplifying these alerts with clearly 
defined behavior for each alert description is the best way forward.

Kyle 

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson
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 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'm happier with a lone 
exception than with atrophied and redundant alert levels continuing as they 
are.  I'd prefer to take the PR, with a minor amendment noting the hazard 
caused by unrecognized_name(112).  Clients that intend to accept TLS 1.2 and 
lower probably have to ignore warning alerts until they see that the server is 
doing TLS 1.3 or higher.

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=DQICAg=5VD0RTtNlTh3ycd41b3MUw=l2j4BjkO0Lc3u4CH2z7jPw=1svSdxAuionbHyrUN4ThSCRLZ1pCQuLaO0qtgQ8Dk7A=jWxxDB9uWwT6kP_7TcZ4isUa_Z5LNWOhgMX_O1s3oaw=
 

___
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 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 an exception.  I'm happier with a
lone exception than with atrophied and redundant alert levels
continuing as they are.  I'd prefer to take the PR, with a minor
amendment noting the hazard caused by unrecognized_name(112).  Clients
that intend to accept TLS 1.2 and lower probably have to ignore
warning alerts until they see that the server is doing TLS 1.3 or
higher.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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
> approach.
>
> 1.  Is it appropriate for all unknown alerts to be treated as fatal? (the
> current draft already states this)
>

I thought we had pretty strong consensus on this. I'd be sad to take it
back.


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 :)

-Ekr


>
> Cheers,
>
> J
>
> On Wed, Oct 19, 2016 at 8:58 AM, Martin Rex  wrote:
>
>> 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 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.
>>
>> It seems that rfc6066 is not clear enough in explaining the issue
>> about the situation with the two WELL-DEFINED (but poorly implemented)
>> variants of the TLS alerts
>>
>>   (1)  unrecognized_name(112)  level WARNING
>>   (2)  unrecognized_name(112)  level FATAL
>>
>> See the *ORIGINAL* specification which created *BOTH* of these alert
>> variants:
>>
>> https://tools.ietf.org/html/rfc3546#page-10
>>
>>
>>If the server understood the client hello extension but does not
>>recognize the server name, it SHOULD send an "unrecognized_name"
>>alert (which MAY be fatal).
>>
>>
>> -Martin
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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
current draft already states this)
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?

Cheers,

J

On Wed, Oct 19, 2016 at 8:58 AM, Martin Rex  wrote:

> 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 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.
>
> It seems that rfc6066 is not clear enough in explaining the issue
> about the situation with the two WELL-DEFINED (but poorly implemented)
> variants of the TLS alerts
>
>   (1)  unrecognized_name(112)  level WARNING
>   (2)  unrecognized_name(112)  level FATAL
>
> See the *ORIGINAL* specification which created *BOTH* of these alert
> variants:
>
> https://tools.ietf.org/html/rfc3546#page-10
>
>
>If the server understood the client hello extension but does not
>recognize the server name, it SHOULD send an "unrecognized_name"
>alert (which MAY be fatal).
>
>
> -Martin
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 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.

It seems that rfc6066 is not clear enough in explaining the issue
about the situation with the two WELL-DEFINED (but poorly implemented)
variants of the TLS alerts

  (1)  unrecognized_name(112)  level WARNING
  (2)  unrecognized_name(112)  level FATAL

See the *ORIGINAL* specification which created *BOTH* of these alert variants:

https://tools.ietf.org/html/rfc3546#page-10


   If the server understood the client hello extension but does not
   recognize the server name, it SHOULD send an "unrecognized_name"
   alert (which MAY be fatal).


-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 
alerts

it says that any unknown alerts, irrespective of their level MUST be 
considered fatal
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 fatal forever (i.e. that no new warning-level alerts
> > can ever be defined).
> 
> That's already true:
> 
> https://tools.ietf.org/html/draft-ietf-tls-tls13-16#section-6
> https://tlswg.github.io/tls13-spec/#alert-protocol
> "Unknown alert types MUST be treated as fatal."
> 
> Changelog says this change was made for draft 14.

but unrecognized_name is defined (it's a part of MTI extension in fact), and 
any value defined by a new RFC automatically becomes a known alert

Not to mention that implementations are not supposed to send unknown alerts 
unless negotiated by extension.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Deprecating alert levels

2016-10-17 Thread Kyle Nekritz 
> 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=DQIBaQ=5VD0RTtNlTh3ycd41b3MUw=l2j4BjkO0Lc3u4CH2
> z7jPw=D6vgejwavMxoWSed2ANWwkecWIlc1MnHfgXfiejFS8Y=-fFwoxaS4TZXNkoZ
> M04oEUCKz283dy6QYRuhlOK0mQo=
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 defined).

That's already true:

https://tools.ietf.org/html/draft-ietf-tls-tls13-16#section-6
https://tlswg.github.io/tls13-spec/#alert-protocol
"Unknown alert types MUST be treated as fatal."

Changelog says this change was made for draft 14.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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:
> > 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 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.).
> > >
> > > could you expand on why it's a problem?
> >
> > Why what is a problem?
>
> clients sending incorrect levels for the description they send
>
> > My understanding is that at present, the AlertLevel is not reliable
> > (that is, some noticeable fraction of clients send nonsense) and so the
> > change in PR 693 is merely documenting existing best practice.
>
> the current draft says that any alert except the three defined as warning
> level must be considered fatal and cause connection closure
>
> I don't see how deprecating the field changes anything - the
> implementations
> won't need to behave differently and data on the wire won't be different
>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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, 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.).
> > 
> > could you expand on why it's a problem?
> 
> Why what is a problem?

clients sending incorrect levels for the description they send
 
> My understanding is that at present, the AlertLevel is not reliable
> (that is, some noticeable fraction of clients send nonsense) and so the
> change in PR 693 is merely documenting existing best practice.

the current draft says that any alert except the three defined as warning 
level must be considered fatal and cause connection closure

I don't see how deprecating the field changes anything - the implementations 
won't need to behave differently and data on the wire won't be different

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 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.).
> could you expand on why it's a problem?
>

Why what is a problem?

My understanding is that at present, the AlertLevel is not reliable
(that is, some noticeable fraction of clients send nonsense) and so the
change in PR 693 is merely documenting existing best practice.

-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 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.).

could you expand on why it's a problem?

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 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_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://www.ietf.org/mailman/listinfo/tls
> >
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 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://www.ietf.org/mailman/listinfo/tls
>

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[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 (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://www.ietf.org/mailman/listinfo/tls