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

[Viktor Dukhovni <[e-mail]>]

On Tue, Feb 11, 2014 at 03:17:35PM -0700, Matt Miller wrote:

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

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.