On Sun, Oct 11, 2015 at 01:24:36PM -0400, Dave Garrett wrote:
> > Is is not appropriate mission for the TLS WG to launch a wider
> > anti-SHA1 crusade. The TLS WG just needs to just avoid SHA-1
> > problems in the TLS protocol itself (PRFs, ...). Avoiding SHA-1
> > in PKIX is outside this group's purview.
>
> Every time something is "someone else's problem", it is ensured that the
> problem will not be properly fixed. Security is only as strong as the
> weakest link in the chain, and thus I don't believe a philosophy of complete
> separation of roles is realistic, especially in a world where upgrades
> and fixes are still deployed slowly and badly.
And yet despite your best intentions, defining the semantics of
the certificates *carried* by TLS (but specified elsewhere and
possibly irrelevant to the verifier) is properly outside the purview
of the TLS WG. We can suggest that in TLS 1.3 SHA-1 signatures
should not be trusted because they are too weak by comparison with
the algorithms used elsewhere in TLS 1.3, we cannot say that peers
must abort handshakes carrying certs with signature algorithms
employing SHA-1, MD5 or even hypothetically CRC-32 certificates on
sight.
> > See above, no crusades.
>
> Calling the goal of phasing out known-bad features a "crusade" is not
> really helpful. I'm perfectly fine with stating that SHA-1 is reasonable
> to allow in areas where it needs to be for continued transition. It,
> however, should require justification to keep allowance rather than to
> remove.
And yet what you propose is a crusade. You're no longer looking
at TLS. You're suggesting we constrain choices outside of TLS,
because we know better, but we don't know better, because TLS has
no knowledge of the application trust model. So TLS does not get
to dictate which offered certificate chains are to be rejected and
which accepted. The best we can do is to specify which parameters
are too weak to include in such decisions when and if processing
chain elements that contain such parameters.
> > SHA-1 must also be allowed in non-root certs, provided
> > the peer does not trust them (possibly does not need them at all).
> > This is something only the peer can know.
>
> If we consider the certificate authenticated cipher suite scenario within
> TLS to expect this to be the common case, then that gives the false
> impression that admins don't "have" to upgrade because they're "usable".
Nothing of the sort. We've agreed that TLS 1.3 clients won't trust
SHA-1. We need to stop there. We have no choice. We might like
to be able to be beneficent dictators, but that's not an option.
> > This is something we agree on, so the pull request needs to limit itself
> > to *exactly* this. Any trusted chain constructed by a TLS 1.3 peer cannot
> > contain issuer->subject links that employ SHA-1 signatures.
>
> Essentially, our disagreement is just what to do on the server side of
> things. I'm saying the server should be required to send non-obsolete
> certificates and not allowed to assume clients might be able to trust
> non-root certs directly, as this is not the dominant way certificate
> authentication is done.
The difference goes further, yes the server must not unilaterally
deny access to a configured SHA-1 chain, but also the client must
not out of hand reject the transmission of such a chain just because
SHA-1 is found. Rather the client optionally (but typically)
attempts to authenticate the server's certificates, and if that
requires using a SHA-1 cert it might stops there given suitable
requirements in the TLS 1.3 draft, but if none of the presented
SHA-1 certs were needed, then all's well that ends well. This
subsumes all the use-cases in which some or all of the server's
certificates go unused.
> > Well, this "MAY" is in fact used incorrectly in Schannel, which
> > aborts connections with opportunistic TLS SMTP clients that present
> > client certs that include CAcert's MD5 self-signed root.
>
> Why on Earth is anyone still using an MD5 self-signed root? Regardless,
> "non-root" is acceptable here, if that's sadly still a concern.
Ask CAcert.org whose 4096-bit root CA is self-signed with MD5 for
no good reason whatsoever. And yet there's no problem with that,
the cert is slightly smaller that way, and the self-signature plays
no role in security.
> When talking about MD5 still being around, I'm inclined to consider it
> acceptable collateral damage to avoid presenting a false sense of security,
> though if the land of half-assed email transport security is still this
> bad, then this may not be ideal.
Your "half-assed" is my impressive success, ~80% of outbound email
from Google, that used to go in clear is now encrypted. What
fraction of HTTP sites have migrated from cleartext?
> The correct course of action is of course
> to not support this connection at all, but that requires more commitment
> than developers are willing to make to security. That lack of will is
> _why_ I'm arguing for minimal tolerance of obsolete hashes.
There is no "lack of will", you're just doggedly ignoring legitimate
use cases. In all-or-nothing security the majority gets nothing.
I know that opportunistic security is major cognitive dissonance
for security professionals trained to accept no compromises, but
it is fact by making judicious compromises that real progress is
made.
> > TLS needs to do *its* job flawlessly, but not overreach.
>
> TLS is not capable of doing its job without sanity checking inputs from
> related layers. The job of TLS is to provide a secure connection, which
> it cannot do if it tolerates authentication of clearly obsolete and
> forgeable certificates when it does not have to. (MD5 being the most brazen
> example)
For opportunistic TLS in SMTP, "secure" means unauthenticated
encryption, for otherwise "secure" means "cleartext" and hope nobody
is looking. Certificates are just useless baggage to make the
protocol happy. There is no single all-encompassing security model,
and it is important for this WG to not presume that a single model
is sufficient.
Yes, we're also trying to roll out DANE authentication for email,
but that'll take time, and still protect a fraction of the traffic,
with the majority doing just unauthenticated TLS for quite some
time.
Please start with a sensibly minimal proposal that achieves the
essential goal of deprecating *trust* in SHA-1. Please do not
overreach by requiring not sending SHA-1 or aborting when receiving
SHA-1. This is adds nothing of value, just needlessly breaks
legitimate (yes non-primary) TLS use-cases.
Soon enough the trusted CAs will stop issuing certs with SHA-1 in
them, and the problem goes away at that layer. Libraries that
implement TLS 1.3 while doing PKIX authentication will help out by
not trusting non-root certs with SHA-1, but will accept and process
the peer's chain before deciding whether they can construct a
trusted path to the leaf using any local certificate stores and
whatever the server provided in addition.
You need to step back and accept a reasonable compromise that makes
progress without overreaching. I'm trying to help, but we must
avoid collateral damage. What you think is "acceptable collateral
damage" is harmful and unnecessary overreach.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
