Subject: [dane] I-D Action: draft-ietf-dane-srv-04.txt

From: [email-masked]
Date: Tue, 11 Feb 2014 14:13:20 -0800

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           : Using DNS-Based Authentication of Named Entities (DANE) TLSA records with SRV and MX records.
        Authors         : Tony Finch
                          Matthew Miller
                          Peter Saint-Andre
	Filename        : draft-ietf-dane-srv-04.txt
	Pages           : 13
	Date            : 2014-02-11

Abstract:
   The DANE specification (RFC 6698) describes how to use TLSA resource
   records in the DNS to associate a server's host name with its TLS
   certificate.  The association is secured with DNSSEC.  Some
   application protocols use SRV records (RFC 2782) to indirectly name
   the server hosts for a service domain (SMTP uses MX records for the
   same purpose).  This specification gives generic instructions for how
   these application protocols locate and use TLSA records when
   technologies such as SRV records are used.  Separate documents give
   the details that are specific to particular application protocols.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-srv-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-04

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: Matt Miller <[email-masked]>
Date: Tue, 11 Feb 2014 15:17:35 -0700

Viktor (and DANE),

Peter and I believe this revision addresses all of your feedback.
Please let us if anything is missing or inconsistent.

Also added an SRV example for the expected records, updated
referenced, and author information.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

On 2/11/14, 3:13 PM, [email-masked] wrote:
> 
> 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           : Using DNS-Based Authentication of Named Entities
> (DANE) TLSA records with SRV and MX records. Authors         : Tony
> Finch Matthew Miller Peter Saint-Andre Filename        :
> draft-ietf-dane-srv-04.txt Pages           : 13 Date            :
> 2014-02-11
> 
> Abstract: The DANE specification (RFC 6698) describes how to use
> TLSA resource records in the DNS to associate a server's host name
> with its TLS certificate.  The association is secured with DNSSEC.
> Some application protocols use SRV records (RFC 2782) to indirectly
> name the server hosts for a service domain (SMTP uses MX records
> for the same purpose).  This specification gives generic
> instructions for how these application protocols locate and use
> TLSA records when technologies such as SRV records are used.
> Separate documents give the details that are specific to particular
> application protocols.
> 
> 
> 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.
> 
> _______________________________________________ I-D-Announce
> mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft
> directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 11 Feb 2014 23:34:03 +0000

> referenced, and author information.

The draft seems to use "indeterminate" in the sense of RFC 4033,
where-in there is no trust-anchor for the domain or any of its
ancestors.  Unfortunately, there is a conflicting definition in
RFC 4035, which I am told is more appropriate in this context.

All 4035-style "indeterminate" results (and "bogus" results) are
essentially lookup errors and must treated as such. See section
2.1 of the SMTP draft.  As for 4033-style indeterminacy it is indeed
to be treated as equivalent to "insecure".

For DANE-EE(3) CU records to have meaningful semantics for the
publisher.  For example for a publisher to use the same certificate
for many SRV hosts or without worrying about using a matching name,
the use of non-use of name checks must be specified precisely.

Therefore I would suggest that the "MAY be ignored" in the second
paragraph of section 5, should be changed to "MUST be ignored".
Otherwise, the published TLSA records have unknown semantics.

When the service domain is the head of a CNAME chain, with the SRV
record obtained after indirection via at least one CNAME RR, the
SMTP and ops drafts specify that name checks must include both the
service domain and its full CNAME expansion (in addition to any
SRV target host name).

The SMTP draft also specifies that servers MUST not refuse to
complete the TLS handshake when no certificate matching the SNI
name is present.  Rather they must then present the default
certificate, because clients may be willing to match other names
in addition to that sent in the SNI extension.

- In the first paragraph of 4.2, change "as describes" to "as described".

- In the third paragraph of 5. change "the the 'to' address" to
  eliminate the duplicate "the".

-- 
	Viktor.

---

From: Matt Miller <[email-masked]>
Date: Wed, 12 Feb 2014 10:32:03 -0700

On 2/11/14, 4:34 PM, Viktor Dukhovni wrote:
>> Peter and I believe this revision addresses all of your
>> feedback. Please let us if anything is missing or inconsistent.
>> 
> ancestors.  Unfortunately, there is a conflicting definition in RFC
> 4035, which I am told is more appropriate in this context.
> 
> essentially lookup errors and must treated as such. See section 2.1
> of the SMTP draft.  As for 4033-style indeterminacy it is indeed to
> be treated as equivalent to "insecure".
> 
> publisher.  For example for a publisher to use the same
> certificate for many SRV hosts or without worrying about using a
> matching name, the use of non-use of name checks must be specified
> precisely.
> 
> service domain and its full CNAME expansion (in addition to any SRV
> target host name).
> 
> certificate, because clients may be willing to match other names in
> addition to that sent in the SNI extension.
> 

Thank you for the feedback, Viktor.  These comments make sense to me.
We'll try to get an update out before the cutoff to address them.

- -- 
- - m&m

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 12 Feb 2014 19:54:13 +0000

On Wed, Feb 12, 2014 at 10:32:03AM -0700, Matt Miller wrote:

> > DANE-EE(3) CU records need to have meaningful semantics for the 

> We'll try to get an update out before the cutoff to address them.

Thanks.  You could mention that both name checks and key usage are
effectively handled by the TLSA record for DANE-EE(3).  The TLSA
record binds the certificate or public key to the requested port
and protocol at the TLSA base domain, the binding is clearly for
a TLS server, so there is an implicit key usage of TLS server.
Finally, the RRSIG expiration date sets the expiration time of the
TLSA "pseudo-certificate".  A requirement to ignore the certificate
content gives the publisher flexibility (e.g. same certificate for
multiple SRV hosts, ...).

There will be some overlap between the SRV draft and the SMTP draft.
I expect that's not a problem, provided they agree.

-- 
	Viktor.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 12 Feb 2014 21:25:43 +0100

> I expect that's not a problem, provided they agree.

I got a complaint on that type of overlap in the dispatch wg on my sip-dane draft.

I haven't had time to look into it, but the feedback was that some of it was copied, some of it actually belonged in the SRV draft. As I am new to the draft-writing business I look for guidance here.

/O

---

From: Matt Miller <[email-masked]>
Date: Wed, 12 Feb 2014 13:39:18 -0700

On 2/12/14, 12:54 PM, Viktor Dukhovni wrote:
>>> certificate for many SRV hosts or without worrying about using
>>> a matching name, the use of non-use of name checks must be
>>> specified precisely.
> 
>>> Therefore I would suggest that the "MAY be ignored" in the
>>> second paragraph of section 5, should be changed to "MUST be
>>> ignored". Otherwise, the published TLSA records have unknown
>>> semantics.
>> 
>> Thank you for the feedback, Viktor.  These comments make sense to
>> me. We'll try to get an update out before the cutoff to address
>> them.
> 
> and protocol at the TLSA base domain, the binding is clearly for a
> TLS server, so there is an implicit key usage of TLS server. 
> TLSA "pseudo-certificate".  A requirement to ignore the
> certificate content gives the publisher flexibility (e.g. same
> certificate for multiple SRV hosts, ...).
> 

Section 5 (after I change the "MAY" to a "MUST") already states that
matching a DANE-EE(3) TLSA bypasses the rest of the certificate checks
(paragraph 2), but the current wording might be too clumsy.  I'll see
what I can wordsmith to make it more explicit.

I could also add something about the RRSIG expiration, but isn't that
already covered by RFC4035 § 5.3.1 (bullet 5)?

> There will be some overlap between the SRV draft and the SMTP
> draft. I expect that's not a problem, provided they agree.
> 

- -- 
- - m&m

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 12 Feb 2014 21:08:13 +0000

> what I can wordsmith to make it more explicit.

It is only a question of how much you feel it is appropriate to
provide a rationale for this requirement and in how much detail
you want to provide it.

> already covered by RFC4035 ? 5.3.1 (bullet 5)?

I don't know that RFC 4035 specifically talks about imputing a TLS
server key expiration time from a DNS RRSIG expiration time, but
per the above comment, it is largely a question of whether you want
to explain why it is OK to ignore the "3 X Y" certificate content
and get everything you need from DNSSEC.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Wed, 12 Feb 2014 23:54:56 +0100 (CET)

Viktor Dukhovni wrote:
> Matt Miller wrote:
> effectively handled by the TLSA record for DANE-EE(3).

I'm sorry, but this simply isn't true today, I do not believe that
this is (nor should be) the intention of DANE, and I'm strongly
opposed to changing that part of the implementations.

DANE it self is about an alternative means to establish (a chain of) trust
to a peer entity, and the usage type 3 only overrides the server endpoint
identification that was originally described in rfc2818 section 3.1

  http://tools.ietf.org/html/rfc2818#section-3

and is described in a more elaborate fashion in rfc6125

  http://tools.ietf.org/html/rfc6125

DANE does NOT invalidate the keyUsage checks and requirements that are
normally part of TLS itself and described here:

  http://tools.ietf.org/html/rfc5246#page-56

There are a number of TLS protocol stacks that will check the
KeyUsage of X.509 certificates that are conveyed through TLS certificate
handshake messages, independent of how the application caller decides
to perform server endpoint identification and how the application caller
determines its trust.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 12 Feb 2014 23:28:14 +0000

> opposed to changing that part of the implementations.

No name checks for CU-3 IIRC was discussed and agreed many months ago.

There is no "true today" for DANE, as there are in effect no "real"
DANE implementations aside from the one in Postfix (I've looked at
some experimental implementations, but they are all incomplete and
often insecure).

The requirement to not do name checks, EKU checks, date checks for
DANE is satisfied by the Postfix DANE implementation, and will be
satisfied by the OpenSSL implementation on which I'm collaborating
with one of the OpenSSL developers.

This requirement makes it possible to use a single certificate to
work with multiple TLSA base domains, substantially simplifying
virtual hosting.  (See the ops draft).  Thus it substantially
enhances the usability of DANE.

The effective chain of trust for a server public key with DANE CU-3
is the chain of DNSKEY and DS RRsets starting at the relevant DNSSEC
trust anchor.  There are no X.509v3 trusted parties with CU-3 whose
signature on a leaf certificate validates the certificate content.
In fact with "3 1 1" the holder of the public key is free to replace
the certificate with any certificate for the same public key,
setting new dates, new names, ...

> identification that was originally described in rfc2818 section 3.1

I thought DANE stood for "DNS-Based Authentication of Named Entities".
With CU-3 TLSA RRset binds a port/protocol at a named transport
endpoint (the name is the TLSA base domain) to the corresponding
public key or public-key certificate.

Since this binding already takes care of naming the entity (with
more specificity than one typically finds in X.509v3 certificates),
establishes the validity interval of the binding, and via the
DNS RR type (TLSA, SMIMEA, ...) implies a suitable usage, there
is nothing left for the (untrusted content beside the public
key with "3 1 X"!) certificate to specify.

Since the certificate is redundant, and ignoring is a major
improvement in the deployability of DANE, the only reasonable thing
to do is to ignore the CU-3 certificate content (except to the
extent required to compare it with the TLSA association data).

> DANE does NOT invalidate the key Usage checks and requirements that are

Those other documents assume that the content of the certificate
is from a trusted authority.  This is true for CU in {0, 1, 2},
but false for CU=3.

If the server operator wants to cease using a CU=3 certificate, he
should publish new TLSA RRs and deploy a new certificate (with due
care about key roll-over, see the ops draft).  There is no need for
clients to enforce expiration when the server is far better positioned
to do so.

> Key Usage of X.509 certificates that are conveyed through TLS certificate

This is not relevant, they don't do DANE.

When they do DANE, which needs to be supported by the TLS library,
as application-only DANE support is actually rather difficult, they
will handle CU=3 appropriately.

The Postfix DANE implementation uses very low-level OpenSSL features,
and essentially bypasses or duplicates or fools the existing
OpenSSL verification code to accept DANE chains.

Implementations will have to change to properly support DANE.
Expecting application to correctly implement DANE support would
lead to precisely the problems I've seen with every single current
experimental DANE verifier I've seen.  They're all flawed.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Sat, 15 Feb 2014 07:53:46 +0100 (CET)

Viktor Dukhovni wrote:
> Martin Rex wrote:
>> Viktor Dukhovni wrote:
>>> 
>>> You could mention that both name checks and key usage are

I'm sorry for having been so unclear.  I wasn't objecting to
the "name checks" part here, only to the "both ... and key usage".

> some experimental implementations, but they are all incomplete and

This is about TLS implementations.  Keep in mind that the server does
not even need to know about DANE at all -- anyhow the server WILL
be acting on the KeyUsage in his very own certificate and drive
the choice of cipher suites based on the KeyUsage requirements

> is from a trusted authority.  This is true for CU in {0, 1, 2},

Nope.

Defective implementations excepted, the TLS protocol engine will
look at the KeyUsage attribute of the Server certificate and check
the cipher suite selection for compatibility -- and the application
call will NOT have a say in this.

> with one of the OpenSSL developers.

You should not confuse EKU checks on the leaf certificate with
KeyUsage checks on the leaf certificate.  EKU checks on the leaf
certificate are extremely application specific, and simply undefined
for the majority of application protocols.
TLS itself (rfc2246,rfc4346,rfc5246) is entirely ignorant of EKU,
and so is HTTP-over-TLS (rfc2818).

Browser vendors together with CAs have defined semantics for EKUs
that browsers (but not necessarily generic TLS libs and programmatic
HTTP clients) will typically check, such as the two
id-kp-serverAuth and id-kp-clientAuth from PKIX(rfc5280)

  http://tools.ietf.org/html/rfc5280#page-45

Curiously, these EKUs are primarily a PKIX obsession, TLS just doesn't care.
And PKIX has defined these two serverAuth and clientAuth purposes with
an extremely narrow semantics:  "TLS WWW server authentication"
and "TLS WWW client authentication", which means that these would
explicitly *NOT* apply to something like "TLS SMTP authentication"
or "TLS SIP authentication", "TLS POP/IMAP authentication",
"TLS XMPP authentication", etc.

Whether a TLS server or TLS client will act on the expiration of an
X.509 server certificate is also implementation dependent, and similarly,
the application caller (that is using DANE for establishing trust),
may not get a say in that.  That is particularly true for the server-side
which may not necessarily see/use any DANE code.

I would really appreciate if you would refrain from suggesting to
create and use bogus X.509 certificates with DANE, _including_ CU=3.
DANE is an alternative means to establish trust, and for
CU=3 it additionally shortcuts/omits the name checks.  But not more.
If you desperately want naked keys, join Paul Wouters in his effort
to get that working with TLS.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 15 Feb 2014 16:44:47 +0000

> from the quoted part of the TLS spec:

The CU=DANE-EE(3) requirements in the SMTP and SRV drafts apply
ONLY to the verifier, i.e. the client.  The server does not perform
a lookup of its own TLSA RRs, ... and just sits there and does TLS.
The only server-side TLS requirement with DANE is a requirement on
the server operator to configure the server to include the root CA
in the server certificate message when the server operator configures
TLSA records with CU=DANE-TA(2) to specify trust in a root CA.

In particular the server is quite free to enforce keyUsage or other
policy, ... on itself.  It is up to the server operator to make
sure the server does not commit "TLS suicide" by deciding its own
private keys and certificate chain are no longer suitable for TLS.

> call will NOT have a say in this.

You seem to be wedded to the idea that DANE support will be in
application code and not in "TLS engine code".  Having actually
implemented a complete DANE verifier, I can assure you that there
will be very few applications indeed that attempt to do this.

DANE will only be adopted by applications when it is implemented
in the TLS engine, and applications can just tell the TLS engine
the server name/protocol/port or perhaps provide the relevant TLSA
records and list of acceptable server names and ask the TLS engine
to do all the work.

> which may not necessarily see/use any DANE code.

Again a statement of the view that DANE in the TLS client is outside
the TLS engine.  DANE changes the semantics of the server certificate
chain and needs to augment the chain processing in the TLS engine.

> CU=3 it additionally shortcuts/omits the name checks.  But not more.

I am not suggesting that servers create "bogus" certificates.  I
am requiring *clients* with CU=DANE-EE(3) to ignore the certificate
content except to the extent needed to match the certificate with
the TLSA certificate association data field.

The reason for this is that the most frequent (and essentially
only) source of failure I observed in a decade of being a postmaster
at large site that in fact applied PKIX secure-channel policy to
some peer domains was certificate expiration.  There was nothing
appreciably more wrong with the peer domain's certificate, the day
after it expired than the day before.  Just an operational oversight.

With DANE "IN TLSA 3 ? ?" we have an opportunity to move the
expiration time outside the certificate, where it is difficult
to change (requires someone to replace the server chain before
a fixed future date).  When the expiration time is in DNSSEC,
it extends automatically every time the same zone file content
is re-signed.  No unplanned outages.

The server operator is free to plan key/cert roll-over whenever it
is convenient, independently of any artificial horizon in the
server's certificate.  Moving expiration out of the certificate
will be the most important thing we can do to promote use of TLS!

With many servers to manage, operations teams hate certificate
expiration!  Invariably some server is forgotten and is updated
after an outage.

With DANE "3 ? ?" the server operator can use the certificate
expiration as in an input to a self-audit tool that reminds him
to replace the certificate when convenient, but failure to do so
is no longer a problem for either the client or the server.

> to get that working with TLS.

This would only work when all the TLSA RRs in the RRset are
"DANE-EE(3) SPKI(1) ?".  If any other TLSA RRs are present it is
not safe to signal support for bare keys.  And of course bare key
support in TLS engines is some years away.  I am not prepared to
wait that long.

Handling a mixture of certificates and bare keys makes APIs rather
more complex, and breaks backwards compatibility.  So I don't expect
that DANE clients that support X.509 chains will bother to signal
support for bare keys any time soon.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Mon, 17 Feb 2014 14:30:57 +0100 (CET)

Viktor Dukhovni wrote:
> application code and not in "TLS engine code".

That isn't my idea, that is a fundamental part of the architecture
of TLS, described in every existing TLS specification at the end
of section 1, Introduction.

  http://tools.ietf.org/html/rfc2246#page-4

                        The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS. 

>
> Having actually implemented a complete DANE verifier, I can assure
> you that there will be very few applications indeed that attempt
> to do this.

We know painfully well just how poor apps are in doing certificate
verification:
 "The most dangerous Code in the World"
 http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

A number of TLS protocol implementations come with utility functions
to make the task easier for applications to consume TLS.

The model how server endpoint identites are checked in HTTP-over-TLS,
as described in rfc2818, is a matter of the application from the
TLS protocol perspective.  Leaving the checking of certificates
entirely to applications is what leads to the problem described in
above paper.

The situation with DANE is very much alike.  DANE does not change
anything about how TLS works, it only changes how applications make
use (including certificate (parh) validation) of the certificates
exchanged within the TLS protocol.

It is likely that TLS implementation will add support for DANE to
the the set of utility functions that are supposed to facilitate
consumption of TLS for applications.  DANE is *NOT* part of TLS,
and it will be the task of application to actually have the checks
performed.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Feb 2014 18:15:33 +0000

> to make the task easier for applications to consume TLS.

We should not descend into a scholastic debate of the fine details
of where the boundary lies between "TLS engine code" and library
code that performs related functions on behalf of the application.

Both TLS protocol processing and certificate trust chain verification
a la DANE, will need to be provided by a complete SSL/TLS toolkit
to enable its applications to employ DANE.  DANE will require
various changes in those toolkits, some of those might be in the
protocol engine some in the related functions.

This said, my intention with DANE-EE(3) semantics is not necessarily
to preempt various features of the EE certificate that are not
covered by the TLSA record.  Rather, my goal was to make sure that
the TLSA record content is not trumped the content of the certificate
(whose signer is not even trusted since we're not checking any PKIX
trust chain).

We've already agreed that name checks are more than adequately
handled by the implied binding with the port, protocol and server
name in the TLSA base domain.

Beyond that, I'd like to make sure that also the validity interval
is from DNSSEC (no sudden failure so long the DNS zone continues
to publish a matching TLSA RR).  Similarly, RFC 5280 extended Key
Usage (sequence of KeyPurposeId) is superseded by the RRtype (TLSA)
to imply an acceptable purpose of id-kp-serverAuth.

So I can live with a weaker requirement, if that settles the issue.
With DANE-EE(3):

    - No PKIX signature verification.  Covered by TLSA association
      data field, and in any case we don't have a trusted issuer
      whose signature can be checked.  [ Obvious. ]

    - No name checks based on certificate content.  Covered
      by TLSA (service, protocol, base domain) triple.  [ Already agreed. ]

    - No expiration checks based on certificate content.  Covered
      by TLSA RRset's RRSIG expiration time.	[ Still under discussion. ]

    - No purpose checks based on extended key usage.  Covered by
      TLSA RRtype.	[ Still under discussion. ]

If there are other elements of the certificate potentially relevant
to the TLS protocol engine, any related functions or the application,
I can live with that.

It was my purpose to make the requirement as simple as possible,
and ignoring everything in the certificate is much simpler to
state than ignoring a subset.

In particular I have no objection to TLS protocol engines complying
with the keyUsage bits from:

    http://tools.ietf.org/html/rfc5280#section-4.2.1.3

Of the two "Still under discussion" fields, the expiration is by
far the most important for the operational success of DANE.  By
far the most common problem is expired certificates, and with
DANE-EE(3), we have an opportunity to eliminate this problem.
There is no more expiration, rather TLSA records are withdrawn from
DNS by the server operator once the certificate is no longer
appropriate (for whatever reason).  

The server operator should of course audit deployed certificates
and may use the expiration date as a reminder to rotate keys, but
with DANE-EE(3) I think it makes much more sense to leave the timing
of key rotation to the server operator, not the client.

-- 
	Viktor.