On Sun, Oct 11, 2015 at 01:53:34AM -0400, Dave Garrett wrote:
> On Sunday, October 11, 2015 01:08:41 am Viktor Dukhovni wrote:
> > Is this clear yet?
>
> It's clear, but we disagree on a few points here.
It is important to keep in mind that the TLS protocol specification
has a reasonably well defined scope and must not intrude on matters
that lie outside that scope.
In particular, the TLS 1.3 protocol, when not performing PSK
resumption, carries a sequence of "certificates" whose first element
(possibly in fact a bare public key) signs the protocol key exchange.
The protocol tries to be helpful by providing certificates that
the peer will understand. Therefore, the peer's list of supported
signature algorithms, whose primary purpose is to negotiate a
mutually supported PRF, is overloaded to help in certificate chain
selection. When multiple choices of certificate chain are available
(quite rare at present) to a peer, "the best" one can be selected.
Beyond that however, it is not the TLS protocol's job to preempt
a peer's decision as to whether a given sequence of "certificates"
is trustworthy or even well formed. That responsibility falls on
related higher-level protocols (PKIX 5280, Peer name checks RFC
6125, DANE 6698 as imminently updated by RFC 7671).
> From a perspective to get it to work with the bare minimum needed, it's
> excessive. From a perspective of killing SHA-1 wherever viable, it is not.
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.
Yes, libraries that implement both TLS and PKIX and provide
applications with active-attack resistant "secure channels" will
should avoid trusting SHA-1 in PKIX, and I'm fine with a narrow
statement that the peer chain verification code in such libraries
should not trust SHA-1 issued certificates when negotiating TLS
1.3. However the TLS specification MUST NOT preempt that verifier's
responsibility at the supplicant.
> Any continued legitimate allowance of a deprecated hash perpetuates other
> possible continued allowances, even if the one in question is viable under
> some specific circumstance.
See above, no crusades.
> The goal I'm aiming for is SHA-1 being restricted to TLS 1.2, with the
> exception of self-signed roots.
A lofty goal, but one that thoroughly exceeds the scope of the TLS
protocol. 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.
> In fact,
> two endpoints exchanging certs using SHA1 with intent to directly trust
> certs is allowed with this wording. Shots-in-the-dark using SHA1 from
> general-purpose servers are not. I think you wish to allow this last case;
> I do not.
I'm afraid this wish exceeds the proper scope of what the TLS
protocol can properly specify.
> If the trust model doesn't need the problematic portion of the chain, then
> the chain is not trustworthy and this does not apply.
This decision fundamentally belongs on the verifier side, and
therefore, it is NOT up to the sender to make it, nor is incumbent
on the verifier to reject the handshake because the chain sent
contains certificate with some algorithm it does not support if it
ends up not needing (to trust or use) those certificates.
> Also note that it
> is merely saying that _if_ the client chooses to abort the handshake, that
> _then_ it must alert and abort, and then specifies which abort should be
> used. If the client does not decide to abort the handshake, then the
> _entire_ portion above is not applicable (no abort, because acceptable in
> its trust model, therefor no alert for the trustworthy chain), which is
> exactly what you're requesting.
We already know what verifiers should do when they don't trust a
peer's credentials. Nothing new applies when that's due do an
unsupported signature algorithm.
> > This is fine, and applies to TLS PRFs, ... but the certificate
> > chain can still contain (untrusted) SHA-1 signatures even with TLS
> > 1.3.
>
> Yes. The certificate list can contain untrusted stuff, but the whatever
> it builds out of that to trust cannot rely on it at any point. (e.g. can
> trust a chain with a root w/ SHA1 or directly trust such a cert, but not
> a link with a SHA1 sig)
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.
If you narrowly say just this, without making any other changes, I'm
on board.
> > +MD5 hashes MUST NOT be used in any certificate in any TLS version, and
> > any
> > +implementation MAY reject any such certificate, without further
> > inspection.
> >
> > Again this is simply too strong. Just like SHA-1, MD5 is not
> > trusted. Its presence MUST NOT terminate the handshake, mandating
> > this at the TLS layer is a layer violation. Trust is an application
> > layer problem.
>
> It does not mandate termination; that's a "MAY". It says it "MUST NOT be
> used". A client could still accept it, if it really had to, so long as
> it's trusting the cert and not using the MD5 sig.
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.
It aborts in the TLS library, rather than in the application
verification layer (which is opportunistic and allows anonymous
clients and otherwise unauthenticated clients). This language
leads to breakage, and does not belong in specification.
It should maximally say that MD5 is untrusted, and should not
suggest that seeing MD5 in the peer's handshake cert chain is
sufficient grounds to immediately abort.
> Again, show no quarter. Even the slightest implication that MD5 is valid
> in any scenario involving a TLS 1.3 endpoint is too much at this point.
No religious zeal. It is counter-productive. The client in the
above example is forced to send in the clear, that's a self-imposed
downgrade from unauthenticated TLS to cleartext. Is that better?
> > The fallback chain can contain anything at all. CRC-32 if need
> > be.
>
> No. It's not just a matter of what can be trusted, but also a matter of
> what should be considered acceptable.
I did not say that CRC-32 is acceptable for trusted signatures.
It would merely not be sufficient grounds to abort a connection just
because a peer sent a certificate with that in its signature (if
there hypothetically was a PKIX OID for a signature algorithm like
that).
Which again points out that signatures in X.509 are PKIX not TLS.
It is not the job of TLS to overreach.
> TLS has a lot of crippling problems
> because they get ignored. Nobody complained about SS2 CLIENT-HELLOs for
> 20 years, so we _still_ have to allow accepting them for TLS 1.0-1.2
> connection attempts. If your goal is to truly phase out obsolete junk,
> you have to put pressure on it everywhere viable.
Remove junk from TLS. Clients that use TLS with PKIX, can avail
themselves of any junk cleanups that happen in PKIX and the libraries
that provide both TLS and PKIX.
We have a means to narrowly specify that TLS 1.3 PKIX profiles
should not trust SHA-1 signatures, we should say that and move on.
No religious zeal or overreach.
Clients that don't do PKIX at all, will then break needlessly
and possibly downgrade to cleartext.
> > This draft deprecates trust in SHA-1, and restates non-trust of
> > MD5.
I am fine with non-trust. I object to any and all requirements to
exclude these from TLS certificate messages presented to peers, or
to reject handshakes in which such messages are received. If the
certificates presented are critical for the peer's trust decision
and trust is required to complete the handshake, *then* the handshake
breaks. No new mandate to object to these algorithms in the peer's
chain based solely on their presence.
> > While clarifying that presence of either in certificates does
> > not constitute a malformed protocol message, and does not automatically
> > lead to fatal handshake errors. Rather, when seen outside of
> > self-signatures in certificates needed to construct the complete
> > chain, these algorithms typically cause chain verification to fail,
> > which may in turn cause the handshake to be aborted for lack of
> > trust, not because of deprecated signature algorithms in the
> > certificate chain.
>
> The text still has the client making the final call on server cert chains in
> all instances.
Not as written. It needs to be clear that clients MUST NOT *trust*
these algorithms, and that's it. If trust is required the connection
ends with a fatal alert. If trust is not required, or the certificates
in question end up not used in whatever chain is ultimately trusted,
then the handshake continues.
TLS needs to do *its* job flawlessly, but not overreach.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
