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

From: [email-masked]
Date: Thu, 19 Dec 2013 08:07:10 -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.
	Author(s)       : Tony Finch
                          Matthew Miller
                          Peter Saint-Andre
	Filename        : draft-ietf-dane-srv-03.txt
	Pages           : 12
	Date            : 2013-12-13

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-03

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

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: Thu, 19 Dec 2013 17:30:27 +0000

> 	Filename        : draft-ietf-dane-srv-03.txt

Section 5 (no exception for usage 3):
Section 7 (MUST and SHOULD on server name are too strong):
Section 10.3 (no exception for usage 3):

This still conflicts with the smtp-with-dane and ops drafts with
respect to name checks (server identity checks) in usage 3.  In
the two conflicting documents usage 3 certificates are validated
exclusively by matching against DANE TLSA RRs.  No name checks,
key usage checks, expiration checks, ... apply with usage 3.  Rather,
the binding of the EE certificate to the service end-point is
entirely established by the DNSSEC TLSA record (also its validity
lifetime is the lifetime of the TLSA record).

Correspondingly, all requirements on the content of the server
certificate are relaxed with usage 3, it may, if desired, contain
no identity information.  For example, given the following TLSA
record:

    _25._tcp.mail.example. IN TLSA 3 1 1 \
	4D8CC746810AB5C7D7D24EE2A78AA6D5 \
	687E5CCA54A85846DAACD71E1B172F00

the below would be a valid certificate (which is, absent DANE,
anonymous and never valid):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: 
        Validity
            Not Before: Dec 19 17:16:51 2013 GMT
            Not After : Dec 18 17:16:51 2013 GMT
        Subject: 
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub: 
		    ...
                ASN1 OID: prime256v1
    Signature Algorithm: ecdsa-with-SHA256
	...
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xMzEyMTkxNzE2NTFaFw0x
MzEyMTgxNzE2NTFaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARIR1J5ykq+
0/4O7VBur2Sv9tgrMvql0kzZzuaMxyFWxbL9bNtkT3zcjrXHVxdhZOZLZo9Fs5AI
MW+zRCwxNcbbMAoGCCqGSM49BAMCA0gAMEUCIFkPVySlkXTbg6mlEUbDGrABN+a2
V9aZR87f+1X+JKydAiEAwlccNJAVHQmkU5kVelXbx8UsVc66Q8Qt6QrT1L5Xg10=
-----END CERTIFICATE-----

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 19 Dec 2013 17:43:09 +0000

> 	Filename        : draft-ietf-dane-srv-03.txt

Another point I should raise is the question of when to perform
TLSA lookups.  In implementing DANE for Postfix, I found that it
is unwise to search for TLSA RRs for an MX host whose hostname ->
address mapping is insecure (that is when the MX RRset is in a
secure zone, but the MX host is not).

The example I posted to this group was nist.gov's MX RRset:

    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
    nist.gov. IN MX      0 nist-gov.mail.protection.outlook.com.

    ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
    nist-gov.mail.protection.outlook.com. IN A    207.46.163.170
    nist-gov.mail.protection.outlook.com. IN A    207.46.163.215
    nist-gov.mail.protection.outlook.com. IN A    207.46.163.247
    nist-gov.mail.protection.outlook.com. IN A    207.46.163.138

    $ dig +dnssec +noall +comment +ans -t tlsa nist-gov.mail.protection.outlook.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14224
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 512

Attempts to retrieve the TLSA RRset SRVFAIL.  Postfix (as likely
should all other applications that want to find TLSA RRs) skips
the TLSA lookup when the MX (form of SRV) host's zone is not secure.

-- 
	Viktor.