On Fri, Jul 29, 2022 at 09:50:56AM -0400, Erik Nygren wrote:
> Also including an Extended SNI option for "Certificate Fingerprint"
> would solve a bunch of issues that have come up from time-to-time.
> For example, it might help with DANE.
DANE does not need and must not carry a client-side expected fingerprint
signal:
* DANE adequately signals the expected server identity by sending the
"TLSA base domain" in SNI.
* The server's TLSA records are generally multi-valued (otherwise
breakage-free key rollover becomes impossible). There is no
single "expected certificate fingerprint", and DANE-TA(2) records
only signal the issuing CA.
* The server's public key may not infrequently be the same across
multiple candidate EE certificates, and its digest may not
clearly identify the right certificate to vend to the client.
...
> We've also talked in the past about being able to include a
> certificate fingerprint in URIs, and being able to signal that in
> Extended SNI would likely make that work better. (A use-case for this
> is for using TLS in local/private network environments such as to home
> network devices or even localhost processes where being able to have a
> URI with an {IP,cert_fingerprint(s)} pairing would have better
> security properties than trying to use some global PKIX framework.)
There are surely better ways than client-side public key pinning to deal
with that use case. For that (home) users will need to be able to
practically manage their own roots of trust and name resolution. Either
PHB's Mathematical Mesh or something related could be the way forward.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
