> On May 22, 2017, at 8:19 PM, Dave Garrett <davemgarr...@gmail.com> wrote:
>
> 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.
Works for me. In all the use-cases I care about the hash algorithm in
question is never actually used to validate any certificate signatures,
but the spec seems to require that the handshake be aborted anyway, just
because the codepoint is present in the chain.
I have no objections to banning *actual* use for making verification
decisions of all hash functions with collision resistance less than
say 120 bits (128 - modest fuzz for attacks that don't significantly
damage the algorithm).
What I am trying to avoid is having implementations just hang up
because the peer's certificate message contains "toxic" codepoints,
that will never actually get used, because verification is not
performed at all, or performed by means other than PKIX, or with
different intermediate certificates than presented.
Setting a collision-resistance floor rather than naming some list
of algorithms makes more sense to me, but if the WG really feels
that naming some "verbotten" algorithms is better, so be it.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
