>> It would be useful to be able to request certificates conditioned on the
>> client promising to not fail just because it is unable or unwilling to offer
>> one.
TLS RFCs do not require clients to fail the handshake when the server requests
a cert and the client cannot satisfy the request. E.g., TLS 1.3 says:
" If the server requests client authentication but no
suitable certificate is available, the client MUST send a Certificate
message containing no certificates (i.e., with the "certificate_list"
field having length 0)."
>> They could just proceed without a certificate, or return a default
one, but they don't.
Yes, but, arguably, such broken clients won't be fixed by adding new
extensions/flags/etc. If they do not comply with the simple RFC language that
exists, can we expect them to implement the new flag correctly?
Cheers,
Andrei
-----Original Message-----
From: TLS <tls-boun...@ietf.org> On Behalf Of Viktor Dukhovni
Sent: Monday, October 23, 2023 10:38 AM
To: tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] Request mTLS Flag
On Mon, Oct 23, 2023 at 11:36:10AM -0400, David Benjamin wrote:
> Would you expect a browser user to send this flag? On the browser
> side, we don't know until the CertificateRequest whether a client
> certificate is configured. We have to do a moderately expensive query,
> dependent on information on the CertificateRequest of the OS's cert
> and key stores to get this information. This query may even call into
> things like 3p smartcard drivers, which may do arbitrarily disruptive
> things like showing UI.
One sensible use-case for such a signal is in mail user agent (MUA) to mail
submission agent (MSA) communication.
- When the submission client is a bot, a client cert is a fairly
natural choice of credential.
- Some Java TLS libraries (used to?) fail the handshake when the
client has no configured certs, or the list of issuer CA DN hints
does include any of its available (typically just zero or one)
certificates.
They could just proceed without a certificate, or return a default
one, but they don't.
- Most MTAs and MSAs don't request certificates, avoiding the
potential interoperability issue.
It would be useful to be able to request certificates conditioned on the client
promising to not fail just because it is unable or unwilling to offer one.
Hence, I would like to see this flag move forward, though I'd also, perhaps
separately, like to see an extension, that either combined with this flag, or
alone, conveys an additional DNS name, where the server might find the client's
TLSA records, allowing the client to establish a binding to that name.
Something like, given:
_smtp-client.example.com. IN TLSA 3 1 1 ...
send a hint of "example.com", with the "_smtp-client" prefix implied by the
application protocol (prepended by the server).
https://datatracker.ietf.org/doc/html/draft-huque-tls-dane-clientid
--
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
