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

From: "Jon A. Solworth" <[email-masked]>
Date: Fri, 8 Apr 2016 17:33:57 -0500

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 Apr 2016 12:28:58 +0000

> 	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.

Can you compare the TTL of the ephemeral key record with the A/AAAA record TTL?  Are they related?  If someone can get phony records into DNS, can they then become the real MLT server?  For how long?

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Apr 2016 15:05:09 +0200 (CEST)

Salz, Rich wrote:
> Can you compare the TTL of the ephemeral key record with the
> A/AAAA record TTL?  Are they related?  If someone can get phony
> records into DNS, can they then become the real MLT server?  For how long?

Admittedly I don't know anything about MLT, but your question indicates
what might be a serious misunderstanding about DNSSEC.

The TTL of a DNS record is *NOT* protected by DNSSEC, and can be
regenerated at will by an attacker, will be regenerated by intermediate
DNS server and its purpose is purely cache-management, *NOT* security.

Only the "Signature Expiration" information in the RRSIG
is protected by DNSSEC, and only that ensures expiry of information
from DNS.

https://tools.ietf.org/html/rfc4034#section-3.1

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 Apr 2016 14:52:26 +0000

> > Can you compare the TTL of the ephemeral key record with the A/AAAA
> > record TTL?  Are they related?  If someone can get phony records into
> > DNS, can they then become the real MLT server?  For how long?
> 
> 

No, thanks, I understand that.

I am asking only about the TTL's of the epehemeral key and what the risks/exposures are.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 11 Apr 2016 11:54:19 -0400

> On Apr 11, 2016, at 9:05 AM, Martin Rex <[email-masked]> wrote:
> 

This is largely wrong, RRSIG RRs carry an "original TTL"
field and:

   https://tools.ietf.org/html/rfc4035#section-5.3.3

   If the resolver accepts the RRset as authentic, the validator MUST
   set the TTL of the RRSIG RR and each RR in the authenticated RRset to
   a value no greater than the minimum of:

   o  the RRset's TTL as received in the response;

   o  the RRSIG RR's TTL as received in the response;

   o  the value in the RRSIG RR's Original TTL field; and

   o  the difference of the RRSIG RR's Signature Expiration time and the
      current time.

So attackers cannot generate TTL values "at will", the TTL is bounded by
the signed "original TTL".  Of course if the attacker remains on path
indefinitely, then he can replay a stale signed RRset until the RRSIG
expires.

-- 
	Viktor.