Subject: [keyassure] Phreeload, Dan Kaminsky's prototype client

From: Matt McCutchen <[email-masked]>
Date: Tue, 11 Jan 2011 21:51:00 -0500

I thought I would mention, for those not already aware, that Dan
Kaminsky has a prototype client for a DANE-like system; he just picked a
record format.  The client is called Phreeload, part of the Phreebird
Suite (http://dankaminsky.com/phreebird/).  I have been playing with it
and have added the necessary record at mattmccutchen.net .  It should be
pretty easy to modify Phreeload to understand whatever record format we
decide on.

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Jan 2011 22:12:50 -0500 (EST)

> pretty easy to modify Phreeload to understand whatever record format we

He is also aware of the TLS/HASTLA drafts. I talked to him two weeks ago
about this. I also asked him for a somewhat more formal specification of
his TXT records, though I urged him to be part of the IETF process in
getting the right new RRTYPE. His fears are mostly based on old software
seeing and having to configure decimal numbers for new RRTYPEs.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Jan 2011 10:32:33 -0500

> seeing and having to configure decimal numbers for new RRTYPEs.

What bothers me about this is that anything that can do DNSSEC
_anyway_ can already cope with unknown RRTYPEs.  Moreover, anyone who
is interested in this right now is obviously going to be willing to
keep their system up to date too.  The difficulty of dealing with
RRTYPE numbers one doesn't know is a zombie fact: something that used
to be true but now will not die.  I don't expect everyone to
understand this, but I do expect people who are promoting DNSSEC to do
so.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 12 Jan 2011 08:09:54 -0800

> understand this, but I do expect people who are promoting DNSSEC to do

Not necessarily.  Even directly over the network (so direct client to server) you see a greater problem requesting an unknown RTYPE rather than a TXT record, and you see problems fetching records with EDNS0 enabled once you hit >512B responses.

Success rate in Netalyzr
EDNS0			98.5%
EDNS0 1400B response	95.8%
(old test, so always run)

TXT			98.1%
RTYPE=169		97.0%
(newer test)

The situation is MUCH MUCH MUCH worse when you are talking about probing the NAT's DNS gateway:
EDNS0			90%
TXT			92%
AAAA			95%
(the unknown rtype test was bugged, so its not considered here).

Since systems are often, by default, configured to use (and ONLY know about) the NAT's DNS gateway, doing just about anything with DNSSEC to the client means that the stub resolver MUST be willing to bypass the recursive resolver infrastructure completely, and even then, be prepared for failures, including failures of new RTYPES to work when old RTYPES work successfully.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 Jan 2011 11:28:57 -0500 (EST)

On Wed, 12 Jan 2011, Nicholas Weaver wrote:

> Date: Wed, 12 Jan 2011 08:09:54 -0800
> From: Nicholas Weaver <[email-masked]>
> Cc: [email-masked]
> To: Andrew Sullivan <[email-masked]>
> Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client
> 
>

How much of those ENDS0 clients allow TCP? Because if not, then your DNSSEC limit is
already at 90% without even considering new RRTYPE's, and I'd think that there is a large
overlap in systems not able to do EDNS0/TCP and systems not able to do new RRTYPEs.

Also, if you are asking TLSA/HASTLS/TXT records, you *are* an endpoint either doing DNSSEC
yourself, or you are using a DNSSEC-capable resolver. In neither case are you using a bad
NAT router DNS stub forwarder as listed above in the list of broken stuff out there.

Paul
Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 12 Jan 2011 09:04:40 -0800

> overlap in systems not able to do EDNS0/TCP and systems not able to do new RRTYPEs.

Its pretty good.  DNS over TCP is much MUCH less mangled than DNS over UDP. 

> NAT router DNS stub forwarder as listed above in the list of broken stuff out there.

The model of doing DNSSEC yourself [1] requires either being able to query the appropriate records from the configured recursive resolver or bypassing it entirely.  This shows that the model of 'only get from the recursive resolver', as the recursive resolver IS the NAT proxy in many many cases, doesn't work, you MUST be prepared to bypass it.

Oh, and the NAT can only handle an unknown RTYPE=1169 [2] in 91% of the cases, and can handle either a TXT record OR an unknown RTYPE in 92% of the cases, so unknown RTYPES really aren't that much worse than TXT records (its highly coupled between the two) from the NAT viewpoint.

And its been pointed out that, oops, you need to look at correlation on the direct case as well:  98.2% were able to get a TXT or Unknown rtype on a direct connection, compared with 98.1% for TXT only and 97.0% for unknown only (and this unknown IS a meta type, so if anything will get shot down, it will).

So in conclusion, I was wrong, it actually is a myth that new RTYPES perform significantly worse than TXT records:  So don't be afraid to design new RTYPEs instead of shoving it into a TXT record: TXT records don't work better enough for this to be worth doing. 

> Paul

[1] ObIMO, the only place that makes sense: the recursive resolver is PROVED untrustworthy, and doing validation on the recursive resolver provides effectively no meaningful increase in security while creating a huge hit on reliability) 

[2] There was a bug in this test that before December 5th, would have the test try 169 rather than 1169.