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

[Eric Rescorla <[e-mail]>]

I'm not necessarily opposed to relaxing this requirement on the server,
but given that:

1. SHA-1 is on its way out.
2. Future versions of TLS seem very likely to explicitly indicate which
hash algorithms the clients support.

I'm kind of confused about the principle being espoused here. In general,
when the client has told the server what's acceptable and the server
doesn't have it, we abort the handshake. What makes this case different
from (say) the client only supporting P256 and the server only supporting
Curve25519 but deciding to send Curve25519 anyway?

-Ekr



On Fri, Jul 10, 2015 at 1:31 PM, Andrei Popov <[e-mail]>
wrote:

> Hi Viktor,
>
> Quoting my previous response to this thread:
> "It is possible that we might improve the product by not complying with
> section 7.4.1.4.1 of RFC 5246 in a future release, but currently schannel
> does comply."
>
> This thread has shown that it is hard to argue that schannel is RFC
> non-compliant WRT this particular problem. However, indeed it can be argued
> that in this case the product does not benefit from being RFC-compliant.
>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: TLS [mailto:[e-mail]] On Behalf Of Viktor Dukhovni
> Sent: Friday, July 10, 2015 9:09 AM
> To: [e-mail]
> Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS
> 1.3 draft-07 sneak peek)
>
> On Fri, Jul 10, 2015 at 11:54:53AM -0400, Dave Garrett wrote:
>
> > On Friday, July 10, 2015 11:49:12 am Viktor Dukhovni wrote:
> > > With time we learn to ignore some elements of specifications that
> > > don't make sense.  This is one such element.
> >
> > Which will lead to problems like this because not everyone will agree
> > on what parts to ignore. If you want it to actually work reliably,
> > you're going to need to follow or amend the spec.
>
> I am proposing that the specification bug be fixed in TLS 1.3.
>
> Indeed specification bugs are suboptimal.  In cases such as this one, not
> implementing the specification bug leads to unconditionally improved
> behaviour.  In some other cases, one has no choice but to implement the bug.
>
> For example, Postfix ignores a bug in RFC 5321 that suggests treating a
> 552 response to "RCPT TO" as though it were a 452 response.
> Following this causes more problems in practice than the mostly
> theoretical problem it solves.
>
> So if Andrey Poppv is still following this thread, I would like to suggest
> that Schannel be revised to be more tolerant of clients that don't offer a
> signature algorithm that matches the server's chain and use the server
> chain anyway.
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>