Subject: [dane] Stapling DNSSEC/DANE

From: Nico Williams <[email-masked]>
Date: Tue, 28 Jul 2015 13:11:31 -0500

I doubt this is the right list to send this to, but might as well start
here and move this elsewhere as needed.

My proposal for stapling DNSSEC/DANE is as follows:

 - Use a DNS response whose answer is the TLSA RRset and whose
   additional section contains all the DNSSEC RRsets needed to validate
   the answer, chaining all the way to ., of course.

One can already get such responses from caching validating resolvers, so
producing these is easy.

Validating them requires a library, but ideally we could define a
protocol to speak to caching validating resolvers for validating stapled
DNSSEC, my proposal for which is:

 - Send the stapled DNSSEC response as a query that the caching
   validating resolver must then respond to with an error if it does not
   validate, or with an answer that contains just the answer RRset
   (which must match the query).

   Caching validating resolvers would be allowed to also ignore the
   answer and additional RRs in the query and instead answer the
   question as usual.  Clients would have to check the response to make
   sure they got the same TLSA RRset as stapled.

Obviously this would work for RRs other than TLSA.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Jul 2015 19:17:05 +0000

>    the answer, chaining all the way to ., of course.

Except that multiple answer RRs might need validation when there
are CNAMEs from the original domain to the TLSA base domain, and
possible CNAMEs from the prefixed (_port._prot) TLSA base domain
to the ultimate TLSA record.

All the CNAME records need to be validated, not just the final
TLSA RRset.

> Obviously this would work for RRs other than TLSA.

The protocol would have to return AD=1 and all the RRs from the
query in the answer section.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Jul 2015 17:05:22 -0500

> All the CNAME records need to be validated, not just the final

Sure.  The CNAMEs should be in the answer section too, no?  Though it'd
be OK if they were in the additional section.  The point is that all of
them have to be in there.  An alternative would be to have multiple DNS
responses, one for each CNAME and one for the TLSA RRset.  The latter
might be necessary if 64KB is not enough to store the entire stapling.
Thoughts?

> query in the answer section.

Yes.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Jul 2015 22:15:57 +0000

On Tue, Jul 28, 2015 at 05:05:22PM -0500, Nico Williams wrote:

> Sure.  The CNAMEs should be in the answer section too, no?

Yes, in the answer section.  Otherwise it is difficult for the
client to navigate the response from its reference identifier domain
(signalled via a mandatory SNI extension) to the actual TLSA RRset
in the server's answer (which may be two layers of CNAMEs away).

	server-name0. -> server-name1. -> ... -> server-name-N. == tlsa-base-domain.
	_port._proto.tlsa-base-domain. -> ... -> _ultimate._tlsa.owner-name.
	_ultimate._tlsa.owner-name. IN TLSA 3 1 1 <blob>

Both CNAME chains and the TLSA RRset go in the answer section, all
supporting RRSIG/DNSKEY/DS records are additionals.  There's a
draft from Shore, Huque et. al., that is evolving, ideally to spell
out all the details.

> might be necessary if 64KB is not enough to store the entire stapling.

The data will need to (and I expect will) fit into 16K so, it can
go into a TLS handshake message.  To that end, and in any case,
the extension should I think support DNS name "compression", and
should be encouraged to do use it (the draft says otherwise at
present).

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 28 Jul 2015 19:45:14 -0400

On Tue, Jul 28, 2015 at 6:15 PM, Viktor Dukhovni <[email-masked]>
wrote:

> out all the detail.

In case others missed it, it's the following draft:

    https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-01

Debate is going on about the precise format of the chain data. The draft
currently doesn't use DNS "messages", but rather wire format DNS RRs
wrapped in a bit of TLS presentation syntax, but we're discussing other
possibilities. If we were to use DNS messages, there is already a proposal
from Paul Wouters which we might also look into:

   https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-02

I've already stated my personal preference for a chain of wire format DNS
RRs that could be fed into existing DNS library functions, but I'd like to
come to a consensus that is acceptable to most of the likely implementers.
One concern we've heard is that some folks don't want to import a large DNS
library into their application that has a whole of bunch of unnecessary
code (e.g. all the DNS transport code).

> should be encouraged to do use it (the draft says otherwise at
Right, it says to uncompress the names right now. Name compression is
defined in terms of pointers to offsets from the beginning of the DNS
message. Since we don't currently use DNS messages, we'd have to redefine
name compression to be something else, like an offset from the beginning of
the chain data structure. That would probably be fine, but I wonder if it's
really worth it. The size of the chain is likely going to be dominated not
by domain names, but by all the DNSSEC signatures, which aren't very
compressible.

Another method of reducing the chain size we are considering is client side
caching of RR sets and server side omission of the same.

Shumon.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 28 Jul 2015 15:54:13 -0800

> should be encouraged to do use it (the draft says otherwise at

Adam's original proposal included a name compression mechanism
(Adam Langley wrote the initial draft a few years ago, and we've
picked it up with his blessing).  We decided to drop it because
it adds some complexity (and the possibility of error) with
questionable benefit, given that signatures are going to be the
bigger consumer of space in the extension.

Melinda

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Jul 2015 23:57:04 +0000

> by domain names, but by all the DNSSEC signatures, which aren't very

Well, certainly the signature and DNSKEY fields don't compress very
well, but there are still lots of domain names floating around.

With ECC signature algorithms (which I hope will eventually be the
dominant algorithms in DNSSEC), the key and signature fields are
much smaller, making it possible for name compression to make a
non-trivial difference.

Also if the response is in DNS wire format, it becomes easier to
just punt the packet for verification to the local validating
resolver (jailed inside a captive portal and fed crumbs of useful
work to do by applications forwarding data from remote TLS servers).

With care the server's response might already be in the form of
the appropriate query (or possibly new DNS opcode), so that the
client can just copy it to 127.0.0.1:53 after a quick syntax check,
and wait for a response.  That would be a much simpler approach
than compiling DNS logic into each and every application.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Jul 2015 23:57:52 +0000

> bigger consumer of space in the extension.

See my follow-up message.  I think you should reconsider.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Jul 2015 18:59:17 -0500

>     https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-01

I had, yes.  Thanks for the pointer.

> from Paul Wouters which we might also look into:

I much prefer using DNS messages, yes.

> come to a consensus that is acceptable to most of the likely implementers.

A wire-format response could be fed to a library too.  And to a
validating resolver.

The point is that the protocol to the local caching validating resolver
*is* the API.

That's because light-weight non-validating resolver libraries to speak
to it are universally available.

And because the local caching validating resolver is the best place to
cache.

(A caching validating resolver might find a lot of the signatures and
validations thereof cached.  The caching validating resolver may not
want to cache stapled DNSSEC even if it's valid to avoid cache poisoning
issues, but it could still pay to cache the validations.)

Resolver libraries are nice, but mostly only for when one cannot ensure
that there is a local caching validating resolver, or when one cannot
trust it, or when one is building a local caching validator.

> code (e.g. all the DNS transport code).

Exactly.  See above.

> by domain names, but by all the DNSSEC signatures, which aren't very

And the public keys.

> caching of RR sets and server side omission of the same.

Sure, you can omit keys and signatures nearer to the root.

Nico
--

---

From: Melinda Shore <[email-masked]>
Date: Tue, 28 Jul 2015 16:03:12 -0800

> See my follow-up message.  I think you should reconsider.

Nothing's cast in concrete, and your point about ECC signatures
is well-taken.  We'll likely get a revision out by the end of
August.  Because this is a TLS extension we'll be working with
the TLS working group, and it's not clear at this point what
sort of biases they'll have that are different from the
preferences of DNS experts.

Melinda

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Jul 2015 19:03:30 -0500

> than compiling DNS logic into each and every application.

Well, relying party would have to check that the header is right (or
replace it), but yes, this, exactly this.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Jul 2015 00:24:45 +0000

> Sure, you can omit keys and signatures nearer to the root.

Only if a client with a slightly warm cache, can tell the server
a list of ancestor domains (of the server domain) for which it
already posesses in its cache already validated DS/DNSKEY records.

But this carries some risk, as a .com server A can insert into a
client's cache valid, but somewhat stale keys for .com, which can't
validate the response from .com server B (signed with more fresh
keys).  In all likelihood, such optimization is too difficult to
get right, and should be avoided.

The only optimization is when a client already has recent TLSA
records for the server, and just avoids asking for the extension
entirely.  That gets most of the benefit, with least complexity.

-- 

	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Jul 2015 00:35:58 +0000

> preferences of DNS experts.

I think that the payload of the extension really needs to be vetted
by folks with DNS expertise, and the TLS WG review mostly focused
on where the extension goes in the handshake, whether its payload
is in the clear or not, whether (as I think should be the case)
SNI is a pre-requsite to signal which domain the server starts the
validation chain from, ...

This is based in part on the architectural assumption that in many
cases the right way to process it on the client side will be a
hand-off a local DNS service.

I would also posit that also on the server, obtaining the requisite
payload might be obtained by constructing appropriate new requests
to the local DNS service (which likely has all the relevant data
in its cache).

The design of the payload should not preclude delegation of the
work of building it to a DNS service on either end.  Of course if
either initially (for lack of supporting DNS services) or through
explicit design choice, some implementations prefer to do everything
in an application library, so be it, they can then construct the
appropriate DNS-compatible payload messages.  Libraries to do so
are likely not too hard to find.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Jul 2015 20:21:57 -0500

> preferences of DNS experts.

Why should their biases be all that different from ours?

A TLS implementor could want to implement a DNS resolver from scratch,
but since they'll need to deal with DNS the protocol, why should
stapling DNSSEC as a DNS response be difficult for them?

Or a TLS implementor could want to use an off-the-shelf DNS
implementation, in which case it wouldn't be hard to use a DNS
response as the container for the stapled RRs.  In the best case
the TLS implementaor can just feed the response as-is (see previous
posts), whereas with any other encoding there's no such best-case.

Existing code would make a difference.  I'm aware of AGL's stapled
DNSSEC code, but that's one implementation -- it'd have to be a
widely-used implementation to make that big a difference.

More than that, I object to each protocol coming up with its own
stapling format.  Whatever is good for protocol X, ought to be good for
protocol Y.  A proliferation of DNSSEC stapling containers would only
serve to make implementors sad.

Nico
--

---

From: Melinda Shore <[email-masked]>
Date: Tue, 28 Jul 2015 17:26:16 -0800

> hand-off a local DNS service.

I think the primary concern about that is the possibility
of introducing additional latency, given that we're trying
to minimize the DANE performance hit on clients like browsers,
who tend to be extremely sensitive to delay.  We probably
need clearer discussion about what we're trying to optimize
for.  But in either case, whether we're using a resolver
in a DNS library or handing it off to a service, encoding
the records in DNS wire format is going to be easiest for
implementers.  Several people have talked about writing
their own bare-bones resolver that does not use an entire
DNS library but I don't have any sense that that's going
to be a common case.  It's worth talking to people working
with highly constrained devices in any event.

Thanks,

Melinda

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Jul 2015 01:48:40 +0000

On Tue, Jul 28, 2015 at 05:26:16PM -0800, Melinda Shore wrote:

> who tend to be extremely sensitive to delay.  

I expect that the latecy to reach 127.0.0.1 is quite low.  And will
only be incurred intermittently (client-side validated TLSA RRset
cache).  When I say "local DNS service", I really mean *local*.

> But in either case, whether we're using a resolver

The question is not only whether individual RRs are in wire format
(which we already agree on), but whether the entire payload is a
DNS packet with all the usual headers and sections.  At present
the draft departs from that format, and there is some merit in
considering whether that's wise.

There are perhaps compelling reasons to serialize the multiple RRs
differently, but I think they really ought to be *compelling* to
trump the potential advantages of using the existing DNS format.

The tricky bit is what DNS opcode should be in the DNS header for
such a payload.  Potentially, something new that constitutes a
request for validation of a set of RRsets (from the answer section)
via supporting RRSIG/DNSKEY/DS records (from the additional section).

Nameserver implementors would then ideally support the new opcode,
allowing applications to defer most of the work to the *local*
(127.0.0.1, ::1) nameserver.

Client libraries would then just need to parse the validated answer,
to make sure that the CNAME chains are pertinent (not merely
authentic), and the TLSA records match the server certificates.

Support for this should ultimately (or immediately) migrate from
application code to TLS toolkit code, with the application asking
the TLS library to enable DANE stapling support as appropriate.
(Some applications, not suffering from last-mile problems, will
simply perform their own DNS lookups, often against the same
127.0.0.1 nameserver that is not locked up in a captive portal).

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Jul 2015 23:50:54 -0500

> to minimize the DANE performance hit on clients like browsers,

It's got to be roughly comparable to the WebPKI performance hit.  In
fact, it will be better because there is no CRL/OCSP for DNSSEC.  There
may be a few more signatures to check in the DNSSEC case, since it's a
proper PKI, so there may be no performance difference.

> with highly constrained devices in any event.

Well, I've made a barebones resolver out of the traditional BSD/ISC
resolver library as a base.  It's almost cheating, yes, but I spent a
fair bit of time cleaning and modernizing decades-old code.  My codebase
still doesn't handle async resolution, but it will, and all in all it's
rather simple and small -- small because it relies on a local caching,
validating resolver.  The hard part is all in the latter.

This is not an approach everyone can take: because a local caching,
validating resolver daemon is not universally guaranteed to be present.
But a local caching, validating resolver ought to be always present:
it's the best place for caching that can be trusted by the user.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Jul 2015 23:57:58 -0500

> trump the potential advantages of using the existing DNS format.

Right, because firstly the DNS message format is in widespread use
(understatement of the month), and secondly because anyone wishing to
use DNS to the loopback resolver as the validation API will appreciate
not having to re-encode the thing, and thirdly because anyone trying to
obtain a stapled DANE payload will appreciate being able to use DNS to
the loopback resolver as the API for obtaining it.

DNS is such a stable and universal protocol that it is an API.  That's a
huge benefit.

> via supporting RRSIG/DNSKEY/DS records (from the additional section).

Whatever the stapler puts in, the relying party has to check/coerce the
header to be as the loopback resolver will expect.  There is no need to
parse the rest of the stapled response, as the local resolver daemon
ought to be secure and less-privileged than the relying party.

Yes.

> authentic), and the TLSA records match the server certificates.

And note: only the header and the answer section, since the signatures
will have been validated and therefore of no further interest.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Jul 2015 08:45:03 +0200

Sounds familiar :)

Sent from my iPhone

> On Jul 28, 2015, at 20:11, Nico Williams <[email-masked]> wrote:
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Jul 2015 12:01:28 -0500

On Tue, Jul 28, 2015 at 05:26:16PM -0800, Melinda Shore wrote:
> who tend to be extremely sensitive to delay.  [...]

This is probably worth going over in some detail.

Where there is no last-mile problem the client will do best to issue
async DNS lookups for all the records it needs, and this will probably
be faster than stapling.  But the client won't always know (especially
if it's mobile) when stapling is the only thing that will help, so
stapling we must.

When stapling is needed there is no latency hit on the server (of
course), and the only latency hit on the client is a) the time to
transmit the stapled data (server-to-client), b) the time to transmit
the stapled data (client-to-resolver-daemon), c) the time to validate
the stapled data, d) having to wait until all the stapled data is
available to begin validation.  (a) and (c) are present whether we
staple or not, and (b) is negligible (loopback networking).  There's a
negligible win in not having to send requests.  That leaves just (d):
having to wait for the stapled data.  But (d) is the same for DANE as
for WebPKI/PKIX, which leaves us with... nothing that adds latency by
comparison to WebPKI/PKIX.

The case where client can speak DNS itself is a win compared to
WebPKI/PKIX because the client can asynchronously do some of the trust
chain validation work before getting the stapled data from the server.
Stapling DNSSEC/DANE is no different than the server sending its
certificate chain to the client and needs to be compared to just that,
not just to stapling of OCSP Responses.

If there's a latency hit, it will be when a sever has both, a long PKIX
certificate chain and a long DNSSEC/DANE RRset chain to send (since both
have to be transmitted, and the client may end up having to validate
both).  Operators should avoid this.

In any case, I don't see how the encoding of the RRsets affects latency
except that using a DNS message is a win for those who use DNS to a
local resolver daemon as the validation API.  Using a DNS message is
neutral for all other implementors.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Jul 2015 17:38:48 +0000

> both).  Operators should avoid this.

This raises an interesting point.  

On the one hand the server cannot do much about the length of X.509
certificate chain, it is what it is, and clients may indeed need
to validate "both" (the X.509 chain and its supporting TLSA records
with supporting DNSSEC signatures, keys, ...).

On the other hand, if the TLSA records in question are DANE-TA(2)
or DANE-EE(3), then if the client's extension requesting stapled
TLSA RRs can be interpreted by the server as a reliable signal that
client is doing DANE-TLSA authentication, the server may well be
able to "truncate" its X.509 chain to just those certificates needed
to match the TLSA records.  

In particular, with matching DANE-EE(3) TLSA record, the server
might send only the leaf certificate without any intermediate CA
certificates.  While with a matching DANE-TA(2) TLSA record, the
server might send a chain that extends only as far as that trust-anchor
certificate and no furhter.  If that trust-anchor is a root CA,
this is actually longer than what might have been sent with PKIX
(see the draft-ietf-dane-ops section 5.2).  If however, that
trust-anchor is issued by some intermediate CA, then the chain
required to validate ala-DANE is shorter than the PKIX chain (even
sans root CA).

I don't know whether it is appropriate for the extension draft to
discuss such potential (bandwidth) optimizations.  The code that
I wrote to validate DANE chains certainly ignores any certificates
beyond the leaf with DANE-EE(3) and beyond the trust-anchor with
DANE-TA(2).

So the optimization opportunity is there, but we'd have to declare
that a client sending the extension effectively commits to using
DANE and forgoes the option of using the full PKIX chain (when a
shorter chain suffices for DANE, i.e. the TLSA RRs contain exclusively
certificate usage DANE-EE/DANE-TA not PKIX-EE/PKIX-TA).

If the optimization is "blessed", then it might even be the case
that at times the leaf certificate plus TLSA RRset with evidence
is shorter than the PKIX chain (if the RRSIGS are EC-based).

This brings us to another point, the server can't know whether its
domain is even DNSSEC-signed in the eyes of the client.  The client's
supported DNSSEC signature algorithms are not sent in the client's
extension.  Whether the server "optimize" or not, there's not much
point sending a pile of TLSA RRs, and associated RRSIG/DNSKEY/DS
records, if some DS RRset needed to validate the response lists no
algorithms supported by the client.

It might make sense to change the client portion of the extension
to send a list of the client's supported DNSSEC algorithm numbers.
On the other hand, clients that hand-off the validation to the
local resolver (as suggested in recent threads) might not always
know which algorithms are supported by that resolver.  That would
have to be client configuration, or something the client can ask
the resolver via an EDNS option of some sort.

So lots of additional fun corner cases to mull over...

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Jul 2015 13:22:31 -0500

On Wed, Jul 29, 2015 at 05:38:48PM +0000, Viktor Dukhovni wrote:
> > If there's a latency hit, it will be when a sever has both, [...]
> 
> [...optimization discussion elided...]
> 

An "extension" may be where the stapled DANE data goes.  That doesn't
mean that it's an "extension" in the sense that you're thinking.
Arguably this is core functionality for TLS.

Still, I'd advise for specifying and implementing this optimization, but
I'd make it OPTIONAL to implement.  It's only an optimization.

Yes.

> is shorter than the PKIX chain (if the RRSIGS are EC-based).

Quite likely.  Plus there's no need for OCSP stapling, nor CRL checking.
So in fact DANE stapling will be a net win.

> to send a list of the client's supported DNSSEC algorithm numbers.

Agreed.

> the resolver via an EDNS option of some sort.

Good point.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Jul 2015 16:56:52 -0500

> https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-02

Excellent.  Now I don't have to write that :)

Now all we need is a document somewhere explaining how to use DNS (to
the local caching resolver daemon) as an API.  That needn't be an IETF
document, of course.

Nico
--