This is a supplemental AppsDir review of draft-ietf-dane-protocol (for
background on AppsDir, please see
<http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate>).

Although Murray Kucherawy has already reviewed this I-D on behalf of
the AppsDir, folks in the Applications Area realize that wide
deployment of the TLSA Resource Record might have a significant impact
on applications, so we are performing additional reviews. Please treat
these comments just as you would any other Last Call feedback.

Document: draft-ietf-dane-protocol
Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol
for Transport Layer Security (TLS)"
Reviewer: Peter Saint-Andre
Review Date: 2012-04-24
IETF Last Call Date: 2012-04-25
IESG Telechat: not yet scheduled


Summary: This draft is almost ready for publication as an Standards
Track RFC but has a few issues that should be fixed before publication.


Major Issue: none, although a) I am agreeing with Peter Saint-Andre's 
major issue and b) I would like to see a reply to my minor issues

Minor Issues:

2.2.  TLSA RR Presentation Format

    The presentation format of the RDATA portion is as follows:

Presentation for what purpose? In management UIs? Is this a required 
presentation format for DNS tools that can retrieve and update TLSA records?

  [...]

    o  The certificate association data field MUST be represented as a
       string of hexadecimal characters.  Whitespace is allowed within
       the string of hexadecimal characters.

Please define what you mean by whitespace here? CR & LFs allowed?
Examples in the Section 2.3 seem to suggest that.

3.  Domain Names for TLS Certificate Associations

    2.  The protocol name of the transport on which a TLS-based service
        is assumed to exist is prepended with an underscore character
        ("_") to become the second left-most label in the prepared domain
        name.  The transport names defined for this protocol are "tcp",
        "udp" and "sctp".

DCCP? Should there be a registry?

4.  Use of TLSA Records in TLS

    Section 2.1 of this document defines the mandatory matching rules for
    the data from the TLSA certificate associations and the certificates
    received from the TLS server.

    The TLS session that is to be set up MUST be for the specific port
    number and transport name that was given in the TLSA query.

So this will not work for any type of DNS indirection mechanism, such as 
MX, SRV, etc? Or does DNS retrieval of such records also requires DNSSec?


Nits:

4.  Use of TLSA Records in TLS

    If a TLSA record has usage type 2 for the certifcate, the

typo: certificate

    corresponding TLS server SHOULD send the certificate that is
    referenced just like it currently sends intermediate certificates.


    If an application receives zero usable certificate associations from
    a DNS request or from its cache, it processes TLS in the normal
    fashion without any input from the TLSA records.

Just to double check: if TLS client receives some TLSA records, but none
of them are usable, is this considered to be the above case?

    If an application
    receives one or more usable certificate associations, it attempts to
    match each certificate association with the TLS server's end entity
    certificate until a successful match is found.  During the TLS
    handshake, if none of the certificate associations matches the
    certificate given by the TLS server, the TLS client MUST abort the
    handshake.