On Sun, Oct 11, 2015 at 12:33:33AM -0400, Dave Garrett wrote:
> https://github.com/tlswg/tls13-spec/pull/287
>
> PR updated with some revisions. Please take a look at some point and tell me
> what you think.
Still problematic, by changing more text than necessary. The following
is wrong and should not be added.
Just after which is largely fine (I would carve out an explicit
exception for self-signatures which are a matter of data format
necessity not trust):
"Endpoints negotiating use of TLS 1.3 MUST NOT trust any
signature that uses any of the deprecated hash algorithms
(MD5, SHA-1, & SHA-224)"
You add the incorrect:
or send any certificate relying on any deprecated hash to
its peer. (see {{server-certificate}})
This is still the same problem as before. The fix is to just as
before say no such thing, each peer sends something with a known
supported algorithm if it can, or whatever otherwise it has if it
can't. Indeed with SNI, sending the right certificate (matching
SAN) takes precedence over any considerations of algorithms. If
the none of the certificates with the right SAN have supported
algorithms, send one with an unsupported algorithm and let the peer
decide.
At which point, the next change is not needed:
-the client a certificate chain of its choice that may include algorithms
-that are not known to be supported by the client. This fallback chain MAY
-use the deprecated SHA-1 hash algorithm.
+the client a certificate chain of its choice that MAY include algorithms
+that are not known to be supported by the client.
For SHA-1 can still be sent, all that changes is that its in
signatures is no longer trusted, (but tolerated in self-signatures
which are not relevant in evaluating trust).
At which point we get to (removed original text elided, just
unchanged and new text below):
If the client cannot construct an acceptable chain using the provided
+certificates and decides to abort the handshake, then it MUST send a
+fatal alert message and close the connection. If the chain is untrustworthy
+because a certificate cannot be parsed correctly or due to use of a
+deprecated hash algorithm (MD5, SHA-1, & SHA-224), then it SHOULD produce
+a "bad_certificate" alert; otherwise it MUST produce an
+"unsupported_certificate" alert.
It is simply wrong to require any particular reaction to an untrusted
chain. Elements of the chain may expired, contain unknown (more
modern?) algorithms, and yet the handshake can continue in trust
models which don't need the problematic portion of the chain.
TLS does not mandate a trust model, it supports Web PKI trust more
directly than other models, but that's as far as it goes.
TLS can say that certificates with SHA-1 are no longer to be trusted.
Some such intermediate certificates sent by a peer may not even
end up in the (alternative) chain the verifier builds. Or the
verifier may not validate any certificate chain at all.
+Servers supporting both TLS 1.2 and TLS 1.3 MAY negotiate TLS 1.2 with
+support for SHA-1 hashes, however servers MUST NOT downgrade to use an
+older version in response to a TLS 1.3 client offering support for only
+deprecated or unsupported hashes. All clients offering TLS 1.3 are REQUIRED
+to offer support for at least one hash/signature pair which is not
deprecated
+(see {{signature-algorithms}}).
This is fine, and applies to TLS PRFs, ... but the certificate
chain can still contain (untrusted) SHA-1 signatures even with TLS
1.3.
+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.
Also the below is not appropriate:
+- Have you ensured that certificate chains using SHA-1 or SHA-224
+ are only used with TLS 1.2 or older, or are prohibited completely?
+
And this:
+- When the client has requested a server certificate, but no
+ suitable certificate chain is available, do you correctly send a
+ valid fallback chain using whatever TLS 1.3 permitted algorithms
+ are necessary, instead of immediately aborting the connection?
+
The fallback chain can contain anything at all. CRC-32 if need
be. Only SHA2-256, equivalent or better is to be trusted, but
that's a decision for the next layer up.
This pull request needs to simply specify that digest algorithms
other than SHA2-256 and SHA2-384 (plus any speficified in future
RFCs as sufficiently strong) are to be trusted by default.
Some clients may accept GOST signatures, that's a local matter for
those clients. And we may yet see some subset of SHA3-256, SHAKE256,
Blake2, ... in certificates.
This draft deprecates trust in SHA-1, and restates non-trust of
MD5. While clarifying that presence of either in certificates does
not constitude 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.
Is this clear yet?
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
