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

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 30 Jun 2015 06:25:18 +0000

On Mon, Jun 29, 2015 at 09:13:21PM -0800, Melinda Shore wrote:

> Please have a look at it and get comments or suggestions
> to us.  We're planning on getting one more revision out
> prior to the Prague meeting, and on having a test
> implementation available in Prague.
> The draft is available at:
> https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-00

1.  There's a more compelling reason than stated why the extension is
not well suited to MTA to MTA SMTP.  With MTA to MTA SMTP DANE is
opportunistic, (START)TLS is optional unless a requirement for
authenticated signalled via TLSA records.  

Such signalled cannot be postponed to the TLS handshake, because
that handshake may not even take place unless the SMTP client MTA
knows that TLS is required.  Even if TLS were to be used, authentication
is generally not required in MTA to MTA traffic, so the extension
would be vulnerable to MITM attacks.

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.

2.  That said, the extension is a potentially good fit for MUA to
MSA submission, and XMPP user-agent (client) to first-hop XMPP
server, where the user agent statically enforces TLS, and generally
connects to a single fixed server it can reasonably authenticate.

3.  I'm not sure what purpose the last paragraph of section 3 is
intended to serve:

   Obviously, an authentication chain will be most compact and easiest
   to verify if each RRset has a single record, i.e., if there is a
   single DNSKEY RR and a single DS RR at each step.  In addition, as
   suggested above, keeping zone cuts to a minimum also reduces the
   length of the authentication chain.

The TLS server has no choice but to return the complete RRset for
each owner name class and RRtype, since RRSIGs cover RRsets, not
individual RRs.  So "compacting" is possible.  The server returns
the RRsets exactly as published by the relevant DNS(SEC) servers.

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

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.

5.  In Section 5, the server MUST not violate DNS TTLs.  The last
senetence:

    Alternatively, it could be configured to rebuild the chain at some
    predefined periodic intervals.

is I fear too much rope.  Sure the server can periodically flush
its cache (using shorter than possible TTLs), but this does not
free it of the obligation to not extend TTLs by relying exclusively
on a cache lifetime of its own choosing.

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.

7.  The draft often says "TLSA record" when it needs to say "TLSA
RRset".  It will be quite common for multiple TLSA RRs to be present
in the RRset, as this is required to correctly effect key rotation.
Therefore, in Section 6 (and elsewhere), text such as the below:

   If the record is correctly authenticated, the client then performs
   DANE authentication according to the DANE TLS protocol [RFC6698].

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.

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.

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

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

11.  Finally, Shumon Huque (mostly) and I (helping out) are writing
a draft to specify DANE TLSA for client authentication.  If and
when that progresses (WG adoption, ...), there may need to be a
similar extension, allowing a client to forward its DNSSEC-validated
TLSA RRset.  This is not an immediate priority and can be re-evaluated
later.

-- 
	Viktor.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 30 Jun 2015 13:10:21 -0800

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.

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

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

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

> (soon -13 which responds to AD and GEN-ART comments) as well as

Okay, thanks.

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

> certificate message.  Many implementors fail to check this.

Good point, thanks.

> (root CAs are NOT optional with DANE-TA(2)).

Ditto.

> 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
[email-masked]

"Software longa, hardware brevis."

---

From: Shumon Huque <[email-masked]>
Date: Tue, 30 Jun 2015 23:27:15 -0400

On Tue, Jun 30, 2015 at 2:25 AM, Viktor Dukhovni <[email-masked]>
wrote:

Thanks Victor. I'll add a few to Melinda's earlier comments ..

> the RRsets exactly as published by the relevant DNS(SEC) servers.

Yeah, section 3 needs a bit of work. Also, the order of record (sets) in
the given example doesn't match the dnssec_chain structure definition -
that should be fixed in the next rev. The structure will likely undergo
some additional changes too, e.g. names that involve CNAME/DNAMEs might
need an authentication tree rather than a single authentication chain, or a
sequence of authentication chains.

> required to be sorted in canonical order?

It would be nice to do so, but not essential - as long as the validator
sorts them canonically before signature verification.

> of the target server name.

I agree with this.

> on a cache lifetime of its own choosing.

I agree that is a bit of rope. The first part of the section does tell the
validator to do the right thing. The alternative (which would be simpler to
implement) was provided for cases where the server operator might know the
TTLs and signature validity periods of the chain above it (assuming they
are stable), and be able to select a suitable regeneration interval below
them. But yes, it provides more opportunity for doing the wrong thing by
selecting the wrong interval. Note that the original draft suggested
something similar (regenerating the stapled chain into an X.509 cert at
some predefined interval).

> TLSA RRset.  This is not an immediate priority and can be re-evaluated

I posted a link to the draft separately on the dane list. But for TLS folks:

    https://tools.ietf.org/html/draft-huque-dane-client-cert-00

-- 
Shumon Huque