Re: [TLS] Server-side missing_extension MUSTs

[Dave Garrett <[e-mail]>]

On Wednesday, July 13, 2016 01:23:53 am David Benjamin wrote:
> 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've triaged TLS-related bugs in Firefox (to be fair, not as much as of late), which largely made me come to the conclusion that stricter and more precise error handling is sorely needed. I make no claim that this particular error in this particular case is the focal point on which anything practical I can come up with at the moment hinges, however I have seen too much nonsense to not advocate for rigorous preventive action. When we leave holes and generic responses in specs, the incomprehensible litany of implementations inevitably results in interactions that we are not capable of predicting.

To be clear though, completely mandatory extensions, at least as we're doing them here, are a new thing. TLS 1.2 relied on separate messages for stuff, but we're front-loading everything into the ClientHello to get reliable 1RTT (with the exception of HRR).

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

We have to assume that some small minority of implementors are not acting in good faith to maintain ideal security, but rather are creating something just functional enough for their specific purpose (possibly a larger minority with IoT). If someone kludges an ad hoc client/server pair that skips the groups extension to go straight to key share, they could get it to work fine. (they're only separate because we are, ourselves, kludging in new features into an old extension, whilst maintaining backwards compatibility) If someone else then has to get this to work with a normal server, they're going to have to let this slide. It is a hell of a lot easier (from a psychological & political perspective) to just kludge in a special case instead of being forced to explicitly cancel out error checks/reporting that come directly from the spec. The more this stuff is left unspecified, the more risk we get of kludge-related breakage/exploits.

As a rule, I never assume something is impossible; you can always be surprised by the interactions of several kludges and a few lazy, sloppy, stupid, or malicious people. This is a 20 year old mess; paranoia is required.

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

I agree we should simplify negotiation, wholeheartedly. That is most certainly a better way to do things. I preferred we just require groups and key share for all TLS 1.3+ hellos, always, without exception. Much simpler, but pure-PSK (which I'd prefer was not in the spec) is the special case that complicates things here, and merging the two systems into one simpler one was rejected. (one always mandatory dh/psk key specification extension that is always used requires far less thought to sanity check) Just because a better system isn't used, doesn't mean I won't advocate for stop-loss on what we do go with, however.

To restate what I said in my other reply, downgrading the relevant MUSTs to SHOULDs would be something I'd be ok with. Servers MUST give an appropriate error when aborting, and SHOULD give the most relevant one they can provide at that time.

I do not claim that this here specifically is of top-tier importance, but I will generally resist all attempts to water-down constraints we had previously maintained consensus for.


Dave