On Wed, Oct 21, 2015 at 08:14:19PM -0400, Dave Garrett wrote:
> On Wednesday, October 21, 2015 03:56:09 pm Viktor Dukhovni wrote:
> > Whether SHA-1 in the chain is used to make trust decisions is only
> > known to the client, and the server MUST NOT preempt that by denying
> > the client access to whatever chain it has on hand.
>
> Can we please just fix this issue properly and add an "any(0xFF)" value
> to the enum so clients can explicitly tell the server that they're capable
> of trusting certs directly (or is doing OE) and the hash is potentially
> irrelevant?
This forces a new signalling channel from TLS clients that need
this to their TLS library to enable this new "any" value. Not an
API that's found in existing libraries or applications. Previously
the TLS library would just let clients validate chains as they fit.
> Note that the current proposed change does not break your use-case. Those
> clients can simply offer SHA-1 support indefinitely. Sure, they don't
> strictly support using SHA-1, but they support receiving certs using it,
> which is all the signal is really for.
Yes, the signal "would" suffice, if it were practical to inject
it. On the other hand, interposing on trust decisions for RFC 5280
chains is not the proper job of TLS. And the chain the server has
may not get used by the client in full (the client might replace
some issuer certs with alternative certs for the "same" issuer).
So, just as before, why is the TLS server the proper vehicle for
hiding SHA-1 certs from potentially, but not necessarily PKIX
clients? What's wrong with just having the various CAs no longer
issue SHA-1 certs, and the PKIX code in TLS libraries no longer
trusting SHA-1 certs by default? Do we really need a third
counter-measure that exceeds the proper scope of TLS?
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
