Re: [TLS] [solwo...@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto]

[Kurt Roeckx]

On Mon, Apr 11, 2016 at 01:08:39PM -0400, Viktor Dukhovni wrote:
> 
> > On Apr 11, 2016, at 12:36 PM, D. J. Bernstein  wrote:
> > 
> > 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.
> 
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [solwo...@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto]

[Eric Rescorla]

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


On Mon, Apr 11, 2016 at 10:10 AM, Eric Rescorla  wrote:

>
>
> On Mon, Apr 11, 2016 at 9:36 AM, D. J. Bernstein  wrote:
>
>> Eric Rescorla writes:
>> > DNS-based priming is a seemingly attractive concept but unfortunately
>> isn't
>> > really workable here, for several reasons:
>> > 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.)
>>
>
> Yes, this is a fair 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.
>
>
> Perhaps: Google's measurements indicate a very high rate of 0-RTT with
> QUIC (75%) without DNS-based priming.
>
>
>
>> > 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.
>
>
> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [solwo...@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto]

[Viktor Dukhovni]

> On Apr 11, 2016, at 12:36 PM, D. J. Bernstein  wrote:
> 
> 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

> On Apr 11, 2016, at 9:05 AM, Martin Rex  wrote:
> 
> 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Rex]

Salz, Rich wrote:
>>  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/ 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

>   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/ 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: richs...@jabber.at Twitter: RichSalz



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls