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

Reply via email to