I'd like to get a sense of what the WG is willing to consider with regard to SHA-1, rather than only Viktor and myself discussing this. Basically, I see 3 options:
Option 0: Do nothing new. SHA-1 is soft deprecated, but still a fully viable option in TLS 1.3 if nothing better is installed. Option 1: Explicitly state that TLS 1.3+ clients must not trust SHA-1 signatures (but may trust full certificates, namely roots). Option 2: Distrust (option 1) and also prohibit endpoints from sending chains that rely on SHA-1 signatures to their peers when negotiating TLS 1.3. (aka, don't upgrade to TLS 1.3 until you've upgraded your certificates; self-signed roots still exempt) No change is proposed with regard to dealing with SHA-1 under TLS 1.2 beyond the current state. TLS 1.3 already prohibits using SHA-1 in CertificateVerify. This discussion is only for TLS 1.3+ non-root certificates. The TLS 1.3 release is not yet near (assume we're talking about 2016, when others are phasing out SHA-1 more strictly as well). I am in favor of #2, as I don't think the risk of keeping it in the spec is worth continued support (SHA-1 is on its way out, and TLS 1.3 shouldn't perpetuate its use). Viktor Dukhovni is in favor of #1, and considers prohibiting servers from sending SHA-1 certs to be sufficiently out-of-scope and not worth the interop risk (opportunistic encryption and direct trust of certificates, of note). Two opinions does not a working group make, so more input is clearly needed to move forward in any way here. This is only a preliminary call for opinions, and certainly not a policy deciding vote. The new reason to consider this: https://sites.google.com/site/itstheshappening/ Current draft language: https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-60 Start of the parent thread: https://www.ietf.org/mail-archive/web/tls/current/msg17956.html Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
