[TLS] SHA-1 patch updated with Russ' suggestion
Nitpicks accepted, pull requests preferred: https://github.com/tlswg/tls13-spec/pull/317 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SHA-1 patch updated with Russ' suggestion
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
Re: [TLS] SHA-1 patch updated with Russ' suggestion
On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote: > 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. Why "SHOULD NOT be checked"? I don't think it needs to say anything about checking self-signatures here, one way or another. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SHA-1 patch updated with Russ' suggestion
On Thu, Nov 05, 2015 at 04:59:18PM -0500, Dave Garrett wrote: > On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote: > > 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. > > Why "SHOULD NOT be checked"? I don't think it needs to say anything about > checking self-signatures here, one way or another. The verifier always has a trusted out-of-band copy of each trust-anchor. Checking the self-signature may needlessly run into problems when its deprecated algorithm is no longer even implemented in the crypto library. And yet the trust-anchor is still fine. If this is the only point on which I'm in the rough, so be it, but as a starting position I think it makes to avoid needless breakage. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SHA-1 patch updated with Russ' suggestion
On Thursday, November 05, 2015 05:05:02 pm Viktor Dukhovni wrote: > On Thu, Nov 05, 2015 at 04:59:18PM -0500, Dave Garrett wrote: > > > On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote: > > > 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. > > > > Why "SHOULD NOT be checked"? I don't think it needs to say anything about > > checking self-signatures here, one way or another. > > The verifier always has a trusted out-of-band copy of each > trust-anchor. Checking the self-signature may needlessly run into > problems when its deprecated algorithm is no longer even implemented > in the crypto library. And yet the trust-anchor is still fine. Ideally, if the implementation is trusting certs as a whole, then it should be attempting to validate self-signatures upon addition to the trust store. If the cert received matches exactly, then it has been checked; redoing it isn't helpful. I note "attempt to validate" and agree that failing but still agreeing to trust the cert could be fine. Essentially, I'd rather it say something to the effect of: "Trusted self-signatures SHOULD be validated before adding to a trust store and SHOULD NOT be re-checked at runtime." But we're getting slightly out of scope here, which is why I'm thinking that elaborating on this topic exactly as suggested is not needed in the document. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SHA-1 patch updated with Russ' suggestion
On Thu, Nov 05, 2015 at 06:53:46PM -0500, Dave Garrett wrote: > On Thursday, November 05, 2015 05:05:02 pm Viktor Dukhovni wrote: > > On Thu, Nov 05, 2015 at 04:59:18PM -0500, Dave Garrett wrote: > > > > > On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote: > > > > 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. > > > > > > Why "SHOULD NOT be checked"? I don't think it needs to say anything > > > about checking self-signatures here, one way or another. > > > > The verifier always has a trusted out-of-band copy of each > > trust-anchor. Checking the self-signature may needlessly run into > > problems when its deprecated algorithm is no longer even implemented > > in the crypto library. And yet the trust-anchor is still fine. > > Ideally, if the implementation is trusting certs as a whole, then it should > be attempting to validate self-signatures upon addition to the trust store. > If the cert received matches exactly, then it has been checked; redoing > it isn't helpful. I note "attempt to validate" and agree that failing but > still agreeing to trust the cert could be fine. Essentially, I'd rather > it say something to the effect of: "Trusted self-signatures SHOULD be > validated before adding to a trust store and SHOULD NOT be re-checked at > runtime." But we're getting slightly out of scope here, which is why I'm > thinking that elaborating on this topic exactly as suggested is not needed > in the document. Good, we essentially agree on the preferred implementation behaviour, what remains to quibble over is how explicit the text should be in that direction. And your more nuanced formulation is fine. I think that some implementation guidance is reasonable, but it can be weaker than "SHOULD". Implementations need to be strict where necessary, but being "strict" where unnecessary is bad, because connections break or downgrade to cleartext in cases that would otherwise just work. Having seen both a considerable lack of necessary checks in many implementations, *and* a considerable excess of counter-productive unnecessary checks, I prefer to give implementation guidance where there is non-negligible risk of either type of error. This particular issue is one where Schannel, for example, is at present not implemented correctly. It aborts handshakes when clients present CAcert.org issued certificates along with the issuer root CA cert. In SMTP to outlook.com this typically downgrades STARTTLS to cleartext for senders configured with client certs as described. Yes, I still agree that this is not a major issue, and if the core issues around client and server obligations are sorted, I can live with silence on this question if it is felt that guidance of this type detracts too much from the document. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SHA-1 patch updated with Russ' suggestion
Martin: > Nitpicks accepted, pull requests preferred: > > https://github.com/tlswg/tls13-spec/pull/317 It might be useful to remind people about the difference between self-signed certificates and self-issued certificates. RFC 5280 says: Self-signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate. Self-signed certificates are used to convey a public key for use to begin certification paths. Self-issued certificates are CA certificates in which the issuer and subject are the same entity. Self-issued certificates can appear in the middle of a path when a CA is doing key rollover and is doing old-signed-by-new and new-signed-by-old. The rollover approach is described in RFC 2510; look for "key update". Self-signed certificates are one very popular way to distribute the public key and distinguished name for a trust anchor. The certification path validation procedures in Section 6 of RFC 5280 do not validate the signature on such a sel-signed certificate. It says: When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. Russ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SHA-1 patch updated with Russ' suggestion
On Thu, Nov 05, 2015 at 08:15:31PM -0500, Russ Housley wrote: > It might be useful to remind people about the difference between self-signed > certificates and self-issued certificates. RFC 5280 says: > >Self-signed certificates are self-issued certificates where the digital >signature may be verified by the public key bound into the >certificate. Self-signed certificates are used to convey a public >key for use to begin certification paths. >Self-issued certificates are CA certificates in which >the issuer and subject are the same entity. > > Self-issued certificates can appear in the middle of a path when a CA is > doing key rollover and is doing old-signed-by-new and new-signed-by-old. > The rollover approach is described in RFC 2510; look for "key update". Thanks, I tried to use the right term in this discussion, and by luck or otherwise seem to have gotten it right. > Self-signed certificates are one very popular way to distribute the public > key and distinguished name for a trust anchor. The certification path > validation procedures in Section 6 of RFC 5280 do not validate the signature > on such a sel-signed certificate. It says: > >When the trust anchor is provided in the form of a self-signed >certificate, this self-signed certificate is not included as part of >the prospective certification path. Which is I think consistent with a recommendation to not check the self-signatures of trust anchors. In OpenSSL the definition of self-issued is as you explained, while self-signed requires all of the below. * Self-issued as a pre-requisite. * If an authority key id is present, it must match. * If keyUsage is present, it must permit certificate signing[0] So for a CA, a self-issued certificate can avoid being self-signed by having an authority key identifier that through its key id, or serial number identifies some other certificate as the issuer. -- Viktor. [0] The check of the keyUsage is a recent addition. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
