Re: [TLS] Draft 18 certificate signature algorithm requirements
On Thu, Dec 01, 2016 at 04:36:17AM +, Peter Gutmann wrote: > Viktor Dukhovni writes: > > >So I'd like to see the text in the first paragraph changed to a SHOULD or > >worst-case a qualified "MUST whenever possible". > > Why is that whole thing even there in the first place? From the previous > discussions where this came up, the pretty much universal consensus was that > people were ignoring the requirement because it served no obvious purpose > but broke interoperability. Unless you're a server operator that chooses to > buy a whole bunch of $995 certs, one per algorithm, from a CA that allows > you to choose which algorithm gets used for signing, the whole thing is > completely inapplicable. You send whatever cert chain the CA gave you to > the client, and it's up to them to decide whether they want to accept or > reject. What would be lost by simply removing that entire block of text, > since it's being ignored by implementers anyway? The solution is to remove > it, not to fiddle with it until it becomes a no-op that matches what > everyone is doing anyway. Using algorithms that are supported is kinda important for interop, since if you send a non-(super-)TA certificate using algorithm the client doesn't know, it is going to have trouble validating the chain. If you are referring to mixing RSA/ECDSA certs in one certificate chain, that already works fine in TLS-1.2-as-of-spec (unless client does something crazy[1]). TLS 1.3 removes the options for clients to be crazy here. [1] That's related to requirment of matching EE (not any CA) certificate type and ciphersuite, causing client to be able to trip all sorts of bugs and edge cases in ciphersuite selection. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft 18 certificate signature algorithm requirements
> On Nov 30, 2016, at 11:36 PM, Peter Gutmann wrote: > > Why is that whole thing even there in the first place? From the previous > discussions where this came up, the pretty much universal consensus was that > people were ignoring the requirement because it served no obvious purpose > but broke interoperability. Unless you're a server operator that chooses to > buy a whole bunch of $995 certs, one per algorithm, from a CA that allows > you to choose which algorithm gets used for signing, the whole thing is > completely inapplicable. You send whatever cert chain the CA gave you to > the client, and it's up to them to decide whether they want to accept or > reject. What would be lost by simply removing that entire block of text, > since it's being ignored by implementers anyway? The solution is to remove > it, not to fiddle with it until it becomes a no-op that matches what > everyone is doing anyway. I would agree, if indeed everyone were ignoring this. Sadly, that's not the case. In particular try to send to use a CAcert-issued client cert to send email with STARTTLS to outlook.com... So I wanted to see explicit text saying that the server SHOULD send what it has. Some folks here probably still think you and I (and perhaps ekr) are wrong, and that the server should drop the connection... This is not an invitation to reopen that wound. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft 18 certificate signature algorithm requirements
Viktor Dukhovni writes: >So I'd like to see the text in the first paragraph changed to a SHOULD or >worst-case a qualified "MUST whenever possible". Why is that whole thing even there in the first place? From the previous discussions where this came up, the pretty much universal consensus was that people were ignoring the requirement because it served no obvious purpose but broke interoperability. Unless you're a server operator that chooses to buy a whole bunch of $995 certs, one per algorithm, from a CA that allows you to choose which algorithm gets used for signing, the whole thing is completely inapplicable. You send whatever cert chain the CA gave you to the client, and it's up to them to decide whether they want to accept or reject. What would be lost by simply removing that entire block of text, since it's being ignored by implementers anyway? The solution is to remove it, not to fiddle with it until it becomes a no-op that matches what everyone is doing anyway. (This seems to be getting like PKIX where a mistake is never actually corrected, just watered down again and again over successive iterations of a spec until it's finally quietly dropped when no-one is looking). Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft 18 certificate signature algorithm requirements
> On Nov 30, 2016, at 10:51 PM, Eric Rescorla wrote: > > > > On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni > wrote: > > The current text reads: > >Section 4.4.1.2 ( > https://tools.ietf.org/html/draft-ietf-tls-tls13-18#page-56 ) > >All certificates provided by the server MUST be signed by a signature >algorithm that appears in the "signature_algorithms" extension >provided by the client, if they are able to provide such a chain (see >Section 4.2.3). Certificates that are self-signed or certificates >that are expected to be trust anchors are not validated as part of >the chain and therefore MAY be signed with any algorithm. > > [...] > > It's "MUST if... ". That's different from SHOULD unless because it > means that the unless clause is that only reason for violating it, and then > if that condition obtains it SHOULD do X but could presumably do > other things. Yes, I see. The stretch of text between the "MUST" and the "if" just happened to overflow my stack limit when I was rereading this today... Please pardon the short attention span. So all is well, unless there is merit it trying to word-smith the text to bring the "MUST" and "if" closer together The good new is that the intent is already just right. > I don't see any difference between "MUST whenever possible" > and the current language. Yes, fair enough... > On a related note, is there in the current draft anything that > requires ECDSA certificates to bear ECDSA issuer signatures? > > No. Nor has that been true since TLS 1.2. See: > https://tools.ietf.org/search/rfc5246#section-7.4.2 Great. Thanks. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft 18 certificate signature algorithm requirements
On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni wrote: > > We've discussed this before, and the current state of the text is > certainly much improved. I'd like to touch on one final point. > > The current text reads: > >Section 4.4.1.2 ( https://tools.ietf.org/html/ > draft-ietf-tls-tls13-18#page-56 ) > >All certificates provided by the server MUST be signed by a signature >algorithm that appears in the "signature_algorithms" extension >provided by the client, if they are able to provide such a chain (see >Section 4.2.3). Certificates that are self-signed or certificates >that are expected to be trust anchors are not validated as part of >the chain and therefore MAY be signed with any algorithm. > >If the server cannot produce a certificate chain that is signed only >via the indicated supported algorithms, 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 only if the "signature_algorithms" extension provided by >the client permits it. If the client cannot construct an acceptable >chain using the provided certificates and decides to abort the >handshake, then it MUST abort the handshake with an >"unsupported_certificate" alert. > > The first and second paragraph are in conflict, unless the first > paragraph's MUST is changed to a SHOULD, or a "MUST if at all > possible", ... That is it fine to require the server to send a > compatible rather than an incompatible certificate when it has at > least one of each, but if the only choice is to fail, the second > paragraph says that the server "SHOULD" send what it has, thus > the first is not really a MUST as written. > It's "MUST if... ". That's different from SHOULD unless because it means that the unless clause is that only reason for violating it, and then if that condition obtains it SHOULD do X but could presumably do other things. The onus is correctly placed on the client (not on the server) to > abort the connection, if the client's security requirements are not > met by the server's certificate chain. > > So I'd like to see the text in the first paragraph changed to a > SHOULD or worst-case a qualified "MUST whenever possible". > I don't see any difference between "MUST whenever possible" and the current language. On a related note, is there in the current draft anything that > requires ECDSA certificates to bear ECDSA issuer signatures? No. Nor has that been true since TLS 1.2. See: https://tools.ietf.org/search/rfc5246#section-7.4.2 If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). This is a departure from TLS 1.1, which required that the algorithms be the same. Note that this also implies that the DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the algorithm used to sign the certificate. Fixed DH certificates MAY be signed with any hash/signature algorithm pair appearing in the extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are historical. > Or > has that finally been relaxed, allowing the transmission of EE > ECDSA certs bearing RSA signatures (ideally the client also signals > support for RSA signatures)? This would lift the restriction > imposed by: > >https://tools.ietf.org/search/rfc4492#section-2.2 > >In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- >capable public key and be signed with ECDSA. > > My impression is that the text in the last paragraph of 4.4.1.4: > >https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.4.1.4 > >Note that a certificate containing a key for one signature algorithm >MAY be signed using a different signature algorithm (for instance, an >RSA key signed with an ECDSA key). > > seems to have the desired effect. Is that correct? If so, should > the change from 4492 be stated more emphatically, making it clear > that the older restriction no longer applies? > Given that ECDHE_ECDSA is not even a concept in TLS 1.3, I don't see that this text is relevant. -Ekr > > -- > Viktor. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
