On Wed, Sep 12, 2018 at 10:40:31PM -0400, Richard Barnes wrote: > > DNS records have semantics beyond a single connection. > > DNS records have caching semantics. Those are only relevant for DNS > resolution. This is the TLS WG, not the DNS.
It's odd you should say that, in draft -07, which you coauthored, I see the below rather reasonable text: https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07#section-6 Clients MAY cache the server's validated TLSA RRset or other validated portions of the chain as an optimization to save signature verification work for future connections. The period of such caching MUST NOT exceed the TTL associated with those records. A client that possesses a validated and unexpired TLSA RRset or the full chain in its cache does not need to send the dnssec_chain extension for subsequent connections to the same TLS server. It can use the cached information to perform DANE authentication. > > A zone owner published a TLSA record. > > A zone owner sent a TLSA record in a TLS handshake. No that's the TLS server application, the TLSA record is in fact published as part of the DNS zone independently of what the TLS application might later do. The data is signed at the origin and can be transmitted over any number of channels and verified at the destination. > This document says nothing about what is "published" through any > other channel. Because DNSSEC handles both data authentication, and authenticated denial of existence, the same facts are conveyed about any requested RRset, regardless of channel. Unlike other contexts, alternative facts are detected as "bogus". > The similarity isn't vague; the problems are identical. Let's look at the > Chrome intent to remove HPKP > > https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ?hn But HPKP is vastly different. It pins keys, which if never possessed or lost by the legitimate site operator, preclude the operator from restoring communication with the client. Indeed though the issue is typically described as a risk of DoS by a malicious adversary, the *real* and far more common problem with HPKP is self-inflicted damage after loss of keys through operational errors or hardware failure. Here, all that would be "pinned" is a capability to support the extension, which anyone could enable at their pleasure, and the self-inflicted damage is entirely out of the picture, just bring the service back online and it continues to work! Delivery of fresh TLSA records or denial of existence updates or clears any previous pin with friction. Furthermore, a client that sees a server violating its pin, rather than failing, can then choose to pay the latency cost and obtain valid DNSSEC signed TLSA RRs from 1.1.1.1 or similar DNSpriv servers (where the extension would be unconditionally supported, as part of DANE support in DNS over TLS or DNS over HTTP). If the TLSA records are proved to not exist, the client can clear the pin. If the TLSA records exist and match the server's certificate chain, the client can continue the connection. > There is a risk of rendering a site unusable. This risk is vastly lower for this protocol, and tamper-evidence that shows that past connections were to a rogue server is frankly a feature more than a bug. The user is now informed that he was previously, or is now, communicating with the wrong server, and that some action may be required to secure his data. > There is a risk of hostile pinning, should an attacker obtain a misissued > certificate. This is the dramatic strawman version of the risk. The real problem is irrecoverable loss of keys. > While there are no confirmed or rumored cases of this having > happened, Precisely, because the real problem is loss of keys, which surely did happen. > the risk is present even for sites that don’t use PKP. This is the strawman risk that sells the deprecation, the real reason is much more mundane. > > Any client that obtains DNS data with a valid TTL is allowed to cache > > and re-use it as long as the TTL allows it. Irrespective of whether this > > is part of TLS or Aviation Carriers. > > The client may do that. That doesn't mean the server is entitled to expect > the client to do that. Nobody is saying the client has to cache, and indeed the server cannot expect the client to be stateful. > And if the server doesn't expect the client to > cache, then there's no downgrade at all. The above is a failure of deductive reasoning. -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
