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.
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
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?
4. Use of TLSA Records in TLS
If a TLSA record has usage type 2 for the certifcate, the
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
apps-discuss mailing list