[TLS] Better weak hash language (was Re: AD Review of draft-ietf-tls-tls13)

[Dave Garrett <[e-mail]>]

On Monday, May 22, 2017 05:31:55 pm Viktor Dukhovni wrote:
> So if putting the consensus to ban MD5/SHA-1 in its *proper context*
> is consistent with the WG consensus, let's do that.

Yes, please.

Citing discussion elsewhere in this thread (that probably should've all
been forked off with a different subject long before now...):

On Monday, May 22, 2017 05:00:20 pm Nico Williams wrote:
> On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote:
> > On Tue, May 23, 2017 at 5:43 AM, Nico Williams <[e-mail]>
> > wrote:
> > > Proposal:
> > >
> > >    Clients SHOULD/MUST NOT accept server certificates, or certificate
> > >    validation paths, where the server certificate or intermediate
> > >    certificates (but not trust anchors) are signed with "weak" signature
> > >    algorithms, unless the client is not expecting TLS to strongly
> > >    authenticate the server (e.g., for opportunistic use) or where the
> > >    client has previously learned and cached the server's certificate.
> > 
> > I don't think "strongly authenticate" is useful here. I think the
> > requirement is that the RP must not accept these algorithms in any
> > context which would require validating signatures made using them.
> 
> Well, I want it to be crystal clear that the "not MD5 and such"
> requirement need not apply to opportunistic TLS usage.  If you don't
> like my text, maybe you can propose your own.

My issue with this area is that we've got this fairly weird two tiered
problem where we're still pretending SHA-1 is vaguely acceptable in some
scenarios where certificates are being validated, and thus we need two
sets of language: one for weak hash MUST NOTs and another for weak hash
SHOULD NOT. The current text was written before SHA-1 was broken back in
February, so, while the topic of changing language we had consensus on is
up, I'd really like to make SHA-1 completely banned for standard certificate
authenticated TLS 1.3+ connections alongside MD5. To do this in a
non-messy way, we'd have to delete the SHA-1 special-casing and state
that TLS 1.3+ implementations can only use deprecated hashes
(MD5/SHA1/SHA224/etc) if explicitly doing opportunistic encryption or some
scenario where trust can be established without validating them. Again,
the trust anchor gets an exception here due to it being trusted directly
without need for validation, and they can get away with just a "NOT
RECOMMENDED". If we can agree to this, then the resulting text will end up
being far less problematic. If we can't get a consensus for this, I seriously
propose citing RFC 6919 s3.


Dave