On Sun, Jan 22, 2023 at 03:41:06PM -0500, Viktor Dukhovni wrote: > Thanks to Todd Short, RFC7250 raw public keys should be available in > OpenSSL ~3.2. Applications that use unauthenticated opportunistic TLS, > employ DANE or have other ways to avoid X.509 certificates and make do > with raw peer public keys can avoid the overhead of receiving and > processing certificate chains.
In TLS 1.2, in response to a CertificateRequest, and with X.509 as the (typically implicit) client certificate type, a client can decline to authenticate itself by sending a zero length certificate list. The ability for the client to opt-out of client authentication is quite useful, it allows servers to request optional client certs, that give some clients additional capabilities, while allowing other clients to connect anonymously, and either not authenticate, or use some other mechanism (SASL, ...) after the handshake. RFC7250 introduces a polymorphic TLS Certificate message that admits raw public keys. The message contains a possibly empty certificate list, or (crux of the problem detailed below) exactly one non-empty raw public key: https://datatracker.ietf.org/doc/html/rfc7250#section-3 opaque ASN.1Cert<1..2^24-1>; struct { select(certificate_type){ // certificate type defined in this document. case RawPublicKey: opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; // X.509 certificate defined in RFC 5246 case X.509: ASN.1Cert certificate_list<0..2^24-1>; // Additional certificate type based on // "TLS Certificate Types" subregistry }; } Certificate; The certificate_type is implicit, from the client_certificate_type extension in the Server Hello, which carries exactly the subsequently implicit type. Therefore, with TLS 1.2, it appears that if the server sends RPK as the client certificate type, the client has no means for *not* sending a raw public key. Not being able to opt-out leads to usability barriers: - A naive client application may have signalled support for RPK as a supported protocol feature, expecting to be able to opt-out in the absence of a configured key, just as with X.509. - The client's RPK algorithm may not be among the server's ClientCertificateType Identifiers: https://www.rfc-editor.org/rfc/rfc5246.html#section-7.4.4 https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-2 As a result, the client may discover late that it has no compatible key to send. TLS 1.3 addresses this by wrapping even RPK client crendentials in a list (that can be zero length). What is the right way to handle this in TLS 1.2? - Never offer to use client RPKs with TLS 1.2? - Advertise client RPK support only in very narrow contexts where the client knows in advance that it has a key that will be acceptable to the server, and the server doesn't just solicit, but in fact requires client auth? - Add a variant of the client_certificate_type extension that that allows the client to opt-out in its Certificate message (send length 0 to signal lack of an RPK)? - Just send a length 0 RPK, and expect that to be taken as "no RPK"? It would certainly be possible to make the upcoming OpenSSL RPK support at least tolerate the last choice on the server side, and allow clients to send 0-length TLS 1.2 RPKs. Sending such 0-length RPKs in the absence of suitable keys, will run into interoperability issues with implemntations that don't take the same liberal reading the RFC7250 message format. In the mean time, it seems that TLS 1.2 servers should only enable support for client RPKs when client authentication is *mandatory*, and clients should only advertise RPK support if they have keys that they have good reason to expect the server to support (either RSA expected to be generally supported by servers, or specific knowledge of the capabilities of the particular server). Any thoughts, comments, or advice? -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls