Subject: [TLS] draft-shore-tks-dnssec-chains-extension

From: Paul Wouters <[email-masked]>
Date: Wed, 22 Jul 2015 07:45:17 -0400 (EDT)

I do like the dnssec-chain-extension.

I think the server should stick to one chain, from the root to itself,
so it does not have to deal with variable chain blobs per client.
That will allow server code to stick to something like hourly
regenerating the blob for use with all clients.

I do strongly prefer the binary blob to be in raw dns format. That
will make parsing easier with existing code, and over time we will
not run into issues where dns libraries support newer algorithms
but this specific dnssec parsing code isn't updated.

The DNS answer packet format can contain many DNS records in the
Additional Section, without requiring any new DNS data format (and note
edns-query-chain also does not specify a new format). I would be fine
with stating the order of the additional records should be top down,
to make validation easier, although probably the TLSA record and RRSIG
itself should appear in the DNS Answer Section.

As for ekr's question on why not stuff this inside X.509, that would not
be compatible with tls raw pulic keys that only contain a SBKI, and drag
back into the protocol more ASN.1 parsing and containers.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Jul 2015 17:16:22 +0000

>From the root to its own TLSA RRset, however, this can be complicated
in the presence of CNAMEs:

	www.example.com. IN CNAME cdn.example.net.
	cdn.example.net. IN A 192.0.2.1
	_443._tcp.cdn.example.net. IN CNAME _dane.example.net.
	_dane.example.net. IN TLSA 2 0 1 <trust-anchor-digest>

In this example, three leaf RRsets need to be verified back to the
root (with notable overlaps in the chains):

	www.example.com. IN CNAME <RDATA>
	_443._tcp.cdn.example.net. IN CNAME <RDATA>
	_dane.example.net. IN TLSA <RDATA>

How should these be organized?  It seems to me that the immediate
answer that gets the client going in the right direction is the
first CNAME, which enables to construct the TLSA base domain,
and then to follow the second CNAME to the ultimate TLSA RRset.

Should everything other than the first CNAME be in additional
records?  Should all the above (with their RRSIGs) be in the answer
section, with the union of the supporting DNSKEY/RRSIG/DS records
as additional?

I tried to ask a related question during the meeting, but bandwidth
to explain the context was limited:  Should proofs of non-delegation
be included, to keep gTLDs and ccTLDs honest for some future CT for
DNS?  Specifically, suppose you see:

	_443._tcp.www.example.com. IN TLSA <rrdata>

with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3
records that demonstrate that "example.com" (and www.example.com)
are not delegated?  (Such records might then be subject to "gossip"
or related "transparency" counter-measures).

> but this specific dnssec parsing code isn't updated.

I'm not sure what "algorithms" you have in mind?  We should perhaps
allow (even encourage) "compression" to reduce the payload size,
this would require the client to "uncompress" (canonicalize) all
the RRs before checking the RRsigs.  Once canonicalized, DNSSEC
signature checks don't care how the canonical forms of each RRset
were constructed, and the wire form (which is not canonical) is
not more compatible with new signature algorithms than any other
representation.

> back into the protocol more ASN.1 parsing and containers.

This really can't go in the certificate, because then certificates
would have to be updated as often as RRSIGS are regenerated.  That
seems exceedingly unlikely to be deployable.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 22 Jul 2015 17:23:39 -0400 (EDT)

> records?

I think so.

>  Should all the above (with their RRSIGs) be in the answer

No, only the TLSA record and its RRSIG should be in there, so it is
identical to a real DNS response packet.

> or related "transparency" counter-measures).

That's an interesting question. I'd be tempted not to do this work in
the TLS extension but keep that to a ct-dnssec document.

> I'm not sure what "algorithms" you have in mind?

The successor to ECDSA or something like Curve*. I meant new DNSKEY
algorithms used to generate RRSIG records. I would like to see DNS
code maintained by DNS people used by browser people but I am young and
naive.

>  We should perhaps

Is that a problem in TLS? I thought the CA chains were already massively
bigger? Or is this something specific to the client/server hello
message?

> seems exceedingly unlikely to be deployable.

I agree, but Adam Langley did make that work so perhaps we are wrong?

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Jul 2015 22:18:17 +0000

> identical to a real DNS response packet.

But, the presence of a CNAME chain (either from host to TLSA base
domain, or from TLSA base domain to ultimate TLSA RRset) the start
of the chain is in the answer per your first comment?

> the TLS extension but keep that to a ct-dnssec document.

But it would affect which RRsets servers should put in the extension.

I guess the extension structure remains the same, so no need to
pin this down yet?

> code maintained by DNS people used by browser people but I am young and

Oh, I see, indeed I DO NOT want to see applications shipping with
their own rarely updated DNSSEC libraries.  They should at least
use an actively maintained library that is sepeparate from the
application, and provides a "standard" API for doing the validation.

Even better would be a new type of query to the local resolver that
includes all the records as part of the query, and the local resolver
validates the results (for clients that can reach a resolver on
127.0.0.1, but which in turn can't get DNSSEC data).

(That is a protocol is even better than an API).

> bigger? Or is this something specific to the client/server hello

Sure, CA chains are largish, but no reason to make DNS chains
needlessly large, or for servers to perform uncompression just to
forward DNS packets to clients.

> I agree, but Adam Langley did make that work so perhaps we are wrong?

Google might be more at liberty to mint certificates as they please
and to coordinate this with any DNS RRSIG refreshes, I don't see
the world at large being at liberty to do this.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 28 Jul 2015 21:44:34 -0400

> and then to follow the second CNAME to the ultimate TLSA RRset.

There are a number of possibilities here, including more complicated data
structures. But I think we can use the current linear chain structure and
have it composed of multiple sequences corresponding to intersecting
branches of the DNS tree.

For the following hypothetical example:

_443._tcp.www.example.com.   IN   CNAME    ca.example.net.
ca.example.net.              IN   TLSA     2 0 1 <cadata_blob>

the getdns library's validation chain function currently returns (RRSIGs
omitted for brevity):

  _443._tcp.www.example.com. CNAME
  ca.example.net. TLSA <set>

  example.com. DNSKEY <set>
  example.com. DS <set>
  com. DNSKEY <set>
  com. DS <set>
  . DNSKEY
  example.net. DNSKEY <set>
  example.net. DS <set>
  net. DNSKEY <set>
  net. DS <set>

> or related "transparency" counter-measures).

I'd prefer to wait till the trans-ct-dnssec draft has progressed a bit more
before considering DNSSEC key transparency issues.

It looks like that draft proposes SCT RRs (with DS+chain data in them,
signed by log providers), so we could in the future incorporate SCT RRs in
the chain. However do we really need to? The TLS server is the one doing
the DNS queries, so it could perform the SCT checks against the logs it
trusts, while querying the chain records, and then build the validated
chain. I'm not sure there is a need for the TLS client to additionally do
these log checks, so it doesn't need to have that info delivered in the
chain.

> seems exceedingly unlikely to be deployable.

I believe Eric's question was about why this couldn't be done via a new
'Certificate Type' (and not about embedding the chain in the X.509 cert). I
presume the idea being the new certificate type would allow both the
server's X.509 certificate chain and the corresponding DANE/DNSSEC chain to
be delivered in the server's Certificate Message. I believe the argument
for doing it via a new TLS extension was that it would allow us to mandate
the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature
Extension.

Shumon Huque

---

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

On 7/28/15 5:44 PM, Shumon Huque wrote:
> I'd prefer to wait till the trans-ct-dnssec draft has progressed a bit
> more before considering DNSSEC key transparency issues. 
> 
> signed by log providers), so we could in the future incorporate SCT RRs
> in the chain. 

That draft really is pretty immature and at this point it's not
clear whether and how it's going to progress.  Paul Wouters can
speak for himself about where he thinks the draft needs to go
but I think it does bear pointing out that he's offered to help
out with content, given that he's got considerable DNS and DNSSEC
expertise.  If the document does continue to progress I would
expect quite substantial changes.

> 'Certificate Type' (and not about embedding the chain in the X.509
> cert). I presume the idea being the new certificate type would allow
> both the server's X.509 certificate chain and the corresponding
> DANE/DNSSEC chain to be delivered in the server's Certificate Message. I
> believe the argument for doing it via a new TLS extension was that it
> would allow us to mandate the use of the DANE chain ("Must staple DANE")
> via the X.509 TLS Feature Extension.

Well, sort of.  We did talk about creating a new certificate
extension rather than a TLS extension but opted not to.  The
one advantage of an X.509 extension would have been that it wouldn't
require protocol changes, but it still would have required modifying
both the server and the endpoint.

Melinda

-- 
Melinda Shore
No Mountain Software
[email-masked]

"Software longa, hardware brevis."

---

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

> ca.example.net.              IN   TLSA     2 0 1 <cadata_blob>

This is simpler than the general case, everything is still "linear",
because there's only a CNAME chain leading to the TLSA RRset.

More generally, there's also a CNAME chain leading to the TLSA base
domain:

    www.example.com. IN CNAME www.example.com.cdn.example.net.
    www.example.com.cdn.example.net IN CNAME node1.example.net.
    node1.example.net. IN A 192.0.2.1

    _443._tcp.node1.example.net. IN CNAME ca.example.net.
    ca.example.net IN TLSA 2 0 1 <cadata_blob>

Here, we have CNAME (perhaps via a DNAME) indirection from the SNI
name (www.example.com) to the actual TLSA base domain (node1.example.net).

And then more CNAME records from there to the CDN provider's TLSA
RRset.

This is no longer the DNS response to a single query (iterative
resolvers generally chase CNAMEs), since one first CNAME expands
the original target hostname to obtain the TLSA base domain (provided
the CNAME chain is validated end-to-end) and then CNAME expands
the _443._tcp. prefixed base domain to find the TLSA RRset.

>   example.net. DNSKEY <set>

The getdns library is unlikely to handle the fully general case,
because first the TLSA base domain has to be found.

> these log checks, so it doesn't need to have that info delivered in the

The TLS server is not trusted, the whole point is detect malfeasance,
where the DNS operator and TLS server conspire to lie (to selected
clients).

> the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature

I see.  I think the question of whether "must staple DANE" is
supported or not is quite orthogonal to the question of how DANE
stapled data is encoded.

The disadvantage of this being a new certificate type is that AFAIK
it would then not be orthogonal to the choice between X.509 chains
and raw public keys.  We might then have a (small) combinatorial mess:
 
	traditional X.509 chain
	X.509 chain with stapled DANE evidence
	raw public key
	raw public key with stapled DANE evidence

I think the extension is a more logical separation of duties, but
I am willing to hear contrary arguments.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 28 Jul 2015 22:43:29 -0400

> the _443._tcp. prefixed base domain to find the TLSA RRset.

Hmm, I guess the DANE ops draft says to look for TLSA records at the alias
target rather than the owner name. This doesn't seem to be how many early
HTTPS sites are deploying TLSA records though, e.g. www.ietf.org.

> because first the TLSA base domain has to be found.

It probably doesn't today. I'll check into this.

> in

Yeah, I had a feeling you'd say this :-) Fair enough, that's an additional
threat we should take into account.

> cert). I

Encoded yes, but not necessarily on what protocol element carries the
encoding. It depends on what mechanism is being used for the must-staple
assertion. The X.509 TLS feature extension mechanism requires a list of TLS
extension values to be specified. Using a new TLS certificate type would
not be compatible with that.

> I am willing to hear contrary arguments.

Yes, I agree.

Shumon Huque.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Jul 2015 03:05:32 +0000

> HTTPS sites are deploying TLSA records though, e.g. www.ietf.org.

With www.ietf.org, the TLSA record for HTTP was there long before
the DANE ops draft:

    www.ietf.org. IN CNAME www.ietf.org.cdn.cloudflare-dnssec.net.
    _443._tcp.www.ietf.org. IN TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6
    www.ietf.org.cdn.cloudflare-dnssec.net. IN A 104.20.1.85
    www.ietf.org.cdn.cloudflare-dnssec.net. IN A 104.20.0.85

The DANE ops draft says to look at the end of the CNAME chain (if
secure) first, and if there are no TLSA RRs there, only then stick
with the original name.  So sites that do it the old way (as above)
also work.  But with the new model cloudflare can provision the "3
1 1" record on their end.

In the case of DANE stapling, the CNAME chasing (or not) is done
by the server, which should ideally know whether it has a TLSA
RRset for the requested SNI domain, or whether it should construct
a CNAME chain starting with that name.  The point is that clients
have to be prepared for either outcome.

In essence the server is a DNS proxy for a  client that is either
cut-off from DNSSEC, or simply unwilling to pay the latency cost.
The data consumed by the client is the same whether acquired
unilaterally, or via the server.

One could almost imagine a VPN tunnel set up by the client and
server between the DNS caches on either end, except that for multiple
reasons that mental model is rather a crude approximation of the
details.  It can however be a useful source of inspiration.

> threat we should take into account.

If and when CT for DNSSEC comes into the picture.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Jul 2015 06:28:24 -0400 (EDT)

>> more before considering DNSSEC key transparency issues.

Agreed.

> speak for himself about where he thinks the draft needs to go

The current draft focussed on the container format of the data, but
after some discussion in the dns and trans groups, it became clear
that the more important question to answer first is what to log.
Especially when you want to protect against a rogue parent, it becomes
important to log zone cuts along with the keys so that consumers of
the log can see the key/parent responsible for publishing the data.

There are also issues with preventing spam/ddos attacks against the
logs, similar but different from certificates.

> both the server and the endpoint.

The TLS extension would be easier to configure than requiring the system
administrator to regenerate (and re-sign?) certificates. Or mark certain
data (the dnssec blob) as not covered by the certificate signature.
People will end up putting the wrong certificate signatures in TLSA
records, etc. The TLS extension separates this more cleanly, and only
the TLS servers supporting the new extension need to know about how
to generate and serve the dnssec blob. Aind finally, with raw public
keys there is no way to embed the dnssec blob into the "certificate"
payload, as it is defined (on purpose) to only contain the SPKI.

Paul