On Wed, Nov 25, 2015 at 02:39:27PM -0500, Sean Turner wrote:
> After reviewing the list discussion, PR#317
> (https://github.com/tlswg/tls13-spec/pull/317) is okay to merge. Initially,
> there was some confusion about exactly what changes were being proposed
> (PR#317 is built on PR#231) but that seems to have no be cleared up; text
> about not checking the signature on a self-signed certificates has been
> added in various places.
It seems the below is the final text on server certificates and SHA-1:
https://github.com/martinthomson/tls13-spec/commit/bd7d7058d43c946142a8628e7d9103bdf346470a
+All certificates provided by the server MUST be signed by a
+hash/signature algorithm pair that appears in the "signature_algorithms"
+extension provided by the client, if they are able to provide such
+a chain (see {{signature-algorithms}}).
+If the server cannot produce a certificate chain that is signed only via
the
+indicated supported pairs, then it SHOULD continue the handshake by sending
+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.
No problem with that text. The text for the receiving end could perhaps use
a bit of refinement:
+As SHA-1 and SHA-224 are deprecated, support for them is NOT RECOMMENDED.
+Endpoints that reject chains due to use of a deprecated hash MUST send
+a fatal "bad_certificate" alert message before closing the connection.
+All endpoints are RECOMMENDED to transition to SHA-256 or better as soon
+as possible to maintain interoperability with implementations
+currently in the process of phasing out SHA-1 support.
the point being that the layer that's deciding that the hash
algorithms in the chain are or are not satisfactory is often well
above the code that's responsible for low-level protocol message
processing and alert generation. Weak signature algorithms will
often simply present as trust failures, and may be reported in
the same way as chains for which no suitable trust anchor is found.
One reason why a precise error may be difficult is that "path
construction" algorithms need not use the particular certificates
provided by the peer, and may have access to alternative certificates
with which to build the chain. So when an untrusted digest is
encountered, the simplest approach is to ignore that certificate
(filter such certificates out of the peer's response) and try to
build a chain without it. Which means that the final error may
not be related to that problem digest.
The main case in which one can reasonably expect that the problem
digest will be reported is if the weak signature is in the leaf
certificate, rather than in an intermediate CA.
Some applications don't abort the handshake when trust fails, they
continue and disconnect at the application layer.
So the upshot is that perhaps "MUST" above is stronger than possible.
On the other hand, I don't see implementations taking that MUST
too seriously if it does not comport with how certificate chain
construction and verification is done. Mere presence of an
unsupported digest in the certificate message should not be a reason
to send the alert and abort, the certificate with the problem
digest might not be needed in the end. So the decision will (or
at least should) generally be delayed until chain construction
and verification take place, where there's enough complexity
that the proposed MUST may not possible.
My recommendation would be to encourage implementations to not
reject peer certificate messages out of hand (prior to attempting
chain construction and verification) merely because they happen to
contain an element with an unsupported signature. When chain
verification fails, the library will do its best to communicate
the reason, which may be that its best chain candidate had an
unsupported digest and a "bad_certificate" alert is then sent. It
may also be that no candidate chain is constructed (the simpler
ignore unsupported intermediates approach), in which case the fatal
alert is more likely "certificate_unknown".
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
