Re: [TLS] Server-side missing_extension MUSTs

I'm also curious what cases were you envisioning missing_extension to be
useful. I spend a lot of my time triaging TLS-related bugs in Chrome, so
I'm certainly not blind to TLS handshake errors being difficult to
diagnose, especially on the client. But I don't believe such an alert would
ever have helped me. Perhaps I am missing something?

I don't believe an implementation which fails to send supported_groups,
etc., in 1.3 would ever leave a developer's workstation. It would not
interoperate with anything. Such a client is completely failing to
implement the protocol, and in a way that nothing would work. Difficulties
usually arise not here, but with more complex cases. Where we have interop
against some peers, but not others. Where all protocol messages are legal
but, due to different configurations on either end, no set of parameters
could be found. Where the connection would have succeeded but for, say, a
recent RC4 removal.

If we wish to address the diagnosis problem, we should think about those,
and also how to simplify negotiation so the kinds of errors are less
complex and reporting them is simpler, rather than get distracted by
trivialities.

David

On Wed, Jul 13, 2016 at 12:18 AM Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 13 July 2016 at 13:22, Dave Garrett <davemgarrett@gmail.com> wrote:
> > I am aware that discussion ended up on accepting sloppy error reporting
> as acceptable. Changing the disputed missing_extension alerts to SHOULDs
> would be an acceptable compromise if that decision is still actually going
> through.
>
> "sloppy" is a bit of a mischaracterization.  There are good reasons
> for this decision.
>
> It allows implementations to be structured differently.  In
> particular, if there are two relevant error conditions, different
> implementations could discover them in different orders.
> MUST-strength requirements on alerting for one of those conditions
> means that you have to order your checking in a particular way;
> MUST-strength requirements on multiple concurrent conditions are
> basically impossible to meet.
>
> It also allows an implementation to decide that abrupt cessation of
> communications is preferable to generating a report.  That can be
> important for DoS mitigation.
>
> In the end, we concluded that you shouldn't lie about error
> conditions; if you determine that there is a missing extension and you
> decide to send an alert, then it has to be the missing_extension
> alert.
>
> David's PR goes to the core of the first of my reasons here.  The ways
> in which servers decide on the things like version and cipher suite
> when presented with a ClientHello is in practice hugely different
> between implementations.  That's healthy, but it does mean that we
> need flexibility.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>