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

[Hubert Kario <[e-mail]>]

On Wednesday 08 July 2015 15:23:03 Dave Garrett wrote:
> 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.

this is general behaviour of schannel implementation, as far as I've read
 
> 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:man
> datoryextensions
> 
> 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?".

definitely agree, what action to take on an error state should be clearly 
defined by the spec

I'm quite sure that by differences in error handling you can fingerprint the 
implementations very specifically - not catastrophic, but hardly ideal

that being said, I don't think this part of spec is, let's say... "fortunate".
It should be left up to the client to decide if it likes the certificate or 
not - not the server withholding it as a "you won't like it anyway".

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

that was my general understanding for the TLS specs, given that we have such 
general alerts as "internal_error" and "handshake_failure" - but I can't point 
to any specific part of RFC that says that.

+1 for adding it to the TLS 1.3 spec
-- 
Regards,
Hubert Kario
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