Re: [TLS] draft-shore-tls-dnssec-chain-extension-00

[Melinda Shore <[e-mail]>]

Thanks for the detailed review, Viktor.  Some of the
issues you've raised are still things we're hashing
through, and we're grateful for your clarifications.
We'll be getting a new draft out before document
submission closes and it will incorporate some of
your suggestions.

On 6/29/15 10:25 PM, Viktor Dukhovni wrote:
> Similar considerations apply to server-to-server XMPP traffic.
> Thus the extension in question is only relevant with protocols
> where TLS (with authenticaiton) is mandatory, and DANE is a
> potentially attractive alternative PKI.  With opportunistic DANE
> TLS, the extension is inevitably too late.

Right now our main use case is https, as browser vendors
are extremely sensitive to increased latency in connection
establishment, and anything we can do to help that can
make it easier to argue for implementation.  We have,
though, been talking about other application protocols,
including XMPP, but haven't worked through the details.
In particular we haven't looked at opportunistic DANE usage.
We'll add some text clarifying that this extension would
be inapplicable in those cases.

> Speaking of RRsets, are the RRs in each RRset returned by the server
> required to be sorted in canonical order?

That's one of the things we've been discussing.  One of the
things that's been driving our decisions so far has been
implementation considerations, and in particular how to
deliver the data needed for validation to a validator
that's part of a DNS API.

> 4.  I think the Section 4 SNI interaction would be a lot cleaner,
> if SNI is mandatory for clients that use the proposed extension.
> In which case the server can only respond with a leaf TLSA RRset
> (and chain of RRSIG/DNSKEY/DS/... records) whose "base domain" (
> see section 3 of RFC6698 and soon definition of TLSA base domain
> in draft-ietf-dane-ops-13 (later this week)).  Using some random
> name for the server's IP address is not a good idea IMHO.  PTR
> records are too often poorly correlated with the client's notion
> of the target server name.

Right, and we actually changed that back and forth a few times.
It's not clear to us that SNI is being used across all applications
using TLS.  I think that generally we're going to need guidelines
for application developers.

> 6.  Note that the soon up for IESG review draft-ietf-dane-ops
> considerably revises the DANE verification logic for TLSA certificate
> usage DANE-EE(3).  Section 6 should refer to draft-ietf-dane-ops-12
> (soon -13 which responds to AD and GEN-ART comments) as well as
> RFC6698.

Okay, thanks.

> is sub-optimal, it should refer to a TLSA RRset, which MUST contain
> at least one TLSA record that matches the server's certificate
> chain, but will often contain additional records that do not.

That's another issue we're currently working through.  We'll
have some more thoughtful text in the next revision.

> 8.  Great care must be taken (with Certificate usages other than
> DANE-EE(3)) to ensure that the TLSA record matches a certificate
> that is actually part of the server's chain and not just some random
> unrelated certificate that happens to be present in the server
> certificate message.  Many implementors fail to check this.

Good point, thanks.

> 9.  This draft should reiterate the requirement that with certificate
> usage DANE-TA(2), the server MUST include the trust-anchor certificate
> in its certificate message even if that trust-anchor is self-signed
> (root CAs are NOT optional with DANE-TA(2)).

Ditto.

> 10.  Validation of RRSIGs is a subtle art, the client will definitely
> need to check not only the signatures but also the validity intervals
> of all RRSIGs (the client must trust its own clock or have access
> to a trusted time source).  Since the server forwards wire-format
> RRsets, these include TTLs, and clients might plausibly cache these,
> provided the TTLs are consistent with the RRSIG validity intervals.
> The draft might provide guidance on any client-side caching (clients
> might e.g. not even send the extension when they have unexpired
> cached TLSA data from a previous interaction with the server).

Will do, but I'm not sure this will make it into the next
revision in much detail, given time constraints.  But yes,
I agree it should go into the document in greater detail
in the future.

Thanks again,

Melind


-- 
Melinda Shore
No Mountain Software
[e-mail]

"Software longa, hardware brevis."