Re: [TLS] SPKI Fingerprints

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 13 June 2022 15:55 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4096DC14F742 for <tls@ietfa.amsl.com>; Mon, 13 Jun 2022 08:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atW1YE1mlUQ0 for <tls@ietfa.amsl.com>; Mon, 13 Jun 2022 08:55:48 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35B1C14CF05 for <tls@ietf.org>; Mon, 13 Jun 2022 08:55:48 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 20080F724E; Mon, 13 Jun 2022 11:55:46 -0400 (EDT)
Date: Mon, 13 Jun 2022 11:55:46 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <YqdeAqGn+ecCa5sp@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <CADZyTk=vwyPk2y_VSJ_Mi2G6rAOE8ht24xXkgm_q+9QKdLs70w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADZyTk=vwyPk2y_VSJ_Mi2G6rAOE8ht24xXkgm_q+9QKdLs70w@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-W9VTTyUJnvuFeTwdiZtTf-e3bo>
Subject: Re: [TLS] SPKI Fingerprints
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jun 2022 15:55:53 -0000

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.