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 <n...@cryptonector.com> > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
