On Sun, Nov 01, 2015 at 08:34:40AM +0900, Shumon Huque wrote:
> This work is proposed to happen in TLS, but we hope to get plenty
> of feedback from DNS/DANE folks. Here's a quick summary of the major
> changes in -02:
>
> * Updated reference newly published DANE RFCs
Thanks.
> * An update to the chain data format. It now uses native DNS wire
> format resource records with no TLS presentation language wrapping.
> This makes it easier for implementations to work with existing
> DNS libraries to produce and consume the data. But we still describe
> the data format in sufficient detail that implementers not using DNS
> libraries can work with it.
I still think this should support and use DNS compression.
> * Description of how CNAME and DNAMEs are accommodated
>
> * Reference to use of the X.509v3 TLS Feature Extension to mandate
> use of the extension by a server certificate.
>
> * Reference to the EDNS chain query option draft as a future easy
> way to obtain/produce the chain data.
>
> * Removed discussion of possible client caching of chain data
> components (could be difficult to get right and/or a premature
> optimization).
Introduction:
The intent of this proposal is to
allow TLS clients to perform DANE authentication [RFC6698] of a TLS
server certificate without performing perform additional DNS record
lookups and incurring the associated latency penalty.
s/performing perform/having to perform/
It also
provides the ability to avoid potential problems with TLS clients
being unable to look up DANE records because of an interfering or
broken middlebox on the path between the endpoint and a DNS server.
s/endpoint/client/
And lastly, it allows a TLS client to validate DANE records
itself without needing access to a validating DNS resolver
to which it has a secure connection. It will typically not
be used for general DNSSEC validation of endpoint names,
but is more appropriate for validation of DANE TLSA records.
Clients can already do independent validation (perhaps at higher
latency cost if they don't implement a *caching* stub resolver).
Furthermore, this mechanism is, at least for now, *definitely*
(not just typically) restricted to carrying DANE TLSA records
and their signatures.
This mechanism is useful for TLS applications that need to address
the problems described above, typically web browsers or VoIP and XMPP
services.
Are "XMPP services" applications? I would say "typically in
web browsers, VOIP or XMPP clients", but we still don't know
that web browsers are likely to adopt DANE however hard we try.
So we can't predict which applications will take the bait,
perhaps we should not try. We might however indicate what
"types" of applications are in scope, and that is mobile clients
for which DNSSEC is not always available on random WiFi hotspots,
and latency-sensitive clients for which making multiple DNS
lookups to validate a DNSSEC response is not an option (and
no DNSSEC validating cache is available locally).
Section 3.2
The AuthenticationChain structure is composed of a sequence of
uncompressed wire format DNS resource record sets (RRset) and
corresponding signatures (RRsig) records. The record sets and
signatures are presented in validation order, starting at the target
DANE record, followed by the DNSKEY and DS record sets for each
intervening DNS zone up to a trust anchor chosen by the server,
typically the DNS root.
Two issues here:
* Because validation order is not always possible (in presence
of DNAME/CNAME indirection), it is I think best to not
suggest that the records are so ordered, even in the case
when such ordering is possible. To do otherwise invites
sloppy implementations that don't correctly deal with
replies that are unavoidably not strictly ordered.
* On the other hand, the specification needs to clearly
identify what the server needs to use as the *first* RRset.
This can be tricky. The point is that a DANE TLSA client
connects to and authenticates a what is essentially "transport
endpoint", except that the network address is replaced by
a DNS name. On the other hand the accepting server might
be behind a NAT device of some sort, and may not even know
what port the client connected to!
The client's name for the service can be learned from the
SNI extension, which therefore MUST be used when the proposed
extension is used, and presumably the transport protocol
(TCP, or UDP) is known on the server end (the server will
be doing TLS or DTLS after all, and will know which).
So it would seem that the client needs to communicate the
target port to the server, as the payload of the proposed
extension in the client HELLO (extension would no longer
be empty on the client side).
The server's job is then to produce a set of DNS RRsets
whose first element is either:
_<port>._<protocol>.<SNI-FQDN> IN TLSA ...
or
_<port>._<protocol>.<SNI-FQDN> IN CNAME ...
in the latter case ultimately along with the TLSA records
for the target of the chain of CNAMEs. Each CNAME will of
course require proof of the validity of that CNAME (which
may be based on proof of associated DNAME records).
This then brings us to the question of whether the server
should be willing to attempt to construct such a set of
records for an arbitrary SNI name the client happens to
send. It seems that the answer should generally be "no".
This is because otherwise the client would be able to
trigger arbitrary DNS lookups on the server, which may
impose unacceptable resource costs (and facilitate DoS
attacks on the targets of such lookups).
Therefore, servers MUST be configured with a list of SNI
domains (or at perhaps domain suffixes) for which they are
willing to attempt to produce a validated TLSA RRset.
A bit lower we have:
[TODO: mention that to reduce the size of the chain, the server can
deliver exactly one RRsig per RRset, namely the one used to validate
the chain as it is built.]
This assumes that the server knows which algorithms the client's
library supports. The server can definitely do some trimming
if multiple signatures are present for the same algorithm as
a side-effect of key rotation, but it cannot in general trim
the list down to one signature per RRset, unless the client's
extension also signals the supported algorithms (too complex
I think, and serves to help "fingerprint" the client).
Each RRset in the chain is composed of a sequence of wire format DNS
resource records. The format of the resource record is described in
RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be
presented in the canonical form and ordering as described in RFC 4034
[RFC4034].
RRs within the RRset are ordered canonically, by treating the RDATA
portion of each RR as a left-justified unsigned octet sequence in
which the absence of an octet sorts before a zero octet.
Here, I'd like to lift both the restriction on the order and
canonical form. In which case, the server can return the
records in exactly the form it obtained them from its own DNS
server, likely not canonically ordered, and quite possibly with
compression!
The server may need to make multiple queries to obtain the full
set of records to return to the client. In order to make it
possible to retain DNS compression, the response format needs
to consist of one or more wire-form DNS packets, each of which
contains one or more answer RRsets ("additional" and "authority"
records should be discarded at the server end, but with care,
in the unlikely case that compressed answers point into records
in the authority or additional sections.)
Thus I think the right structure for the reply is a sequence
of DNS packets, not a sequence of RRsets. Compression is then
scoped to each individual packet.
Of course we could make the server "work harder" by consolidating
all the DNS packets it receives into a single sequence of RRsets
as suggested in the current draft. This would typically require
"decompression" and "recompression" once the full set of RRsets
is assembled (if I think is best) we opt to minimize the network
footprint of this extension.
The first RRset in the chain MUST contain the DANE records being
presented. The subsequent RRsets MUST be a sequence of DNSKEY and DS
RRsets, starting with a DNSKEY RRset. Each RRset MUST authenticate
the preceding RRset:
Except of course when it is a CNAME (perhaps a chain of such
CNAMEs). Some nameservers return RRSIGs before the record they
signed. Again, apart from the first RRset being either the
desired TLSA RRset, or a CNAME from its qname ultimately to a
TLSA RRset, the order of records after the first should not be
constrained.
The client should load them *all* into memory, then validate
the first (using all pertinent records in the resulting cache)
and recurse if that first record is a CNAME, (being mindful of
potential loops), until it ultimately validates a TLSA RRset,
which authenticates the server's certificate or bare public
key (RFC7250).
I'll stop here for now, because if I'm in the rough on the above,
further comments would likely fall afould of the same issues.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
