Thanks for the detailed response, that is very much appreciated. When I
wrote the initial email, I had more in mind some sort of configuration - as
opposed to DANE. I agree that the use of PSKI should not cause any of the
headaches associated with pinning.

Yours,
Daniel

On Mon, Jun 13, 2022 at 11:56 AM Viktor Dukhovni <ietf-d...@dukhovni.org>
wrote:

> On Mon, Jun 13, 2022 at 10:42:51AM -0400, Daniel Migault wrote:
>
> > I sent this question regarding the use of SPKI Fingerprints to the
> > add mailing list, but I am also eventually interested to feed backs not
> > necessarily restricted to encrypted resolvers.
> >
> > RFC 7858 (DNS over TLS) indicates the use of SPKI Fingerprints in an
> > analogous manner to that described in RFC7469 (public KEy Pinning
> extension
> > for HTTP). I am wondering if anyone is aware of implementation
> considering
> > SPKI Fingerprints for or if such usage is not something we would like to
> > recommend/deprecate.
>
> SPKI fingerprints are used in DANE, specifically either:
>
>     * DANE-EE(3) SPKI(1) SHA2-256(1)/SHA2-512(2) records
>     * PKIX-EE(1) SPKI(1) SHA2-256(1)/SHA2-512(2) records
>
> Since the TLSA records are published by the service operator, questions
> about stale data largely go away, modulo a small fraction of negligent
> operators (in SMTP stale TLSA records are seen for ~1% of MX hosts, but
> more importantly, only 0.0053% of DANE-enabled domains).
>
> Also, OpenSSL supports use of SPKI fingerprints for peer certificate
> verification, because "TLSA record" lookups are left up to the
> application, which feeds these into the SSL handle prior to the
> handshake.  This makes it possible to synthesise TLSA "[31] 1 [12]"
> records corresponding to an SPKI fingerprint, and use these in
> peer certificatre chain verification.
>
> Postfix, for example, has a "fingerprint" TLS "security level", in which
> the peer is authentication via a locally specified SPKI fingerprint, and
> this actually implemented on top of the OpenSSL DANE API via the above
> mentioned synthetic TLSA records.
>
> --
>     VIktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to