Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

[Dave Garrett <[e-mail]>]

On Wednesday, July 08, 2015 02:15:40 pm Hubert Kario wrote:
> The IIS is behaving as the RFC requires it to (with the exception of TLS 
> alerts) - according to section 7.4.2 of RFC 5246 - bottom of page 48.

I was just about to respond to this with the obvious joke: "It works perfectly fine except for the part that is broken" ... and then I read the spec and actually have to defend them here. There isn't actually a requirement of throwing an error alert in the spec, currently. There of course ~should~ be an alert, and it should be in the spec, but it isn't yet.

Note, BTW, that my current WIP for MTI extensions already does have hard error cases added in, including a new alert:
https://github.com/davegarrett/tls13-spec/compare/pruning...davegarrett:mandatoryextensions

There have already been a few spots that got clarifications on what errors should be expected, and I think this is an area that really should be given proper focus for TLS 1.3. We shouldn't have any spots where anyone can say: "huh, what should it do now?".

In fact, I think a catch-all requirement that a server MUST always return ~something~ in response to a (mostly) valid client message might be helpful here. Radio silence in response to any error is a really bad scenario that makes dealing with things annoyingly difficult. Servers should only stealth block/drop connections when it's likely to be junk its receiving (e.g. DoS or explicitly invalid/unauthorized attempt).


Dave