Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

[Viktor Dukhovni <[e-mail]>]

> On Mar 22, 2017, at 10:56 AM, Melinda Shore <[e-mail]> wrote:
> 
> The draft could definitely benefit from additional review.

A more complete walk through:

> 2.  Introduction
> 
>    This draft describes a new TLS [RFC5246] extension for transport of a
>    DNS record set serialized with the DNSSEC signatures [RFC4034] needed
>    to authenticate that record set.  The intent of this proposal is to
>    allow TLS clients to perform DANE authentication [RFC6698] of a TLS

Should RFC6698 here be replaced or augmented with RFC7671?  In RFC7671,
the processing of DANE-EE(3) are DANE-TA(2) is modified from what one
might naively do with just RFC6698.  One of these changes of course
introduces the UKS problem referenced in this draft, but since this
draft militates against UKS attacks, that's not a problem.

>    server certificate without performing additional DNS record lookups
>    and incurring the associated latency penalty.  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 client and a DNS server.

FWIW, sometimes is the very DNS server the client learns via DHCP that
does not support DNSSEC, so no "middle-box" may be required to block
DNSSEC access.

>    And lastly, it allows
>    a TLS client to validate DANE records itself without necessarily
>    needing access to a validating DNS resolver to which it has a secure
>    connection.

[ It might be interesting at some point to implement a service in a
  local validating resolver to which the obtained DNS RRs can be
  forwarded for validation.  This way, all the application is doing
  is proxying DNS lookup via the TLS server to data that the local
  resolver may be prevented from obtaining directly, or would take
  too long to obtain.  This of course is not for the draft. ]

>    Furthermore,
>    SMTP MTAs usually employ Opportunistic Security [RFC7435], in which
>    the presence of the DNS TLSA records is used to determine whether to
>    enforce an authenticated TLS connection.  Hence DANE authentication
>    of SMTP MTAs [RFC7672] will typically not use this mechanism.

Note that RFC7672 describes opportunistic DANE TLS for SMTP, so RFC7435
should probably be replaced by RFC7672 here.

>    The client then authenticates the chain using a pre-configured trust
>    anchor.

Speaking of trust-anchors, the client will ultimately need to have some
mechanism to deal with root KSK rollover.  If the client has no local
resolver that is, at least intermittently, able to refresh the root KSK,
then the client may well also need to use this specification to update
the root KSK list from the DNSKEY RRsets returned by servers, and to
persist these for future use.  That's probably worth a mention...

>    As described in the DANE specification [RFC6698], this procuedure
>    applies to the DANE authentication of X.509 certificates.

Or raw public keys as described in 7671, and indeed mentioned below
in the draft.

> 3.1.  Protocol, TLS 1.2
> 
>    A client MAY include an extension of type "dnssec_chain" in the
>    (extended) ClientHello.  The "extension_data" field of this extension
>    MUST be empty.

One might ask the client to include the port number here, the server
may not know which port the client used if some load-balancer redirected
the layer-4 server address.

> 3.4.  DNSSEC Authentication Chain Data

>    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].
> 
>              RR(i) = owner | type | class | TTL | RDATA length | RDATA

Note that the TTL in the canonical form is the one in the RRSIG, rather
that a typically smaller value in response from the resolver.  Whose
responsibility is it to ensure that the records fed into the signature
verification algorithm have the correct (maximal) TTL?

>    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 that of course, as explained below, they don't have to be a
sequence of "DNSKEY" and "DS" RRsets, because wildcards also necessitate
NSEC, NSEC3 or possibly (some decade this century unless scalable QCs
arrive first) NSEC5 records.

>    o  A DNSKEY RRset must include the DNSKEY RR containing the public
>       key used to verify the previous RRset.

I assume that the DNSKEY RRset must be presented in full, because
otherwise how is its signature to be validated?  This even applies
to the root RRset in support of KSK rollover.  While it is possible
to limit the transmitted RRSIG records to just those supported by
the client, I don't see any opportunity to transmit partial RRsets
of any other type.

>    o  For a DS RRset, the set of key hashes MUST overlap with the
>       preceding set of DNSKEY records.

Again, except for the root (whose DS RRs need not be transmitted
at all), all the DS RRsets would surely need to be sent in full,
else their signature cannot be validated...

>    In addition, a DNSKEY RRset followed by a DS RRset MUST be self-
>    signed, in the sense that its RRSIG MUST verify under one of the keys
>    in the DNSKEY RRSET.

Are these instructions to the server (what to send) or to the verifier?
More specifically, the DNSKEY RRset must be accompanied by a signature
made by one of the KSKs whose hash appears in the DS RRset.  If there
are multiple algorithms in the DS RRset (say RSA and ECDSA) then if
at all possible an RRSIG by a KSK for each such algorithm MUST be
included unless the server knows which DNSSEC algorithms are supported
by the client and can safely omit RRSIGs for some of the algorithms.

>    The final DNSKEY RRset in the authentication chain, containing the
>    trust anchor may be omitted.

As mentioned below, that would make RFC5011 KSK rollover rather
difficult, and presumably we don't want clients to eventually cease to
be able to verify chains for lack of fresh trust anchors.

Indeed it is not just the root zone KSKs (trust anchors) that change
from time to time.  Rather, on a more frequent basis the root zone ZSKs
will roll over, and these are probably not part of any stable set of
trust-anchors maintained by the client.  For example, unbound's root
key file on my machine contains only the KSK:

   $ cat /usr/local/etc/unbound/root.key 
   ...
   .       172800  IN      DNSKEY  257 3 8 ...

So a fresh root zone DNSKEY RRset is going to be needed with some
frequency.  Right now the root zone has a single KSK and two ZSKs
and is signed by the KSK:

.                       DNSKEY  257 3 8 ( ... ) ; KSK; alg = RSASHA256 ; key id = 19036
.                       DNSKEY  256 3 8 ( ... ) ; ZSK; alg = RSASHA256 ; key id = 14796
.                       DNSKEY  256 3 8 ( ... ) ; ZSK; alg = RSASHA256 ; key id = 61045
.                       RRSIG   DNSKEY 8 0 172800 ( 20170411000000 20170321000000 19036 . ... )

While the SOA record and the rest of the root zone appears to be signed by
just the 61045 ZSK:

.                       SOA     a.root-servers.net. nstld.verisign-grs.com. (
                                2017032201 ; serial
                                1800       ; refresh (30 minutes)
                                900        ; retry (15 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
.                       RRSIG   SOA 8 0 86400 ( 20170404170000 20170322160000 61045 . ... )

One of the two ZSKs is presumably on its way out...

So it seems to me that the client extension needs to signal whether
the client is in need of a fresh root DNSKEY RRset.  Clients can omit
sending such a signal with most TLS connections and only ask periodically,
say once a day or so, perhaps from a few different servers just in case).

>    If omitted, the client MUST verify that
>    the key tag and owner name in the final RRSIG record correspond to a
>    trust anchor.  There may however be reason to include the trust
>    anchor RRset and signature if clients are expected to use RFC5011
>    compliant key rollover functions inband via the chain data.

But how is the server to know unless the client asks?  So I think
that perhaps the client extension needs to ask (RFC5011-enable flag
and port so far).

>    ...  Wildcard DANE records will need to include the wildcard
>    name, and negative proof (i.e.  NSEC or NSEC3 records) that no closer
>    name exists MUST be included.

And so the earlier text that says DS/DNSKEY only needs to be less
restrictive.

>    Note as well that if a user has a specific TLSA record for port 443,
>    and a different wildcard covering other ports, attackers MUST NOT be
>    able to substitute the wildcard TLSA RRset for the more specific one
>    for port 443.  DNSSEC wildcards must not be confused with the X.509
>    wildcards.

I don't understand this paragraph.  DNSSEC closest encloser proofs are
needed to show that the wildcard record is applicable.  The client knows
that the server is returning a wildcard response, which must prove that
the actual port sought has no explicit TLSA RR.  What am I missing?
Is this just asking the client to do DNSSEC wildcard answer processing
correctly?

> 4.  Construction of Serialized Authentication Chains
> 
>    This section describes a possible procedure for the server to use to
>    build the serialized DNSSEC chain.
> 
>    When the goal is to perform DANE authentication [RFC6698] of the
>    server's X.509 certificate, the DNS record set to be serialized is a
>    TLSA record set corresponding to the server's domain name.

Well, actually domain name *and* protocol *and* port.

>    The domain name of the server MUST be that included in the TLS Server
>    Name Indication extension [RFC6066] when present.  If the Server Name
>    Indication extension is not present, or if the server does not
>    recognize the provided name and wishes to proceed with the handshake
>    rather than to abort the connection, the server uses the domain name
>    associated with the server IP address to which the connection has
>    been established.

Or some suitable default name selected by the server.  I don't think it
is necessary to prescribe a selection mechanism.  The server may be
behind a load-balancer, and the name may be statically configured, rather
than obtained from the local address of the accepted socket.

>    The TLSA record to be queried is constructed by prepending the _port
>    and _transport labels to the domain name as described in [RFC6698],

That covers the label order, is it necessary to repeat it?

>    where "port" is the port number associated with the TLS server.  The
>    transport is "tcp" for TLS servers, and "udp" for DTLS servers.  The
>    port number label is the left-most label, followed by the transport,
>    followed by the base domain name.
> 
>    The components of the authentication chain are built by starting at
>    the target record set and its corresponding RRSIG.  Then traversing
>    the DNS tree upwards towards the trust anchor zone (normally the DNS
>    root), for each zone cut, the DNSKEY and DS RRsets and their
>    signatures are added.  If DNS responses messages contain any domain
>    names utilizing name compression [RFC1035], then they must be
>    uncompressed.

Of course there are additional complications when the original name
requires CNAME or DNAME processing to reach the ultimate target domain
where the TLSA records are stored.  Perhaps that's worth describing
in more detail, as that's the non-obvious part of the algorithm.

> 5.  Caching and Regeneration of the Authentication Chain
> 
>    DNS records have Time To Live (TTL) parameters, and DNSSEC signatures
>    have validity periods (specifically signature expiration times).
>    After the TLS server constructs the serialized authentication chain,
>    it SHOULD cache and reuse it in multiple TLS connection handshakes.
>    However, it MUST refresh and rebuild the chain as TTLs and signature
>    validity periods dictate.  A server implementation could carefully
>    track these parameters and requery component records in the chain
>    correspondingly.  Alternatively, it could be configured to rebuild
>    the entire chain at some predefined periodic interval that does not
>    exceed the DNS TTLs or signature validity periods of the component
>    records in the chain.

Perhaps the job of transmitting "canonical" TTLs should also be up to
the server, in which case this section should explain that the server
must replace the TTLs of each record with the corresponding RRSIG max
TTL field.

> 6.  Verification
> 
>    A TLS client making use of this specification, and which receives a
>    DNSSEC authentication chain extension from a server, SHOULD use this
>    information to perform DANE authentication of the server certificate.
>    In order to do this, it uses the mechanism specified by the DNSSEC
>    protocol [RFC4035].  This mechanism is sometimes implemented in a
>    DNSSEC validation engine or library.
> 
>    If the authentication chain is correctly verified, the client then
>    performs DANE authentication of the server according to the DANE TLS
>    protocol [RFC6698], and the additional protocol requirements outlined
>    in [RFC7671].

Some discussion of UKS may be appropriate here, since there'll probably
be some day soon an update to RFC7671 that says that name checks are not
generally optional for DANE-EE(3), but as this protocol militates against
UKS attacks, the original policy of RFC7671 should stand despite any such
(near future) amendation.

> 7.  Trust Anchor Maintenance
> 
>    The trust anchor may change periodically, e.g. when the operator of
>    the trust anchor zone performs a DNSSEC key rollover.  Managed key
>    rollovers typically use a process that can be tracked by verifiers
>    allowing them to automatically update their trust anchors, as
>    described in [RFC5011].  TLS clients using this specification are
>    also expected to use such a mechanism to keep their trust anchors
>    updated.  Some operating systems may have a system-wide service to
>    maintain and keep the root trust anchor up to date.  In such cases,
>    the TLS client application could simply reference that as its trust
>    anchor, periodically checking whether it has changed.

Hence clients should signal servers whether they want the root DNSKEY
RRset, or already have a sufficiently fresh local copy.

-- 
	Viktor.