Subject: [perpass] draft-hzhwm-start-tls-for-dns-00: Starting TLS over DNS

From: Zi Hu <[email-masked]>
Date: Fri, 14 Feb 2014 19:03:31 -0800

We recently posted draft-hzhwm-start-tls-for-dns-00 ("Starting TLS over
DNS") to explore one proposal to add standard TLS over standard DNS to
improve privacy.
http://tools.ietf.org/html/draft-hzhwm-start-tls-for-dns-00

This topic may be of interest to DNSOP and PERPASS.  Some of the authors
will be at the London IETF and can discuss it at the DNS privacy BOF if
there is interest.

An obvious concern about combining DNS and TLS is the performance
implications, both for client latency and server state.  The above i-d
focuses only on the protocol parts, but we have a separate technical
report at ftp://ftp.isi.edu/isi-pubs/tr-688.pdf that evaluates these
questions.

We would love feedback on either document.

thanks
-Zi Hu

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 15 Feb 2014 15:01:33 +0100

On Fri, Feb 14, 2014 at 08:58:47PM -0800,
 Paul Vixie <[email-masked]> wrote 
 a message of 76 lines which said:

> this is good work.

I fully agree. But do note we did not discuss yet the alternatives
(draft-wijngaards-dnsop-confidentialdns, DNScrypt or simply
IPsec). The BoF "DNS encryption" in London seems a good start 
<http://trac.tools.ietf.org/bof/trac/wiki/WikiStart> and 
<https://datatracker.ietf.org/wg/dnse/charter/>.

> i recommend it be adopted by the working group, 

DNSOP? Some people say it is outside the charter since it is a
modification of the protocol. I myself are not favorable to an
ultra-strict interpretation of the charter so I'll hummmmmm with you.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Feb 2014 20:58:47 -0800

Zi Hu wrote:
> ...

this is good work. i recommend it be adopted by the working group, and i
will act as a reviewer.

vixie

---

From: Tony Finch <[email-masked]>
Date: Sat, 15 Feb 2014 15:40:48 +0000

> DNS") to explore one proposal to add standard TLS over standard DNS to

I like this. The general approach of the extension looks sensible to me.

Some comments:

   This document defines only the protocol extensions necessary to
   support TLS negotiation.  It does not describe how DNS clients might
   validate server certificates or specify trusted certificate
   authorities.  Solutions for certificate authentication are outside
   the scope of this document.

This absolutely needs to be defined before the protocol is deployed and I
think it is a huge mistake to rule it out of scope.

SMTP made this mistake (RFC 3207) and as a result most certificates
offered by SMTP servers cannot be validated, and SMTP over TLS is
vulnerable to MITM attacks. Fixing this is a huge headache. I don't
want to see it happen again.

But solving this problem is really hard especially in this context :-(

A DANE-like approach might work for authoritative servers.

Dunno about stub <-> recursive connections...

2.1.2.  Receiving Responses

   A DNS client that receives a response using UDP transport that has
   the TO bit set MUST handle that response as usual.  It MAY record the
   server's support for DNS-over-TLS and use that information as part of
   its server selection algorithm in the case where multiple servers are
   available to service a particular query.  [For discussion: UDP is
   subject to spoofing and a client which depends on TO=1 in a UDP
   response may be tricked into never upgrading to TLS.]

This is also true for DNS over TCP. It would be nice to have some stronger
protection against downgrade attacks. Point 3 in the security
considerations needs more thought.

   A DNS client that receives a response to its initial query using TCP
   transport that has the TO bit clear MUST not initiate a TLS handshake
   and SHOULD utilize the existing TCP connection for subsequent
   queries.

I think in this situation it would be better for the client to go back to
using UDP. Existing DNS servers do not handle TCP queries concurrently, so
the client will suffer much worse performance by continuing to use TCP.

2.4.  Middleboxes

   2.  The DNS client sends a TO=1 query and receives a TO=1 response,
       but the TLS handshake fails because the server's certificate
       cannot be authenticated.  In this case the client SHOULD close
       the established connection and fall back to unencrypted DNS for a
       reasonable period (as discussed in Section 2.1.2).

Having said that certificate validation is really important, I still think
that unauthenticated encryption is strictly better than nothing, since it
defeats passive (but not active) eavesdropping. But this kind of soft
failure is a great way to introduce downgrade attacks.

3.  Performance Considerations

This section should require servers to handle DNS queries over TCP and TLS
concurrently. They should be prepared to send responses as soon as they
are available, and out of order when necessary, to avoid head-of-line
blocking. This minimises the performance penalty relative to UDP.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 15 Feb 2014 08:44:27 -0800

Dear all,
This proposal has multiple shortcomings compared to DNSCurve.

First off, it says that the rationale for TLS over DNSCurve is simply
to "take advantage of TLS". I would respectfully submit that DJB can
do a better job than the TLS committee, and did. Merely adding bolts
and nuts onto a design is not improving it.

Secondly, this proposal only works on TCP. This imposes latency and
state requirements that most people would rather avoid. The use of
keepalive only addresses computational burden, not state burden, and
with the DH speed records we have today unnecessary.

Thirdly, this proposal ignores entirely how to validate the server
over the TLS connection. Does it need a certificate? Who should be
allowed to sign it? How should it be validated? DNSSEC provides a PKI,
and this proposal provides another one. Their interactions will not be
fun.

Fourthly, there is substantial operational knowledge and deployed,
working, code implementing DNSCurve. This does not hold for this
proposal.

Sincerely,
Watson Ladd

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 15 Feb 2014 17:52:56 +0100

On Sat, Feb 15, 2014 at 03:40:48PM +0000,
 Tony Finch <[email-masked]> wrote 

> A DANE-like approach might work for authoritative servers.

It is mentioned in the draft but it raises an interesting
chicken-and-egg problem when you want to secure DNS with info found in
the DNS.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 15 Feb 2014 17:57:18 +0100

On Sat, Feb 15, 2014 at 08:44:27AM -0800,
 Watson Ladd <[email-masked]> wrote 
 a message of 25 lines which said:

> working, code implementing DNSCurve.

While you raise some interesting points, this specific one pushes me
to ask you a list of domain names secured by DNScurve (DNScrypt is a
bit different).

In exchange, I can produce a list of Web sites secured with TLS.

---

From: Tony Finch <[email-masked]>
Date: Sat, 15 Feb 2014 17:23:57 +0000

> chicken-and-egg problem when you want to secure DNS with info found in

Very interesting :-)

The resolver needs to find out that an auth server supports TLS before it
sends a query. This implies that the information needs to be part of the
referral. It would be wrong to shoe-horn it into the DS RRset (e.g. by
adding semantics to one of the algorithm fields) since DS records relate
to the zone not to the name servers. So it should go into the NS RRset -
but referral NS records aren't signed!

Maybe the resolver could go and ask elsewhere. This could be quite
plausible for out-of-zone name servers, but it does not help for in-zone
server names. Or use the reverse DNS?

No palatable options that I can see :-/

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Malin, Hebrides, Bailey: Northwest 7 to severe gale 9 decreasing 4 or 5,
occasionally variable 3 later. Very rough or high, becoming rough later.
Showers, squally at first. Moderate or poor becoming good.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 15 Feb 2014 10:08:30 -0800

> and nuts onto a design is not improving it.

has mr. bernstein's Curve25519 (see
http://en.wikipedia.org/wiki/Curve25519) been explicitly validated by
other crypto experts? last i knew he was the only one claiming it was
correct and strong enough for production use. this matters, because no
one person ought to be trusted to get something like this right sans
review. mr. bernstein's competence isn't being questioned, it's just the
"second set of eyes" requirement for technology at scale. i'm speaking
as an x.509-hater, which means, i tend to agree with what you said about
committees.

as a bolter-onner of many of dns's nuts including EDNS, i'm ready to
quibble with anyone who says DNS has not been improved by the post-1987
work that's been done to it. i won't claim it's gotten prettier, but
that's not the only metric for "improvement".

> with the DH speed records we have today unnecessary.

my understanding is that this is a hop-by-hop cover protocol for adding
confidentiality when needed, and that something like dnssec will still
be needed for end-to-end content authenticity. in that sense the tcp
requirement isn't itself burdensome, though i will certainly recommend a
block-cipher mode so that udp can also be supported. this is not
something we can fix with DTLS or SCTP because of the all-pervasive
"middlebox problem". even getting EDNS options through has proved
difficult, a completely new transport is unthinkable.

> and this proposal provides another one. Their interactions will not be

see above; i don't think this proposal offers or intends to offer a PKI,
merely a hop-by-hop confidentiality option. DNSSEC will still be required.

> working, code implementing DNSCurve. This does not hold for this

dnscurve was offered to the ietf community but it didn't stick for
reasons unrelated to this newer proposal. i don't see any sense in
comparing their installed bases.

> Watson Ladd

warmly,

vixie

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Feb 2014 10:36:35 -0800

> This proposal has multiple shortcomings compared to DNSCurve.

And some advantages over DNSCurve.

> and nuts onto a design is not improving it.

That is a value judgement that cannot be measured. While DJB's crypto
algorithms have been widely adopted, his crypto protocols have not.

> with the DH speed records we have today unnecessary.

That is a measureable criticism. Note that DNSCurve trades latency and
state for massive amounts more computation by parties who might not care to
do any. Even after many years, there has been no noticeable interest in
DNSCurve from those whom that protocol would hit the hardest.

> over the TLS connection.

True.

> Does it need a certificate?

No.

> Who should be
> allowed to sign it?

"Allowed"? Are we now the identity police?

> How should it be validated?

Using TLS authentication.

> DNSSEC provides a PKI,

They in fact might be fun; they have barely been explored.

> working, code implementing DNSCurve. This does not hold for this
I question "substantial" and  "operational" at the level that is expected
for this protocol. Regardless, there is substantial operational knowledge
of TLS that dwarfs whatever has been done for DNSCurve.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Feb 2014 10:38:34 -0800

Cherry-picking the worst of the assertions...

On Sat, Feb 15, 2014 at 10:08 AM, Paul Vixie <[email-masked]> wrote:

> other crypto experts?

Yes.

> last i knew he was the only one claiming it was
> correct and strong enough for production use.

It has been widely discussed with no papers showing any flaws at all.

The crypto is not in question: the rest of the protocol is.

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Sat, 15 Feb 2014 10:46:40 -0800

> as an x.509-hater, which means, i tend to agree with what you said about

Do you mean the curve or the implementation? The answer is that
Curve25519 passes all
requirements on elliptic curves: it is safe against all known attacks.
You can validate this
in a few minutes with PARI. The implementation has been validated as
well, including a test
against independent implementation I did a few years ago.

As for review, considerable effort exists on solving DLP on curves. It
is a very thoroughly studied problem.

> merely a hop-by-hop confidentiality option. DNSSEC will still be required.

If we don't have authentication, we don't have confidentiality: MITM
is possible.

Secondly, "hop-by-hop" means what for DNS? If all this secures is the
connection between a client and the full resolver, then this doesn't
protect the confidentiality of anyone doing a DNSSEC query, as
resolvers cannot return the data required to validate DNSSEC. It also
doesn't protect against the cache recording what is being looked up.
All it protects against is someone eavesdropping on the cache, and
because we aren't putting in certificate validation requirements, it
doesn't even protect against that.

> comparing their installed bases.

That reason was caches everywhere are very useful to reduce load on
DNS servers, and the dnscurve security model couldn't work with them
effectively. Perhaps we should work on PIR protocols to secure the
retrieval of information from caches: putting data into the cache
would still be an issue, but we could hide the number and names of
people who want the information that gets retrieved.

Sincerely,
Watson Ladd

---

From: Paul Wouters <[email-masked]>
Date: Sat, 15 Feb 2014 14:57:58 -0500 (EST)

On Sat, 15 Feb 2014, Stephane Bortzmeyer wrote:

(D)TLS for DNS makes a lot of sense to me.

> IPsec). The BoF "DNS encryption" in London seems a good start

"simply IPsec"? bootstrapping DNS from IPsec which relies on DNS is not
trivial (and the versign proposal seems to only deal with nameservers
with access to their reverse dns, which excludes the DNS servers that
really need the protection, those supplied by DHCP in coffeeshops,
and completely lacks understanding of IPsec realities such as NAT-T)

> ultra-strict interpretation of the charter so I'll hummmmmm with you.

At ietf87 it was planned to  have a discussion at dnsop about this
continued problem of drafts that fall between operations and extensions
and the fact that dnsext closed down. Nothing happened at ietf87 or
ietf88. I hope to see this as agenda item for dnsop this meeting.

We need a WG to discuss DNS innovation.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Sat, 15 Feb 2014 16:24:50 -0800

Watson Ladd wrote:
>> ... The answer is that Curve25519 passes all

SSH1 was safe against all known attacks, until the first one. turns out
"integer underflow" was not previously a known attack. let's all learn
some caution about what we define as "safety", lest the gods strike us
down for our temerity.

> If we don't have authentication, we don't have confidentiality: MITM

the MiTM problem is due to X.509 not TLS per se. DANE stops MiTM for
TLS. my comfort level with DTLS, or STARTTLS-over-EDNS, or TLS or SSL,
is the same: low with X.509 since most nation-state actors and many
criminal actors can feed any endpoint a certificate they will believe no
matter what the name is; high once we pitch X.509 into the ash bin of
history and get DANE running everywhere.

> resolvers cannot return the data required to validate DNSSEC.

all arguments of the form "DANE can't be deployed because of
middleboxes" beg the answer "we will have to send JSON over HTTPS using
a RESTful query to protect the last mile , see bortzmeyer's draft on
that subject."

> It also

well, yes. if someone wants to look stuff up in DNS without middleboxes
knowing what they looked up, they have to use a VPN.

> DNS servers,

well, no. caches everywhere are very useful to reduce latency for
clients. authority servers today must be so massively overprovisioned
for DDoS reasons that any multiple of normal load even if no caches
existed anywhere would be pretty much line noise.

vixie

---

From: Watson Ladd <[email-masked]>
Date: Sat, 15 Feb 2014 17:23:03 -0800

On Sat, Feb 15, 2014 at 4:24 PM, Paul Vixie <[email-masked]> wrote:
> "integer underflow" was not previously a known attack. let's all learn some
> caution about what we define as "safety", lest the gods strike us down for
> our temerity.

Fine: Curve25519 is just as dangerous as every other curve that passes
the current requirements.

> the MiTM problem is due to X.509 not TLS per se. DANE stops MiTM for TLS. my
> comfort level with DTLS, or STARTTLS-over-EDNS, or TLS or SSL, is the same:
> low with X.509 since most nation-state actors and many criminal actors can
> feed any endpoint a certificate they will believe no matter what the name
> is; high once we pitch X.509 into the ash bin of history and get DANE
> running everywhere.

Unfortunately this isn't in the draft. Furthermore, DANE only links a
server to a domain name: it doesn't let me know that the DNS resolver
with the name moescoffee.com is not the resolver for the coffee shop I
am in.  DANE could protect nameservers, but we already put the keys of
nameservers into DNS, and it's fairly easy to guess what query I am
sending to dns.ewr1.nytimes.com, so encrypting the query to that
server doesn't gain much. How does DANE work when we are dealing with
devices without domain names, like the router in Moe's Coffee?

> all arguments of the form "DANE can't be deployed because of middleboxes"
> beg the answer "we will have to send JSON over HTTPS using a RESTful query
> to protect the last mile , see bortzmeyer's draft on that subject."

So I was wrong: you need a validating stub resolver, which can still
use a separate recursive resolver to find things, so caches aren't as
bad as I thought they were.

> knowing what they looked up, they have to use a VPN.

So what does this draft change in that regard? I'm not really seeing
the gains to privacy that
were promised, except maybe against other evesdroppers on the same
segment who aren't using
active attacks.

> well, no. caches everywhere are very useful to reduce latency for clients.
> authority servers today must be so massively overprovisioned for DDoS
> reasons that any multiple of normal load even if no caches existed anywhere
> would be pretty much line noise.
>
>
> vixie
Sincerely,
Watson Ladd

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Feb 2014 18:31:09 -0800

> were promised, except maybe against other evesdroppers on the same

That. It is certainly one of the goals of the perpass effort. If one can do
better (such as detect MITMs so you don't have to communicate through one
if you don't want), that's great too.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 15 Feb 2014 19:34:14 -0800

> devices without domain names, like the router in Moe's Coffee?

i expect i'm about to defer to paul hoffman as to the details of DANE.
my coarse-grained understanding is that the distinguished name will come
from the first term of the URI, which means that the key fingerprint
will mostly be in normal ("forward") space but could be in in-addr
("reverse") space. it's a straightforward mapping problem, if moe's
coffee's router is at 192.168.1.1 for you, then moe's router's key
fingerprint had better be at 1.1.168.192.in-addr.arpa for you. exactly
how you bootstrap localized split-view DNS when NAT'd is a hard but
tractible problem. let's assume that moe's router's IP is
2001:200:dff:fff1:216:3eff:fe4b:651c and that his router's key
fingerprint is at
c.1.5.6.b.4.e.f.f.f.e.3.6.1.2.0.1.f.f.f.f.f.d.0.0.0.2.0.1.0.0.2.ip6.arpa. not
that i know why you want to contact moe's router but that's the question
you asked.

> > well, yes. if someone wants to look stuff up in DNS without middleboxes knowing what they looked up, they have to use a VPN.
>

TLS gets you privacy if you take X.509 out of the circuit. this proposal
is about adding TLD to DNS. other proposals have been made having the
goal of getting the world out of X.509 hell. it's the two proposals
together that give us privacy.

vixie

---

From: Watson Ladd <[email-masked]>
Date: Sat, 15 Feb 2014 20:02:42 -0800

On Sat, Feb 15, 2014 at 7:34 PM, Paul Vixie <[email-masked]> wrote:
> i expect i'm about to defer to paul hoffman as to the details of DANE. my
> coarse-grained understanding is that the distinguished name will come from
> the first term of the URI, which means that the key fingerprint will mostly
> be in normal ("forward") space but could be in in-addr ("reverse") space.
> it's a straightforward mapping problem, if moe's coffee's router is at
> 192.168.1.1 for you, then moe's router's key fingerprint had better be at
> 1.1.168.192.in-addr.arpa for you. exactly how you bootstrap localized
> split-view DNS when NAT'd is a hard but tractible problem. let's assume that
> moe's router's IP is 2001:200:dff:fff1:216:3eff:fe4b:651c and that his
> router's key fingerprint is at
> c.1.5.6.b.4.e.f.f.f.e.3.6.1.2.0.1.f.f.f.f.f.d.0.0.0.2.0.1.0.0.2.ip6.arpa.
> not that i know why you want to contact moe's router but that's the question
> you asked.

Because I'm in the coffee shop, connected to their wifi. I'm not
entirely sure of the semantics of arpa based key lookups, but I'll
take your word for it that it works correctly.

> TLS gets you privacy if you take X.509 out of the circuit. this proposal is
> about adding TLD to DNS. other proposals have been made having the goal of
> getting the world out of X.509 hell. it's the two proposals together that
> give us privacy.
>
> vixie

The crypto seems fine: you get the address you were looking for with
only the cache knowing about it. And then you turn around and connect
to the address given you by DNS. Onion-routing is the only solution to
this problem, but in that case you can onion-route the DNS lookups.

Sincerely,
Watson Ladd

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Feb 2014 13:28:07 -0500

Paul,
> criminal actors can feed any endpoint a certificate they will believe 
> no matter what the name is; high once we pitch X.509 into the ash bin 
> of history and get DANE running everywhere.

Your (valid) concerns re MiTM attacks are not about X.509 per se, but 
with the Web PKI as
adopted by browser vendors and the associated CAs.

Steve