[dane] Extending TLSA RFC to operate with TLS's new raw public keys

John Gilmore <gnu@toad.com> Thu, 29 May 2014 08:05 UTC

Return-Path: <gnu@toad.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE761A0789 for <dane@ietfa.amsl.com>; Thu, 29 May 2014 01:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.245
X-Spam-Level:
X-Spam-Status: No, score=0.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrItuA9Od8ZX for <dane@ietfa.amsl.com>; Thu, 29 May 2014 01:05:26 -0700 (PDT)
Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C481A070D for <dane@ietf.org>; Thu, 29 May 2014 01:05:25 -0700 (PDT)
Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s4T85HBT008757; Thu, 29 May 2014 01:05:17 -0700
Message-Id: <201405290805.s4T85HBT008757@new.toad.com>
To: dane@ietf.org, gnu@toad.com
Date: Thu, 29 May 2014 01:05:17 -0700
From: John Gilmore <gnu@toad.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/XrZllETsL1WdFi6vTpWADQph8YQ
Subject: [dane] Extending TLSA RFC to operate with TLS's new raw public keys
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 May 2014 08:05:27 -0000

The TLS Working Group is in the final stages of approving RFC 7250,
"Using Raw Public Keys in TLS/DTLS":

  https://www.rfc-editor.org/authors/rfc7250.txt

The draft modifies the TLS protocol to allow clients and servers to
negotiate and exchange types of authentication material other than
PKIX certificate chains, and defines a format for exchanging a raw
public key.  These public keys are authenticated "out of band",
outside the TLS protocol, for example by prior administration (in some
Internet-of-Things cases), or by the use of DANE.  Paul Wouters was
the main author, and the protocol and document were significantly
improved by several co-authors from the TLS WG.

In reviewing the draft, I noticed that it doesn't ever describe how
you store such a public key in a TLSA record.  And the TLSA RFC 6698
explicitly specifies that TLSA records can ONLY store PKIX
certificates!  The relevant sections are:

RFC 6698 Sec. 1.3:

   This document only applies to PKIX [RFC5280] certificates, not
   certificates of other formats.

RFC 6698 Sec. 2.1.1:

   The certificate usages defined in this document explicitly only apply
   to PKIX-formatted certificates in DER encoding [X.690].  If TLS
   allows other formats later, or if extensions to this RRtype are made
   that accept other formats for certificates, those certificates will
   need their own certificate usage values.

I remember fighting this fight in the DANE WG, and the result was
something along the lines of "We'll narrow the RFC now, and then
if-and-when raw public keys are approved by the TLS WG, then we'll
amend it to include them."  Well, the time has come.  Raw public keys
are approved by the TLS WG.  The trouble is that nobody has bothered
to amend the TLSA RFC, so the new draft RFC tells people "just use
DANE", but the DANE TLSA RFC says, "No you can't".

I propose to add some text to the draft RFC 7250 that extends RFC 6698
by defining how raw public keys are stored in TLSA records.

My coauthors seem to prefer that we just ignore the entire issue,
issue RFC 7250, and ignore the conflict between the two.  As someone
who learned most of what I know about protocols (and the Internet)
from reading Saint Jon Postel's clearly written RFCs, I would hate to
inflict that on future readers.  We should not release documents that
contain deliberate incompatabilities.

We think RFC 7250 is ready to go except for this remaining issue.  It
has been approved by the TLS WG, the IESG, the RFC Editor, and all the
co-authors but me.

Here's my proposed wording change for RFC 7520.  Improvements welcome.
Start from this version:

  https://www.rfc-editor.org/authors/rfc7250.txt

Section 4.4.
OLD (entire section):
   When the TLS server has specified RawPublicKey as the
   server_certificate_type, authentication of the TLS server to the TLS
   client is supported only through authentication of the received
   client SubjectPublicKeyInfo via an out-of-band method.

NEW (entire section):
   When the TLS server has specified RawPublicKey as the
   server_certificate_type, authentication of the TLS server to the TLS
   client is supported only through authentication of the received
   client SubjectPublicKeyInfo via an out-of-band method.

   In order to support out-of-band authentication via DANE [RFC6698],
   this document extends the DANE TLSA record definition to allow such
   records to describe raw public keys as well as PKIX [RFC5280]
   certificates.  This extension does not define any new field values;
   it merely defines how existing fields are processed when being
   matched to raw public keys provided by TLS servers.

   A raw public key is represented in a TLSA record by specifying a
   certificate usage of 3 (domain-provided), a selector of 1
   (SubjectPublicKeyInfo), and a matching type of 0.  The
   SubjectPublicKeyInfo that holds the public key is placed in the
   certificate association data.  Matching types other than 0 may also
   be used, by placing the corresponding hash value into the
   certificate association data.

   DANE [RFC6698] section 1.3 is extended to say:

      This document only applies to raw public keys and to PKIX
      [RFC5280] certificates, not certificates of other formats.

   DANE section 2.1.1 is extended to say:

      The certificate usages 0, 1 and 2 defined in this document
      explicitly only apply to PKIX-formatted certificates in DER
      encoding [X.690].  If TLS allows other formats later, or if
      extensions to this RRtype are made that accept other formats for
      certificates, those certificates will need their own certificate
      usage values.

   In DANE section 2.1.1, in addition to the definition of certificate
   usage 3 with TLS servers that use PKIX certificates, certificate
   usage 3 may also be used with TLS servers that use raw public keys:

      3 -- Certificate usage 3 is also used to specify a raw public key
      that MUST match the raw public key presented by the server in
      TLS.  When the TLS server provides a raw public key, there is no
      PKIX certificate and no PKIX validation is done; the TLS
      server's raw public key MUST match the raw public key provided in
      the TLSA record.  This certificate usage is sometimes referred
      to as "domain-issued" because it allows a domain administrator
      to directly certify a domain's public keys.

I believe that this wording reflects the up-to-now tacit consensus on
how the DANE WG expects TLS raw public keys to be represented and
processed in TLSA records.  In the absence of significant dissent or
further improvements, I propose to provide the above updates to the
RFC Editor and release the new RFC.

	John