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 <hka...@redhat.com> 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
