Subject: [TLS] [[email-masked]: TLS weakness in Forward Secrecy compared to QUIC Crypto]

From: Tanja Lange <[email-masked]>
Date: Sat, 9 Apr 2016 03:26:38 +0200

Looks like this didn't make it out to the list. Forwarding
from my email address a message by Jon Solworth.

----- Forwarded message from "Jon A. Solworth" <[email-masked]> -----

Date: Fri, 8 Apr 2016 17:33:57 -0500
From: "Jon A. Solworth" <[email-masked]>
To: [email-masked], Tanja Lange <[email-masked]>, "D. J. Bernstein"
	<[email-masked]>, "W. Michael Petullo" <[email-masked]>
Subject: TLS weakness in Forward Secrecy compared to QUIC Crypto

	It is not necessary to choose between either forward secrecy
or low latency.  It is possible to achieve both (and many other
properties) as does MinimaLT.

	In MinimaLT, the current ephemeral key for the server
is added to the DNS record fetched during the DNS lookup.  These entries
expire fairly quickly, ensuring that old keys are never
used.

	The DNS lookup is necessary for other reasons, so there
is no additional latency.

	This design avoids weak mechanisms and added complexity,
two issues that cause enormous problems in security software.

Jon Solworth

----- End forwarded message -----

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 8 Apr 2016 23:19:22 -0300

> is no additional latency.

DNS-based priming is a seemingly attractive concept but unfortunately isn't
really workable here, for several reasons:

1. It requires DNS security, which has relatively minimal deployment. We
want
0-RTT to be available in TLS 1.3 even in environments without DNS security.

2. Measurements indicate that penetration rates for DNS records other than
the
basic ones that are necessary for nearly all operation (A, CNAME, etc.) are
fairly poor, so this adds a number of operational problems.

If you want to use short-lived ephemerals that are frequently refreshed in
the
DNS, thus providing forward secrecy you have the additional problem that
most Web servers are not well integrated into the DNS server (one reason why
Let's Encrypt initially launched with HTTP-based validation).

With that said, if the deployment situation changes, it wouldn't be
that hard to add a feature like this to TLS 1.3 in the future.

Best,
-Ekr

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Apr 2016 16:36:28 -0000

Eric Rescorla writes:
> 1. It requires DNS security

No, it doesn't. MinimaLT sticks to the existing X.509 PKI for easy
deployability. The same server key that you're using for HTTPS, the key
where you've obtained a certificate from (say) Let's Encrypt, is also
signing your MinimaLT ephemeral keys. (Improvements in DNS security can
give _additional_ protection to MinimaLT beyond the X.509 PKI, whereas
TLS doesn't have this feature, but this is not the main point.)

You _do_ need to be able to automatically sign new ephemeral keys and
drop the signed data into your DNS database. If you're not used to this
level of automation---for example, if you've outsourced your DNS data to
a company that provides only manual web-based DNS editing---then you
might see this as a showstopper. But there are many other sites where
this is a trivial level of scripting. The resulting latency improvement
is huge---_always_ getting what 0RTT _sometimes_ gets.

> 2. Measurements indicate that penetration rates for DNS records other
> than the basic ones that are necessary for nearly all operation (A,
> CNAME, etc.) are fairly poor, so this adds a number of operational
> problems.

I agree that the original goal of extensible "query types" in DNS (see
RFC 1034, third paragraph) was ruined by poor implementation work (which
was in turn encouraged by other aspects of the DNS protocol design, but
let me not get sidetracked here), so trying to deploy new DNS "query
types" creates operational problems.

This does _not_ mean, however, that putting new applications into DNS
creates operational problems. It simply means that one has to avoid the
trap of thinking that new applications should encode their data as new
DNS "query types". Sticking to the limited set of well-supported DNS
"query types" is reasonably straightforward and eliminates all of the
operational problems.

Of course, the difference in encodings between DNS and TLS can produce
differences in the number of packets used to send a long chain of large
certificates. But it's an easy exercise to have DNS cache pretty much
everything for long periods. The only thing that changes frequently is a
new signature on a new ephemeral key.

---Dan

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 11 Apr 2016 13:08:39 -0400

> On Apr 11, 2016, at 12:36 PM, D. J. Bernstein <[email-masked]> wrote:
> 

I've been monitoring DANE TLSA adoption in SMTP for some time now, including
monitoring of domains where requests for the novel TLSA records encountered
misconfigured middle-boxes that drop the query.

Initially (2 years ago), problems were widespread.  Now problems are rather
rare and getting more so.  Out of ~130,000 DNSSEC domains in my corpus, only
~40 drop requests for TLSA records.  Two years ago there were many thousands
out of a much smaller corpus.

If TLSA is a canary for generic "exotic" RRtypes, we're increasingly in good
shape, at least for domains whose zones are signed.

When one reports demonstrated problems caused by firewalls that are too eager
to "protect" DNS servers from "non-standard" DNS queries the issue is generally
dealt with.

So the main obstacle to lack of support of new RRtypes is lack of use.  Make it
compelling for DNS operators to support these (e.g. continue to receive email,
...) and they will update their configurations accordingly.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Apr 2016 10:10:54 -0700

> TLS doesn't have this feature, but this is not the main point.)

Yes, this is a fair point.

> is huge---_always_ getting what 0RTT _sometimes_ gets.

Perhaps: Google's measurements indicate a very high rate of 0-RTT with
QUIC (75%) without DNS-based priming.

> "query types" is reasonably straightforward and eliminates all of the

I'm not sure which query type you're assuming: the measurements I am
referring to were taken with TXT records.

To be clear: I wish this weren't true. Expecting to have some kind of
out-out-band
priming was one of the main reasons for having a DH-based 0-RTT mode in
draft-12, but increasingly it just started to look like that wasn't viable.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Apr 2016 10:15:25 -0700

To add one more point here: the WG was very uncomfortable with having any
kind of long-term delegation mechanism, which a static signature of this
type
would be (though perhaps it would be a weaker form of attack if you required
an online signature as part of the handshake, as draft-12 does, in which
case
the attack would be limited to the 0-RTT data).

-Ekr

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 11 Apr 2016 23:48:39 +0200

> out of a much smaller corpus.

Don't you have to look at it the other way?  From a client that's
behind some broken box that tries to look up TLSA records?

I would really hope that if someone deploys DNSSEC that their
nameservers would actually support DNSSEC.  But that doesn't mean
that a client trying to look up the DNSSEC related records is able
to.

Kurt

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Apr 2016 03:07:22 +0000

> behind some broken box that tries to look up TLSA records?

Yes, that's a separate issue.  I've been monitoring domains served
by nameservers that support DNSSEC, but refuse TLSA RR queries.
(which are DANE, not DNSSEC).

> nameservers would actually support DNSSEC.

Some had significant issues with authenticated denial of existence,
which was a DNSSEC implementation problem, the vast majority of
these are now resolved.  Others, were dropping TLSA RRs, which is
not a DNSSEC issue, but breaks RFC 7672 opportunistic DANE TLS.
That too is mostly addressed.

> But that doesn't mean

What's under discussion here is not so much DNSSEC, but some
hypothetical new RRtype to support 0-RTT data.  It is true that
I've not been monitoring client-side issues (home cable boxes,
hotel networks, and the like), a lot more cats to herd on the client
side, and not really relevant to MTA-to-MTA transport security.

-- 
	Viktor.