Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

[Viktor Dukhovni <[e-mail]>]

> On Oct 8, 2018, at 8:09 PM, Christopher Wood <[e-mail]> wrote:
> 
> 1. What is the fundamental security issue? What is the purpose of this
> extension?
> 2. Under what circumstances should DNS records received in the
> extension be cached and reused for future use?
> 3. Is pinning required? If so, what is pinned, and at what layer(s)
> should it be implemented?

1. Some applications that would take advantage of DANE cannot do
   so because they can't use DNSSEC directly.  Either because of
   last-mile problems or perhaps out of latency considerations
   (though often the lookups can be made in parallel).

2. The stated purpose of the draft, per its introduction, is to
   enable such applications to obtain the requisite DNSSEC records
   in-band from the TLS server, thereby avoid both problems in (1).
   As noted by Richard Barnes, this even also resolves potential
   UKS attacks in some protocols, that inherent in DANE without
   certificate name checks, as with raw public keys, or the advice
   of RFC7671 Section 5.1

   https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07#section-2

<quote>
   This draft describes a new TLS [RFC5246] [TLS13] 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] [RFC7671] of a TLS server 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
   [HAMPERING].  And lastly, it allows a TLS client to validate the
   server's DANE (TLSA) records itself without needing access to a
   validating DNS resolver to which it has a secure connection.

   This mechanism is useful for TLS applications that need to address
   the problems described above, typically web browsers or SIP/VoIP
   [RFC3261] and XMPP [RFC7590]. [...]
</quote>

3. The draft's intended scope is not and should not limited to
   *just* "green field" applications such as DPRIVE, where use of
   the extension might be always mandatory, or otherwise based on
   static local policy for designated peers.

4. Without static client policy, existing applications (e.g. web
   browsers), can't know a-prior which servers are expected to
   support the extension and which are not.

5. Absent such knowledge, they're vulnerable to stripping of the
   extension on first contact, by an attacker able to provide valid
   WebPKI credentials (unchanged status quo ante for majority of
   servers).

6. Let's Encrypt certificates are both cost and hassle free.  For
   a an existing application service (not "green field") there's
   no substantive disincentive to having a WebPKI certificate that
   ensures interoperability with a majority clients that will at
   least initially, and perhaps indefinitely, support only WebPKI.

7. If the WebPKI were sufficiently secure to preclude any concerns
   about (5), then there'd be no need to bother with DANE.  Nobody
   would ever use a BGP MiTM attack to demonstrate domain control
   (run a server on port 80, respond to an intercepted email to
   "admin@", forge unsigned DNS replies, ...).

8. If on the other hand, back in the real world, one has legitimate
   concerns about the security of DV certificate issuance (knowing
   that compromise of the DNS registrar account used to manage
   DNSSEC records also necessarily compromises ACME), then one might
   actually want one's DANE TLSA records to securely restrict the
   acceptable certificate chains to match the these records in a
   manner that is not trivially downgraded to the ability to obtain
   a WebPKI certificate.

9. Not only is the extension subject to stripping by an adversary
   that subverts DV certificate issuance, thereby eliminating all
   of its benefits when not enforced by client policy (a-priori
   static pinning), it still carries costs in the form of needing
   to keep any TLSA records correct or else risk failure when clients
   that support the extension see non-matching certificates.

The above is discussed in Ben Kaduk's proposed additions to the
security considerations back on Jun 1.

a. There are other gaps in the document.

	i. Failure to explain that when the server caches DNS data
	   for multiple responses, it must decrement TTLs when
	   transmitting "aged" data to clients.

	ii. Failure to adequately explain interactions with virtual
	    hosting

	iii. Failure to mandate SNI, or to convey the server port
	     in the client extension to deal with DNAT.

	iv.  Pointless ordering constraints on the DNS RRsets, that
	     don't work well when CNAME and DNAME records are involved.

So before we discuss remedies, I'd like to hear whether there's
substantive disagreement with the above statement of the problem.
A discussion of remedies if we don't yet agree on the problem at
hand would likely lead to much miscommunication.

-- 
	Viktor.