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
