Re: [TLS] Server-side missing_extension MUSTs

[Dave Garrett <[e-mail]>]

On Tuesday, July 12, 2016 09:58:46 pm David Benjamin wrote:
> I would like to remove the missing_extension MUSTs on the server side. Full
> justification in the PR.
> https://github.com/tlswg/tls13-spec/pull/544
> 
> On the client, it is perfectly feasible to mandate a particular alert
> value. The check is very straight-forward. On the server, however, this is
> a mistake. Servers do not necessarily have full information if not all
> advertised ciphers are known, and a natural implementation of the
> negotiation algorithm will not output this case. Even without this clause,
> the handshake is already required to fail, so there is no risk of invalid
> clients being deployed.
> 
> Adding more complexity to an already hairy negotiation algorithm (the
> pseudocode I mentioned is incomplete) just to diagnose what is an invalid
> ClientHello anyway is not worth it. It buys too little for the complexity
> cost.

Reporting errors sufficiently is not an inconsequential issue. TLS has many interop issues with servers which just stare blankly back when something goes wrong, or fail in ways which do not indicate why. This general topic has come up as a problem in discussions here before. We need to specify how to fail appropriately such that when it happens, it can actually be diagnosed and fixed easily. The alternative is people sticking with the status quo forever. The only way this adds complexity is if you assume you're only writing the client and server for themselves, not expecting to interop with unknown peers.

First of all, as to not having "full information", I don't think anyone expects a server to be expected to pick the exact error alert if it can't even parse the cipher suites in question. When a server just skips over an unknown suite, if a missing_extension was technically correct for a server which could've understood it, then it doesn't really matter; the lack of that extension isn't what's causing the failure, as it never gets to that point.

To respond to your pseudocode in the PR, I'd say that explaining the expectation is simpler with a try/catch model: just assume that the required extensions are present, do whatever you do, and throw a missing_extension exception to trigger said fatal alert if at any point that fails to be true. (if you're using a language that does not have exceptions, you can of course do the same thing, just differently; this model just makes stating things simple)

The current wording in the draft has "and no alternative cipher suite is available" added in there, as selecting another suite that doesn't care about such a fault was agreed to be passable because requiring further validation after an acceptable suite+variables was already found was agreed to be excessive. However, we do not mean to imply that you should go _looking_ for an alternative if you're evaluating a suite and the required extension for it is missing. I would generally advise against adding workarounds for implementation flaws you've yet to actually encounter, as all you do is make it harder to detect and fix them when first created.


Dave