Subject: [dane] I-D Action: draft-ietf-dane-ops-08.txt

From: [email-masked]
Date: Wed, 13 May 2015 11:26:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

        Title           : Updates to and Operational Guidance for the DANE Protocol
        Authors         : Viktor Dukhovni
                          Wes Hardaker
	Filename        : draft-ietf-dane-ops-08.txt
	Pages           : 28
	Date            : 2015-05-13

Abstract:
   This document clarifies and updates the DNS-Based Authentication of
   Named Entities (DANE) TLSA specification based on subsequent
   implementation experience.  It also contains guidance for
   implementers, operators and protocol developers who want to make use
   of DANE records.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-ops/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dane-ops-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 May 2015 18:36:14 +0000

> https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-08

This should contain the various suggested changes from the last
call comments.  If I've missed anyone's suggested changes, please
speak up.

I've still not heard anything from Paul Wouters or John Gilmore
about any additional text they might want to see in support of Raw
Public Keys (RFC 7250).  Perhaps the present text is sufficient.

-- 
	Viktor.

---

From: John Gilmore <[email-masked]>
Date: Wed, 13 May 2015 17:15:03 -0700

> Public Keys (RFC 7250).  Perhaps the present text is sufficient.

I took a brief look at the draft, and I don't think the present
text is sufficient. 

It doesn't explicitly repeal the requirement that TLSA records can
only be used with X.509 certificates.  When there's a bald statement
to that effect prominently in RFC 6698, it's not sufficient for a
minor paragraph halfway through minor section 5.1 in the middle of a
subsequent document to show a counterexample.  As courts are fond of
saying, Congress does not hide elephants in mouseholes.  Standards
committees shouldn't either.  The X.509 requirement needs to be
plainly, succinctly and obviously repealed.

I think the same is true of the RFC 6698 requirement that TLSA only be
used with TLS and https.  The port number prefix avoids confusion and
overhead when authenticating multiple protocols that are used with the
same host.

There seems to be an entire section of the draft that says it does not
represent the consensus of the WG and that maybe it belongs in a
separate document.  Section 9 is pointed out as not-conensus by
Section 12.  Why is such a section still sitting in a draft that's
supposedly in last call?

Section 9 also seems to say that if you have two valid TLSA records,
one of which specifies a full key and the other of which uses a
digest, a client can't use the one with a full key even if it is
identical to the key used in the TLS negotiation?  It also seems to
say that if the server doesn't publish any TLSA records that use the
client's favorite BetterAlg, then the client should not authenticate
the server, even if the client supports WorseAlg and the server
publishes WorseAlg TLSA records.  In general the description in
Section 9 seems very muddled.  No wonder there is no consensus on it.

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 May 2015 01:07:41 +0000

> I took a brief look at the draft, and I don't think the present

Thanks for reply.  I was hoping you'd chime in!

> plainly, succinctly and obviously repealed.

Do you have specific suggested language?  It might reduce the number
of back and forths if you're willing to make the first step in the
desired direction.  Otherwise, Wes or I will have to give it a go,
but I'm leaving on vacation on Sunday, so cycles are very limited.

> overhead when authenticating multiple protocols that are used with the

I don't see any HTTPS requirement in 6698, just TLS.  Thus, SMTP
with STARTTLS on port 25 is using TLSA records, as is XMPP.  What
additional protocols over TCP that employ certificates, but not
TLS did you have in mind?  I don't recall much discussion of that
possibility in this WG, and it certainly goes beyond RFC 7250 (still
TLS) support.  I am not opposed if the shoe fits, but I think that's
very new, and would probably need a separate draft.

> Section 12.  Why is such a section still sitting in a draft that's

It seems I neglected to remove the weasel words.  Perhaps we can
have a consensus call on Digest Agility.

> identical to the key used in the TLS negotiation?

That's certainly NOT the intention.  I guess the language needs to
be more clear.  Matching type Full(0) keys are not intended to be
skipped even in the presence of digests.  Rather, section 9 is
about agility between digest algoritms (allowing weaker algorithms to
be ignored in the presence of records with stronger algorithms).

> It also seems to
> publishes WorseAlg TLSA records.

That also NOT the intention.  Again the text applies only when BOTH
appear in the TLSA record.  The client can ignore some of the
published records when ones with a more favoured algorithm are
*present*.

This is what's implemented in Postfix, and I hope to have similar
logic in OpenSSL in the not too distant future.

I'll put together more clear language for Section 9 promptly.

Thanks again.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 May 2015 05:09:48 +0000

> I'll put together more clear language for Section 9 promptly.

Below my "signature" is a proposed rewording of Section 9.  I
believe it says the same thing it said (or at least tried to say)
all along, only much more clearly.

I'd also like to remove the "weasel words" from Section 12 that
disclaim consensus on Digest Agility.  This passed through last
with no objections and has been in the draft for quite some time.

I need guidance from the chairs on how to proceed.  [Chairs?]

-- 
	Viktor.

<t>
  While <xref target="RFC6698"/> specifies multiple digest algorithms,
  it does not specify a protocol by which the TLS client and TLSA
  record publisher can agree on the strongest shared algorithm.
  Such a protocol would allow the client and server to avoid exposure
  to any deprecated weaker algorithms that are published for
  compatibility with less capable clients, but should be ignored
  when possible.  We specify such a protocol below.
</t>

<t>
  This section defines a protocol for avoiding deprecated digest
  algorithms when these are published in a peer's TLSA RRset
  along-side stronger algorithms.  A mixture of algorithms may be
  present in server TLSA records to allow for interoperability with
  legacy or constrained clients.  In particular, this protocol never
  avoids any RRs with DANE matching type Full(0), as these do not
  employ any potentially tarnished digest algorithm.
</t>

<t>
  Suppose a server's TLSA RRset contains RRs with more than one
  digest matching type.  Suppose also that the server adheres to
  the requirements of <xref target="rrreq"/> and ensures that each
  combination of TLSA parameters contains at least one record that
  matches the server's current certificate chain (or raw public
  keys).  Under the above assumptions it suffices for the client
  to identify a most preferred digest algorithm among those published
  in the TLSA RRset, and process only records that algorithm in
  addition to any records with matching type Full(0).
</t>

<t>
  To make digest algorithm agility possible, all published DANE
  TLSA RRsets MUST conform to the requirements of <xref target="rrreq"/>.
  With servers publishing compliant TLSA RRsets, TLS clients MAY,
  for each combination of usage and selector, ignore all digest-based
  RRs except those that employ the strongest digest algorithm.  The
  client then processes only any records with matching type Full(0)
  and those with the best published digest algorithm.
</t>

<t>
  The ordering of digest algorithms by strength is not specified
  in advance; it is entirely up to the TLS client.  TLS client
  implementations SHOULD make the digest algorithm preference
  ordering a configurable option.
</t>

<t>
  TLS clients SHOULD use digest algorithm agility when processing
  the DANE TLSA records of an TLS server.  Algorithm agility is to
  be applied after first discarding any unusable or malformed records
  (unsupported digest algorithm, or incorrect digest length).  Thus,
  for each usage and selector, the client SHOULD process only any
  usable records with a matching type of Full(0) and the usable records
  whose digest algorithm is considered by the client to be the strongest
  among usable records with the given usage and selector.
</t>

---

From: nudge <[email-masked]>
Date: Thu, 14 May 2015 11:44:54 +0200

> I need guidance from the chairs on how to proceed.  [Chairs?]

Viktor,

I've slightly reworded your text for clarity:

<t>
  While <xref target="RFC6698"/> specifies multiple digest algorithms,
  it does not specify a protocol by which the TLS client and TLSA
  record publisher can agree on the strongest shared algorithm.
  Such a protocol MUST allow the client and server to avoid exposure
  to any deprecated weaker algorithms that are published for
  compatibility with less capable clients, but SHOULD be ignored
  when possible.  We specify such a protocol below.
</t>

<t>
  along-side stronger algorithms.  A mixture of algorithms MAY be

<t>
  If a server's TLSA RRset contains RRs with more than one digest 
  matching type and adheres to the requirements of <xref target="rrreq"/>
  with each combination of TLSA parameters containing at least 
  one record that matches the server's current certificate chain 
  (or raw public keys) then under these circumstances, a client MAY 
  identify its preferred digest algorithm and only process records 
  for that algorithm, in addition to any records with matching type 
  Full(0).
</t>

<t>
  To allow for digest algorithm agility, all published DANE TLSA RRsets 
  MUST conform to the requirements of <xref target="rrreq"/>. With 
  servers publishing compliant TLSA RRsets, TLS clients MAY, for each 
  combination of usage and selector, ignore all digest-based RRs except
  those that employ the strongest digest algorithm.  The client then 
  processes only those RRs plus any records with matching type Full(0)
</t>

<t>

<t>
  TLS clients SHOULD use digest algorithm agility when processing
  the DANE TLSA records of a TLS server.  Any algorithm agility MUST
  be applied after first discarding any unusable or malformed records
  (unsupported digest algorithm, or incorrect digest length).  Thus,
  for each usage and selector, the client SHOULD process only usable 
  records whose digest algorithm is considered to be the strongest, 
  as well as any records with a matching type of Full(0).
</t>

-- Thanks, Ian Maddison

---

From: John Gilmore <[email-masked]>
Date: Thu, 14 May 2015 17:56:46 -0700

> desired direction.

Sure!  I submitted a whole short I-D that had no wording EXCEPT
for this issue.  It's enclosed below.

	John

INTERNET-DRAFT                                                J. Gilmore
DANE Working Group                        Electronic Frontier Foundation
Intended status: Proposed Standard                          July 3, 2014
Expires: December 31, 2014
Updates: 6698 (if approved)

             Authenticating Raw Public Keys with DANE TLSA
                       draft-ietf-dane-rawkeys-00

Abstract

   This document standardizes how the Domain Name System can
   authenticate Raw Public Keys.  Transport Level Security now has the
   option to use Raw Public Keys, but they require some form of external
   authentication.  The document updates RFC 6698 to allow the Domain
   Name System to standardize the authentication of more types of keying
   material.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

J. Gilmore              Expires December 31, 2014               [Page 1]

INTERNET DRAFT       Raw Public Keys with DANE TLSA         July 3, 2014

   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1  Background and Introduction

   The Internet uses many kinds of encryption, and many kinds of keying
   material.  These keys are authenticated in an attempt to prove that
   the public keys used in communication are the correct keys needed to
   interact with a particular server or client across the Internet.

   The Domain Name System (DNS) [RFC1034, RFC1035] provides a globally
   distributed database for brief information about names used in the
   Internet.  The DNS Security Extensions (DNSSEC) [RFC4033, RFC4034,
   RFC4035] provide authentication for this database, proving whether
   the information in the DNS was truly published by the owner of the
   associated domain name.

   Transport Level Security (TLS) [RFC5246] and Datagram TLS (DTLS)
   [RFC6347] define a protocol that protects an Internet datastream or a
   series of datagrams from eavesdropping and modification.  They
   initially used certificates in PKIX [RFC 5280] formats to store their
   keying material, and authenticated them via a series of trust anchors
   embedded in client applications.

   Domain name system Authentication of Named Entities (DANE) provides a
   way to store application level public keys in the DNS and
   authenticate them using DNSSEC.  The DANE TLS Authentication (TLSA)
   resource record [RFC6698] initially provided authentication for the
   PKIX certificates used in TLS and DTLS.

1.1  Summary of Changes

   This document extends TLSA records to be able to authenticate more
   kinds of keying material than PKIX certificates.  Protocols can then
   use their keying material with DANE by standardizing new forms of
   TLSA records.

   As a first example of such a new form, this document extends DANE to
   provide authentication for Raw Public Keys.  Raw Public Keys are used
   in place of PKIX certificates in an extension to TLS and DTLS
   [RFC7250].  Client applications using Raw Public Keys with TLS or
   DTLS can use DNSSEC to prove whether those public keys were truly
   published by the owner of the domain name whose server they are

J. Gilmore              Expires December 31, 2014               [Page 2]

INTERNET DRAFT       Raw Public Keys with DANE TLSA         July 3, 2014

   accessing.

1.2  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2  Extending TLSA records to support non-PKIX keying material

   This document relaxes the restriction that TLSA records can only
   authenticate PKIX certificates (RFC 6698, section 1.3).  The DANE
   protocol and TLSA records can now apply to encryption keying material
   in general.  This protocol and record type continue to apply to PKIX
   [RFC5280] certificates, but new standards are free to define non-PKIX
   keying material formats.

   Wherever the term "certificate" is used in RFC 6698 to refer to
   fields in the TLSA record, this document extends it to refer more
   generally to "keying material".  Thus the "certificate usage" field
   can be thought of as a "keying material usage" field, the
   "certificate association data" can now be used as "keying material
   association data", etc.

   In addition, this document relaxes the requirement that certificate
   usage value 3 can only be used for PKIX format certificates (RFC
   6698, section 2.1.1).  Certificate usage 3 can now be used with any
   standardized keying material format.  Certificate usages 0, 1 and 2
   remain restricted to apply only to PKIX-formatted certificates in DER
   encoding [X.690].

3  Supporting Raw Public Keys in TLSA records

   This document extends the DANE TLSA record definition to allow TLSA
   records to describe raw public keys as well as PKIX certificates.
   This extension does not define any new field values; it merely
   defines how existing fields are processed when being used with raw
   public keys, such as those provided by TLS and DTLS servers.

   There are two different ways to use raw public keys in TLSA records.
   One is to store the public key itself, so that it can be accessed
   directly from the DNS.  The second is to store a hash of the public
   key, so that a public key obtained in some other way can be
   authenticated via the DNS.  These cases are distinguished by the
   matching type field in the TLSA record.

   When a raw public key is to be stored in a TLSA record, the record
   MUST specify a certificate usage / keying material usage of 3

J. Gilmore              Expires December 31, 2014               [Page 3]

INTERNET DRAFT       Raw Public Keys with DANE TLSA         July 3, 2014

   (domain-provided), a selector of 1 (SubjectPublicKeyInfo), and a
   matching type of 0.  The SubjectPublicKeyInfo structure that holds
   the public key is placed in the certificate association / keying
   material association data field.

   This SubjectPublicKeyInfo structure MUST be encoded in DER encoding
   [X.660] of Abstract Syntax Notation One (ASN.1) [X.208].  It is
   identical to the SubjectPublicKeyInfo structure that is described in
   RFC 3279 [RFC3279], which is a used as a component of PKIX
   certificates.  It is identical to the SubjectPublicKeyInfo structure
   that is used in TLSA records that use a selector value of 1 and a
   matching type of 0 to match PKIX certificates.  It contains an
   algorithm identifier, any optional parameters needed with that
   algorithm identifier, and the public key itself.

   When a raw public key (that was obtained in some other way, such as
   in a TLS or DTLS transaction) is to be merely matched by a TLSA
   record, matching type 0 MAY be used, or matching types other than 0
   MAY also be used, by placing the hash value of the
   SubjectPublicKeyInfo structure into the certificate association /
   keying material association data.

   This document extends the meaning of the certificate usage / keying
   material usage value of 3 (from RFC 6699 section 2.1.1) by defining
   how the TLSA record is used by a client communicating with a TLS or
   DTLS server that uses raw public keys.  This extension adds to,
   rather than replacing, the definition of certificate usage 3 with TLS
   or DTLS servers that use PKIX certificates.

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

4  Security Considerations

   The encoding used in the TLSA resource record for Raw Public Keys is
   identical to the encoding used to match the public key of a PKIX
   certificate.  This allows a single TLSA record to match both a PKIX
   certificate used in traditional TLS or DTLS, and to also match a Raw
   Public Key provided in extended TLS or DTLS.  This offers TLS or DTLS
   servers an easy way to interoperate with both traditional and
   extended clients.  They can use the same public and private key when
   communicating with either extended or traditional clients.

J. Gilmore              Expires December 31, 2014               [Page 4]

INTERNET DRAFT       Raw Public Keys with DANE TLSA         July 3, 2014

   Since TLSA records use a protocol type and port number as a prefix on
   the domain name, services that use Raw Public Keys on various ports
   accessed through the same domain name are free to use different
   keying material.  Using diverse keying material for different
   services can improve the robustness of the services after a key
   compromise.  For example, email service on port 25 can continue with
   full security, even after the private key protecting HTTPS service on
   port 443 has been compromised.  This is a tighter binding between
   public keys and services than that provided by PKIX certificates,
   which do not distinguish port numbers.  When PKIX certificates are
   authenticated with TLSA usages 0, 1, or 2, a PKIX certificate that
   was originally used with HTTPS could be used for a man-in-the-middle
   attack on email service as well, after its corresponding private key
   has been compromised.  This cross-port attack does not work when the
   domain name uses TLSA usage 3 to authenticate different Raw Public
   Keys (or PKIX certificates) for the different services on different
   ports.

   In the TLS and DTLS protocol, certificate types are often negotiated
   before the relevant TLSA records are available to the client.  Server
   operators who anticipate using TLSA records to authenticate the
   server should always ensure that if their server offers support for
   Raw Public Keys, then their server's domain name(s) SHOULD contain
   TLSA records that match the public key that the server offers.
   Failure to publish such TLSA records would otherwise lead to an
   authentication failure in clients that opt to use Raw Public Keys,
   even if TLSA records exist that authenticate PKIX certificates with
   usages 0, 1, or 2.  This is not an issue when Raw Public Keys are
   used with out-of-band non-DANE authentication.

   When using Raw Public Keys and TLSA records, the security of the
   domain name system records directly affects the security of the
   communications protected by TLS or DTLS.  If the domain's DNS records
   are compromised, or the DNS records that delegate name service to
   this domain are compromised, communications can be blocked,
   redirected, intercepted, or modified.  The DANE TLSA Security
   Considerations section [RFC6698] provides further details.

5  IANA Considerations

   In the IANA "TLSA Certificate Usages" registry created by Section 7.2
   of RFC 6698, the value "3" ("Domain-issued certificate") should have
   its short description changed to "Domain-issued keying material", and
   should have this document added as a reference document.

6  References

6.1  Normative References

J. Gilmore              Expires December 31, 2014               [Page 5]

INTERNET DRAFT       Raw Public Keys with DANE TLSA         July 3, 2014

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3279]  Polk, T., Housley, R., Bassham, L, "Algorithms and
              Identifiers for the Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 3279, April 2002.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6698]  Hoffman, P., Schylter, J., "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

   [RFC7250]  Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S.,
              Kivinen, T., "Using Raw Public Keys in Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", RFC 7250, May 2014

   [X.208]  CCITT Recommendation X.208: Specification of Abstract Syntax
              Notation One (ASN.1), 1988.

   [X.690]    "Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2002,
              Information technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules

J. Gilmore              Expires December 31, 2014               [Page 6]

INTERNET DRAFT       Raw Public Keys with DANE TLSA         July 3, 2014

              (DER)", July 2002.

6.2  Informative References

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

Authors' Addresses

   John Gilmore
   Electronic Frontier Foundation
   815 Eddy Street
   San Francisco, CA  94117
   United States

   EMail: [email-masked]

J. Gilmore              Expires December 31, 2014               [Page 7]

---

From: John Gilmore <[email-masked]>
Date: Thu, 14 May 2015 18:28:49 -0700

> with STARTTLS on port 25 is using TLSA records, as is XMPP.  

Right.

> What additional protocols over TCP that employ certificates, but not
> TLS did you have in mind?

Well, the obvious ones are IPSEC, OpenPGP, and SSH.  VoIP and other
chat protocols are other obvious apps, though crypto for them is
currently fragmented (partly as a result of a lack of good key
distribution).  We have people working on drafts and/or
implementations for various of these protocols, but the base document
still inappropriately says "this can only be used for TLS".

SSH has its own keying record (SSHFP, RFC 4255) but it only provides
for communicating a fingerprint, not for the actual public key.  
DANE could be used to publish the entire public key if desired; and
SSHFP doesn't seem particularly popular.  Once people get used to
publishing DANE keys for TLS, they might well be happy to publish
DANE keys for SSH too.

I thought the idea of your draft's "raw public key" text is to
eliminate the requirement for certificates, so why ask about protocols
that use certificates?  There never was a requirement for TCP,
considering DTLS doesn't use it and DTLS was in RFC 6698 (see section
3).

In general I don't think that IETF standards should be written to
limit their applicability to a single application.  In 1985 I could've
written the BOOTP spec (RFC 951) to insist that people should never
use it for anything but the narrow application it was intended for
(helping diskless workstations boot up from their server).  Happily,
Bill Croft and I didn't, and almost 10 years later, someone else built
DHCP on top of BOOTP.  Now billions of cellphones use DHCP to get an
IP address when they connect to a WiFi access point.  Why would I have
wanted to rule out that outcome?  Perhaps in some crabbed attempt to
constrain competitors so I could sell more diskless workstations?

DANE could be widely usable to provide access to crypto keys and
authentication thereof for almost ANY kind of crypto protocol.  But if
the working group that designed it insists that it's "only to be used
to support our favorite toys and no others," then people looking for a
crypto key access / authentication protocol will go elsewhere.  Who
needs the hassle of adopting a protocol where you have to fight all
the time with the designers over the simplest things?  Protocols,
especially poor ones, are easy enough for new implementers to design,
that we should put few barriers in the way of re-using an existing
protocol that has stood the test of time.

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 May 2015 05:12:48 +0000

> > TLS did you have in mind?

Sorry about that, I should have included UDP also, as TLSA records
include the transport layer protocol in the owner label, so I don't
see any reason to exclude DTLS over UDP.

> Well, the obvious ones are IPSEC, OpenPGP, and SSH.

Does it make sense to specify IPSEC keys on a port by port basis?
And if so, how does one distinguish between an application willing
to talk TLS on a given port, from an O/S stack willing to do IPsec?

This is important, because the keys are not necessarily available
to both, and client applications may insist on TLS, when the TLSA
record is hypothetically intended to be used with IPSEC.

So I'm fairly sure that IPSEC requires a separate record type (not
TLSA).  I believe Paul Wouters is doing some work on DANE and IPSEC,
so I'll further discussion to him.

Similarly, PGP is not a transport protocol, and there are separate
efforts to use DANE for S/MIME and PGP, but with new records distinct
from TLSA.

Which leaves SSH.  SSH is connecting to a transport endpoint, so
if someone wanted to standardize SSH with TLSA records (and possibly
even DANE-TA(2) CAs?), that might be possible, despite the fact
that the security protocol is neither TLS nor DTLSA.  I think such
an extension of TLSA can be added at that time if it makes more
sense to overload TLSA than introduce a dedicated RRtype.

Any security protocol that supports "2 0 1" TLSA records has to
deal with X.509 certs and trust anchors and certificate chains,
and are we really going to design more of these that are not
TLS/DTLS?  If it only supports "3 1 1" then perhaps TLSA is
not the most appropriate RRtype.

So I'm with you on DTLS, but I am rather sceptical about extending
the TLSA RRtype much more broadly.  It is easy enough to write up
a spec for a new RRtype that applies to some other (than TLS/DTLS)
transport security mechanism, and such a spec would be able to omit
features of TLSA that are a poor fit.

> SSHFP doesn't seem particularly popular.

Largely (catch-22 perhaps) because DNSSEC is not yet terribly
popular.  And there's not too much demand for ad-hoc inter-domain
SSH.  I don't SSH to google.com, but I send them email and visit
their website.

> Once people get used to

If DANE for SMTP helps to drive DNSSEC adoption, perhaps more folks
will publish SSHFP, I don't see a compelling case for TLSA with
SSH, the fingerprints are really good enough, the main obstacle is
DNSSEC not lack of support for publishing the full key.

> that use certificates?

It is to allow the use of RFC7250 raw public keys (no certificates),
but still at this time in the context of TLS (or DTLS).

> limit their applicability to a single application.

Indeed, thus DANE TLSA for SMTP, XMPP, HTTP and also application
protocols that use SRV records with TLS (IMAP, ...).

> In 1985 I could've

Many thanks for all those diskless Sun3/50's by the way!  They got
me started down my eventual career path.

> authentication thereof for almost ANY kind of crypto protocol.

Indeed, and thus there's work on SMIMEA, OPENGPGKEY, ... and
opportunities for any additional RRtypes that make sense.

So the key question is whether for a protocol that is neither TLS,
nor DTLS and wants to just use bare public keys (ditch the X.509
PKI legacy bloat) does it make sense to use TLSA records with all
their permutations of parameters, or might there instead be a new
(still application neutral) RRtype for "dane public keys"?

    _4242._tcp.newcrypto.example.com IN DANEPKEY <matching-type> <data>

in which the DANE-EE(3) and SPKI(1) are fixed and implicit?

> But if
> crypto key access / authentication protocol will go elsewhere.

Well, DANE is not just for TLS.  Rather at present, TLSA records
are just for TLS/DTLS.  So the key question is whether that's a
good fit for other use-cases.  The draft extends "3 1 1" to work
with TLS and RFC7250's bare keys, it is a start.

How would one signal which security protocol to use with a particular
transport end-point?  Having TLSA signal the use of TLS is potentially
helpful if the same application also supports other encapsulations.

> Who needs the hassle of adopting a protocol where you have to fight all

So bottom line, I am actually open to allowing "3 1 1" to be
overloaded, for non-TLS "just key" purposes, but honestly sceptical
that it is a good fit.

It would be good to explore this with a real (non-hypothetical)
use-case for an application whose designers/developers want to use
DANE for key management.  I don't see real obstacles to writing
another draft later that updates 6698 again, if that turns out to
be a fruitful direction.

At present, I think the right thing to do is to make sure that the
RFC 7250 use-case is adequately covered.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 May 2015 05:25:23 +0000

>                        draft-ietf-dane-rawkeys-00

I have read the draft, thanks.  I think that RFC 7250 raw public
keys are covered in the same way in draft-ietf-dane-ops via
usage DANE-EE(3) selector SPKI(1).

For other potential use-cases (i.e. neither TLS nor DTLS), it is
not clear how to interpret the TLSA record selector, and what the
meanings of the existing certificate usages might be.

I'd like to see some success with RFC 7250 + DANE, before we further
extend the TLSA RRtype into virgin territory.  At the very least
there should be a practical use-case against which to measure the
soundness of the proposal.

RFC7260 is a sound extension, if additional sound extensions come
along, I think they can be accomodated at that time.

So, I'd like to ask that at this time, we come to closure on whether
RFC7250 is adequately supported by the language in draft-ietf-dane-ops.
If so, let's get that out the door, and open the floor for discussion
of further extensions after that.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 May 2015 06:03:32 +0000

> I've slightly reworded your text for clarity:

Thanks, with guidance from the chairs, I'll merge as much as I can.

>   legacy or constrained clients.

I don't think that the "MAY" above needs to be in RFC 2119 language.
I had a lower case "may", in order to discuss a hypothetical.  This
is not a paragraph that *specifies* allowed server behaviour.
However, if "MAY" really is better, it does not make a great deal
of difference.

>   for that algorithm, in addition to any records with matching type 

Here (and this is not the result of your changes) we run into a
bit of trouble.  Because of the original uncertain status of the
consensus on agility, this says "MAY", but a couple of paragraphs
the text says that the client SHOULD employ algorithm agility.  We
need to pick one or the other for both paragraphs.

>   processes only those RRs plus any records with matching type Full(0)

Ditto.

>   as well as any records with a matching type of Full(0).

The above is the final "SHOULD" that is in apparent conflict with
the initial "MAYS" that explain potential strategies, which are
then upgraded from potential to "SHOULD".

So the exposition needs to lose some hedging, and state clearly
whether Digest Agility is "MAY" or "SHOULD" throughout.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 16 May 2015 05:42:11 +0000

> Thanks, with guidance from the chairs, I'll merge as much as I can.

Inspired by the proposed improvement, the below takes a stab at
further clarity and elimination of redundancy.  I realize it is
late in the process, so guidace on whether/when/how to improve
this section would be helpful.  New section 9 text below the
"signature" line.

With Section 9 ideally no longer under a cloud of uncertainty,
we would also update section 12:

    OLD:
         <t> In <xref target="agility"/>, we propose a digest algorithm
         agility protocol.  [Note: This section does not yet represent
         the rough consensus of the DANE working group and requires further
         discussion.  Perhaps this belongs in a separate document.] </t>

    NEW:
         <t> In <xref target="agility"/>, we specify a digest algorithm
         agility protocol. </t>

-- 
	Viktor.

<t>
  While <xref target="RFC6698"/> specifies multiple digest algorithms,
  it does not specify a protocol by which the client and TLSA record
  publisher can agree on the strongest shared algorithm.  Such a
  protocol allows the client and server to avoid exposure to
  deprecated weaker algorithms that are published for compatibility
  with less capable clients, but which SHOULD be avoided when
  possible.  We specify such a protocol below.
</t>

<t>
  This section defines a protocol for avoiding deprecated digest
  algorithms when these are published in a peer's TLSA RRset alongside
  stronger digest algorithms.  Note that this protocol never avoids
  RRs with DANE matching type Full(0), as these do not employ a
  digest algorithm that might some day be weakened by cryptanalysis.
</t>

<t>
  The ordering of digest algorithms by strength is not specified
  in advance; it is entirely up to the client.  Client implementations
  SHOULD make the digest algorithm preference ordering a configurable
  option.
</t>

<t>
  To make digest algorithm agility possible, all published DANE
  TLSA RRsets MUST conform to the requirements of <xref target="rrreq"/>.
  Clients SHOULD use digest algorithm agility when processing the
  peer's DANE TLSA records.  Algorithm agility is to be applied
  after first discarding any unusable or malformed records (unsupported
  digest algorithm, or incorrect digest length).  For each usage
  and selector, the client SHOULD process only any usable records
  with a matching type of Full(0) and the usable records whose
  digest algorithm is considered by the client to be the strongest
  among usable records with the given usage and selector.
</t>

<t>
  Example: a client implements digest agility and prefers SHA2-512(2)
  over SHA2-256(1), while the server publishes an RRset that employs
  both digest algorithms as well as a Full(0) record.
</t>

  <figure>
  <artwork>
_25._tcp.mail.example.com. IN TLSA 3 1 1 (
                              3FE246A848798236DD2AB78D39F0651D
			      6B6E7CA8E2984012EB0A2E1AC8A87B72 )
_25._tcp.mail.example.com. IN TLSA 3 1 2 (
                              D4F5AF015B46C5057B841C7E7BAB759C
			      BF029526D29520C5BE6A32C67475439E
			      54AB3A945D80C743347C9BD4DADC9D8D
			      57FAB78EAA835362F3CA07CCC19A3214 )
_25._tcp.mail.example.com. IN TLSA 3 1 0 (
                              3059301306072A8648CE3D020106082A
			      8648CE3D0301070342000471CB1F504F
			      9E4B33971376C005445DACD33CD79A28
			      81C3DED1981F18E7AAA76609DD0E4EF2
			      8265C82703030AD60C5DBA6FB8A9397A
			      C0FCF06D424C885D484887 )
  </artwork>
  </figure>

<t>
  In this case the client SHOULD accept a server public key that
  matches either the "3 1 0" record or the "3 1 2" record, but
  SHOULD not accept keys that match only the weaker "3 1 1" record.
</t>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 21 May 2015 16:08:35 -0400

> we would also update section 12:

We have heard nothing from the working group saying that they are
unhappy with the new section 9, and it seems clear.

>          <t> In <xref target="agility"/>, we specify a digest algorithm

The Working Group reviewed this document, and we called consensus on
it (and then waited a bit to see if anyone came out of the woodwork,
looking sad), and so I believe that this *does* have WG consensus, and
so the [Note:...] can be removed.

W

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 21 May 2015 22:24:29 +0000

> unhappy with the new section 9, and it seems clear.

And yet the language is somewhat muddy and repetitive, and confused
at least John Gilmore about what it was trying to say.  Furthermore
Section 12 disclaims consensus, but I think we should reach concensus
on digest agility (if we have not yet).

> so the [Note:...] can be removed.

Thanks.  I'll remove the note, but I would very much like to improve
the clarity of the section 9 text (without changing the technical
content).   I have such an update queued-up.  How might we proceed
to adopt it?

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 22 May 2015 13:34:06 -0400

> content).   I have such an update queued-up.  How might we proceed

Does anyone have any useful clarity improvement suggestions?
We'll wait until 12:00PM UTC on Wednesday (20:00ET), otherwise we'll
go ahead with the text as written, and ask Viktor to include it.

W

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 23 May 2015 08:17:59 +0000

> go ahead with the text as written, and ask Viktor to include it.
  
Multiple updates were posted list.  The latest one is on github:

https://github.com/vdukhovni/ietf/commit/d67149f19893d76bf5a716d982211d3f52d40509?diff=split#diff-6232fbcb795dbe385e4d6b7436795328

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 25 May 2015 20:32:08 -0400

> go ahead with the text as written, and ask Viktor to include it.

<no hats>
... I have some very small grammar / readability suggestions.

Take them if you like them, or ignore if you don't....

------

<t>

[O]: Such a protocol allows the client and server
  [P]: Such a protocol would allow the client and server
  [C]: We haven't specified the protocol yet, so different tense for
readability.

<t>

[WK] ... we hope -- or we have some *serious* issues. :-P

<t>
  The ordering of digest algorithms by strength is not specified
  in advance; it is entirely up to the client.  Client implementations
  SHOULD make the digest algorithm preference ordering a configurable
  option.
</t>
[O]: The ordering of digest algorithms by strength is not specified
  in advance; it is entirely up to the client.  Client implementations
  SHOULD make the digest algorithm preference ordering a configurable
  option.
  [P]: While all clients SHOULD implement ordering of digest algorithms
  by strength, each client is free to decide upon the order of digest
algorithms,
  from strongest to weakest. Client implementations SHOULD make the digest
  algorithm preference ordering a configurable option.
  [C]: The original paragraph is unclear as to whether the client can choose the
  order of the algorithms or whether the client can choose to implement this
  feature at all.

<t>

<t>

  <figure>
  <artwork>

<t>

-----
</no-hats>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 26 May 2015 23:24:12 +0000

> Take them if you like them, or ignore if you don't....

I'll post a new version later today (I'm in Australia today,
so for most of you, my later today will be your tomorrow).

-- 
	Viktor.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 26 May 2015 19:24:25 -0600

> so the [Note:...] can be removed.

Although I wouldn't call this a "protocol" since it describes desirable 
client behavior and not an over-the-wire negotiation, the proposed text 
seems fine to me.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 27 May 2015 11:45:02 +0000

> so for most of you, my later today will be your tomorrow).

Done, please confirm that diffs are acceptable.

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 27 May 2015 15:02:52 -0400

LGTM.