On Thu, Mar 23, 2017 at 12:28 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > On Mar 22, 2017, at 10:56 AM, Melinda Shore < > melinda.sh...@nomountain.net> 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. > Yes, I agree. We should add a reference to 7671. > > > 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. > Yes. > > 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... > Yes, and it kind of is mentioned later in the document where there is a discussion of whether or not to include the trust anchor DNSKEY RRset in the chain or not. We need to sort out the requirement there. > 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. > Hmm, I remember you brought up this point a while back, but I can't remember the subsequent discussion and what we decided to do about this. I suppose it may be possible to preconfigure the servers on the other side of the load balancer to know the original port to avoid this problem. > > 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? > I would assume the validator on the TLS client side. > > > 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. > Yes. The need to include NSEC/3 records for the wildcard DNS record case is mentioned later in the draft, so this text needs to be reconciled with it. Also, on the issue of ordered vs unordered sequence of RRsets, the draft at the moment appears to have contradictory text on this issues. Earlier in section 3.4 it says: "The record sets and signatures are presented in the order returned by the DNS server queried by the TLS server, although they MAY be returned 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. " I know there are proponents of each. We need to decide which it is. > > 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. > Yes. > > > 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... > Yes, again. > > > 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. > We seem to be quoting generic DNSSEC protocol requirements here. I'd be in favor of striking this sentence. > 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. > Right, we need to decide whether this protocol extension will support in-band RFC 5011 key rollover capability or not. If so, the chain will have to include the trust anchor DNSKEY RRset (or I suppose its inclusion could be negotiated by client signaling). One could make the case, that key rollover is best handled by a system wide service that the TLS client uses (mentioned in the draft). However, there may again be potential middlebox interference problem here that could prevent such a service from working reliably (e.g. if the middlebox prevents the delivery of DNSKEY queries and signed responses). Another way this problem could be addressed is by regular client software updates - browsers I believe are comfortable with this mode. The DNS root key rollover happens (or is at least planned to happen) on a time scale that is much larger than typical client software updates. The protocol described here is general purpose though. It could be used with a custom trust anchor for a different point in the DNS tree where key rollover schedules are more unpredictable. > > > 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). > The client asks for it, or the server sends it unilaterally, or we decide that client TA rollover is handled outside the protocol. > ... 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. > Yes (discussed previously). > > > 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? > It sounds like it. I would strike this paragraph. > 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. > Yes. > > > 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. > Personally, I'm in favor of mandating TLS SNI usage with this extension. But I lost that argument with other folks, so I defer to consensus. > > > > 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. > We need to sort out the ordered vs unordered issue first. We can then elaborate on CNAME/DNAME processing. > > > 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. > I would be okay with that, but it doesn't have to be that way. Validating resolver logic placed in the client can just as easily figure out the canonical TTL before signature verification. > > > 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. > Yes, I agree. > > > 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. > [See previous discussion] -- Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
