On Thu, Nov 05, 2015 at 06:47:51PM +0900, Martin Thomson wrote:
> Nitpicks accepted, pull requests preferred:
>
> https://github.com/tlswg/tls13-spec/pull/317
I am having a hard time figuring out what's changing. Can you
summarize the proposal?
I'd like it to say:
* The signature algorithms of self-signed certificates are
not subject to any constraints on either the supplicant or
the verifier. They are not required to match the supported
signature algorithms of the peer, are not required to avoid
deprecated algorithms, and their self-signatures SHOULD NOT
be checked.
* A "compatible" certificate message (ideally a certificate
chain) is one in which each certificate is either self-signed
or else is signed with a supported signature algorithm
advertised by the peer.
* A "non-SHA1" certificate message is a certificate message in
which each certificate is either self-signed or else is signed
with a signature algorithm other than SHA-1.
* A certificate message provided for verification to the peer
MUST be compatible if at all possible.
* A compatible certificate message MUST be "non-SHA1" if at
at all possible.
* When it is not possible to send a compatible certificate
message, a suitable default certificate message, in which
signature algorithms not known to be supported by the peer
MAY be sent. The onus of determining whether such a chain
is trustworthy falls exclusively on the verifier.
* If a verifier determines that the chain is not trustworthy
it MAY elect to abort the hanshake with a corresponding fatal
alert. If the chain is not trusted because it depends on an
unsupported signature algorithm, then the appropriate alert
is unsupported_certificate(43).
Note that the pull request contains harmful text:
Any endpoint receiving any certificate signed using any signature
algorithm using an MD5 hash MUST send a "bad_certificate" alert
message and close the connection.
This breaks peers that send the self-signed CAcert root CA as part
of their chain. The correct language would be:
Certificates signed with a signature algorithm based on the
MD5 hash that are not self-signed MUST NOT be trusted, even if
signed by a trusted issuer (and not expired, etc.).
I should note that the harmful text is at least on the correct side
of the supplicant/verifier divide. We protect nobody by restricting
what legitimate supplicants can send, that just lulls verifiers
into a false sense of security (they might not check for conditions
that they are not typically exposed to). We need to protect
verifiers from what malicious actors will send, and malicious actors
will not play nice by avoiding MD5 and SHA-1.
So the emphasis needs to be clearly on the responsibilities of the
verifier. Furthermore, questions of whether the chain is trusted
or not trusted belong in the layer doing PKIX (5280) trust chain
construction, not the layer doing TLS protocol message processing.
I will make sure that OpenSSL's stack for TLS 1.3 does not accept
MD5 signatures as trusted and (by default) won't accept SHA-1 as
trusted either. The simplest implementation is to delete all
non-leaf certificates from the received chain that use disabled or
unsupported algorithms and then construct the chain from what
remains.
If no trusted chain can be built, succeed or fail accordingly.
Some peers will be opportunistic and go on regardless. Some peers
will require a secure connection, but will complete the connection
and then gracefully disconnect at the application layer. Other
peers will abort the handshake and close with a fatal alert.
The logic unequivocally belongs in the verifier as it always did.
The lower levels of the protocol MUST NOT get in the way.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
