Subject: [dns-privacy] [Step 2] More discussion needed: state your opinion

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 13 Dec 2016 11:59:36 +0100

In the minutes of the Seoul meeting, we see:

Strong hum for sticking around to work on this.
Terry (as AD): more mailing list discussion, please

So, this email is to request this
discussion. draft-bortzmeyer-dprive-step-2-04 is published, with all
the remarks from the Seoul meeting integrated. Now, it is time to give
an advice on things like:

1) Use TLS for the resolver-to-auth link, or not?

2) Which authentication(s) to use?

---

From: Shane Kerr <[email-masked]>
Date: Tue, 13 Dec 2016 15:46:25 +0100

Stephane,

At 2016-12-13 11:59:36 +0100

> 1) Use TLS for the resolver-to-auth link, or not?

I think that TLS may be more painful in the resolver-to-auth case, as
TCP Fast Open will be generally less useful, right?

But what are the other alternatives?

DTLS is mentioned in the draft. Do we have any benchmarks or
simulations as to the expected relative benefits of DTLS vs. TLS for
DNS?

IIRC the idea of using IPsec was also discussed somewhere. IIRC, IPsec
may have problems traversing NAT. It is also usually implemented by the
kernel, which may cause deployment issues. I *want* IPsec to be an
option here, but realistically I don't think it is.

The other alternative is to invent some novel crypto (fun but
ill-advised) or steal some equivalent (like the crypto part of
DNScurve, also mentioned in the draft). After TSIG, DNSSEC, DNS
cookies, and the rest, it would be weird if DNS used something
standard, but maybe we can try it for once? ;)

> 2) Which authentication(s) to use?

I really like the CGA approach, but realistically I don't think that
would be accepted. If we think that it would be, then I'm all for it.

----

Otherwise I think we should lean towards putting authentication tokens
in the DNS itself.

AIUI the draft, if we want to use DNS the problem is that we want to
know how to encrypt a session to a name server, but we can't look up
anything about the name server in the DNS because we don't yet know how
to encrypt a session to the name server.

Is it possible to tie the authentication to the domain instead of the
name server?

We could say sessions looking up EXAMPLE.COM use certificate 1234,
regardless of which name server they are talking to.

If we could do this, then we could even publish certificate 1234 in a DS
record, and then it would be returned by the parent. (We can use a new
type for this, which is more elegant but requires server modification
and protocol changes.)

There are several advantages of this:

* no bootstrapping issues

* no modification to existing software needed for parents

* an observer/attacker cannot know that a resolver is going to use an
  encrypted session unless they observe the actual session between the
  resolver and authoritative server (which is unavoidable)

Also some disadvantages:

* a single authoritative server may have to configure thousands of
  certificates (although of course this is less of a problem for
  hosters that are the masters of the zones, as they can share
  certificates between zones)

* keys must be shared across administrative boundaries (that is, if I
  use Dyn and FreeDNS for hosting, then both hosters can impersonate
  the other or decrypt traffic to the other)

* resolvers can't just store certificates with the name server
  information

* could be interpreted as another layer of indirection in the DNS ;)

Cheers,

--
Shane

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 13 Dec 2016 16:41:33 +0100

On Tue, Dec 13, 2016 at 03:46:25PM +0100,
 Shane Kerr <[email-masked]> wrote 
 a message of 120 lines which said:

> I think that TLS may be more painful in the resolver-to-auth case,
> as TCP Fast Open will be generally less useful, right?

Same thing (even worse) for persistent TCP connections.

But the problem is made less serious by the huge concentration of
authoritative name servers (this concentration is a bad thing, but it
helps for clients who maintain per-server state, which would be the
case with TCP Fast Open). Among the Alexa top 100k, only 24 k servers
<https://blog.imirhil.fr/2015/02/18/vie-privee-dns.html>

> IIRC the idea of using IPsec was also discussed somewhere. IIRC,
> IPsec may have problems traversing NAT. It is also usually
> implemented by the kernel, which may cause deployment issues. I
> *want* IPsec to be an option here, but realistically I don't think
> it is.

Eric Rescorla talked about it at the London BoF
<https://www.ietf.org/proceedings/89/slides/slides-89-dnse-5.pdf>

> ill-advised)

This was the opinion defended by Mukund Sivaraman at the Seoul
meeting, and this is why draft-krecicki-dprive-dnsenc is mentioned in
my draft (there is also draft-wijngaards-dnsop-confidentialdns).

> anything about the name server in the DNS because we don't yet know
> how to encrypt a session to the name server.

I disagree. We can look up without keys. It just has to be without
privacy. See for instance the discussion on
draft-ietf-dprive-dtls-and-tls-profiles, specially
<https://mailarchive.ietf.org/arch/msg/dns-privacy/U9bGDAOReP_zYc4tPZY4AdWc2eM>

> * keys must be shared across administrative boundaries (that is, if
>   I use Dyn and FreeDNS for hosting, then both hosters can
>   impersonate the other or decrypt traffic to the other)

This is for me a stopper.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 13 Dec 2016 11:24:29 -0500 (EST)

> <https://www.ietf.org/proceedings/89/slides/slides-89-dnse-5.pdf>

"IPsec probably isn't going to work here" is a rather week conclusion.
It seems mostly based on "I think people still firewall that stuff".
Regardless of that, IKE over TCP is a draft that's currently going to
go into WGLC any time now. And it can be encapsulated in pseudo or real
TLS to break through misconfigured (or administratively blocking)
networks. Which gives TLS and IKE/IPsec the same penetration
capabilities.

Also, if/when TLS would be used for encrypted DNS, malicious code will
appear to use that as an exfiltration side-channel, so any middleware
inspector device will go and MITM those connections anyway or simply
block them. So I doubt this while "TLS will always get out the network
for free" will be true in the long term.

People might remember I did an IKE/IPsec presentation on that it can
be used to protect DNS traffic when all this talk about using TLS or
custom DNS encryption RRTYPE's came up, and when people talked about
dnscrypt, which is just a generic VPN with a policy to only allow DNS.
Which is why I wanted to remind people that we have existing technology
in IETF that would work fine as a solution without re-inventing the wheel:

https://www.ietf.org/proceedings/93/slides/slides-93-dprive-4.pdf

It surely can work fine. IKEv2 allows IPsec clients to remain anonymous
while authenticating the server, basically giving IKE a "TLS-like"
security with anonymity. You can find an example using LetsEncrypt
for IKE/IPsec at:

http://events.linuxfoundation.org/sites/events/files/slides/LinuxSecuritySummit-2016-OE-16x9.pdf

The only real differene between using IKE/IPsec and a "bolt on" crypto on
the DNS packets is the generic difference between TLS and a (IP base) VPN.
A VPN protects host-to-host traffic, and TLS protects a single stream.
That has both advantages and disadvantages. And note TLS can be used
both as a single stream of IP based VPN deployment:

Pro VPN:

- With IKE/IPsec (or generic VPN), multiple DNS (UDP and/or TCP)
   connections do not need to use their own separate crypto handshakes
- Encryption can be "long lived" (eg hours) so no need crypto
   negotiation needed when you don't send queries for 5 minutes and
   all your TCP/UDP sessions were terminated by the DNS server.
- IPsec/IKE or TLS can run on seperate hardware from the DNS server.
- No modifications needed for DNS software - re-usable technology.

Conn VPN:

- With IKE/IPsec (or generic VPN) it becomes harder for the DNS
   authoritative server to know if a connection is unencrypted or
   encrypted. While that might not matter for the privacy element,
   as we will assume the DNS server will respond to all DNS clients
   regardless of its privacy level, it might make a difference for
   DNS-COOKIEs and other anti-amplification counter meassures that
   the server might want to do.
- offloading crypto to seperate hardware introduces an unencrypted
   DNS stream between hardware and DNS servers.

> privacy.

Even better, since you are going to setup a secure connection to that name
server anyway, there is no privacy lost by querying for its public key
in DNS out in the open.

Anyway, just some more data points of IKE/IPsec vs TLS. It's like
margarine versus butter. I can't believe that's not butter versus
trans fats will actually kill you of faster.

Paul

---

From: John Heidemann <[email-masked]>
Date: Tue, 13 Dec 2016 10:01:51 -0800

>TCP Fast Open will be generally less useful, right?

You're correct that connections are less sticky from recursive-to-auth,
and so persistent connections and fast open are less helpful.  From the
server's perspective, they are still helpful---we see about 90%
connection reuse in replays of root-server traffic with a 30s connection
timeout (see figure 2c in http://www.isi.edu/~johnh/PAPERS/Zhu16b.pdf ).

But the set of clients seen by a root is somewhat
skewed by the number of bogus clients.  From the *client* perspective,
we see less connection reuse from recursive-to-auth: only about 25% with
a 30s connection timeout (figure 8 in the paper).

The other real cost is in memory for state (memory that is in both TCP
and TLS, so DTLS doesn't make it go away).  Memory at auths is much
higher if all traffic is TCP, but well within the reach of current
servers.  Our estimate was about 4GB of connection state at a root with
a 30s timeout window.

>simulations as to the expected relative benefits of DTLS vs. TLS for

It seems unlikely that there would be significant benefit from DTLS.
The only thing DTLS saves is the SYN / SYN-ACK RTT,
otherwise it runs the same TLS handshake.  The SYN / SYN-ACK RTT can also be
avoided with TCP fast open, if you get a cache hit.
The main place where DTLS wins is not performance, but in allowing out-of-order
packet processing once the connection is setup.
(If you drop a query packet after handshae, you don't need to recover it
before processing later ones).

Our experiments with TCP fastopen and persistent TLS are basically the
same performance as UDP when you get a cache hit (compare bars e and f
vs. bar a for Figure 6 in that paper).  So the main performance question
is: how often do you find an already open connection.

>standard, but maybe we can try it for once? ;)

Can you please clarify, what is the problem IPsec or novel crypto is
trying to solve?

   -John Heidemann

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 13 Dec 2016 11:16:08 -0800

> option here, but realistically I don't think it is.

IPsec will always have worse characteristics for DOS than DTLS, and 
probably worse than TLS. Why do want it to be an option here?

> The other alternative is to invent some novel crypto (fun but

If what we invent has better characteristics than DTLS or TLS, that 
means that the TLS WG failed to find something that we could. That seems 
*incredibly* unlikely, given the people active in the two WGs.

> or steal some equivalent (like the crypto part of
> DNScurve, also mentioned in the draft).

The "crypto part of DNScurve" could be added to (D)TLS.

> After TSIG, DNSSEC, DNS

Yes.

> would be accepted. If we think that it would be, then I'm all for it.

Why do you think it would not be accepted? It could be used where 
available, and fall back to current authentication when it isn't.

> Otherwise I think we should lean towards putting authentication tokens

OK, now I'm confused. I thought this is what you meant by "CGA 
approach". Can you explain the difference?

> to encrypt a session to the name server.

The draft drifts towards that, but I don't think it is the right problem 
statement. Instead, we should be going towards "encrypt wherever 
possible, but don't limit yourself if you can't."

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 13 Dec 2016 14:36:35 -0500 (EST)

On Tue, 13 Dec 2016, Paul Hoffman wrote:

> IPsec will always have worse characteristics for DOS than DTLS, and probably 
> worse than TLS.

[citation needed]

Paul

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 13 Dec 2016 11:44:22 -0800

> *incredibly* unlikely, given the people active in the two WGs.

Actually, QUIC might provide an answer, if you are willing to wait a couple
years. Runs over UDP, uses TLS 1.3 key negotiation, encrypts pretty much
everything, enables 0-RTT, and manages multiple flows. A one-query per
QUIC-flow model would provide better service than TCP because it does not
suffer from head of queue blocking, and better service than DTCP because it
does not limit the amount of data sent in queries and response. But of
course, the QUIC WG is just getting started, so it will probably take two
years before we can start deployment of something like DNS over QUIC.

-- Christian Huitema

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 13 Dec 2016 12:39:13 -0800

On 13 Dec 2016, at 11:36, Paul Wouters wrote:

>> probably worse than TLS.

Amount of state needed to be kept on the server for each connection from 
resolvers

As for other reasons that IPsec will have worse (or at best the same) 
characteristics as (D)TLS 1.3:

- Number of round trips before data can be sent from the initiator

- Inability for parties to get the configuration wrong

--Paul Hoffman

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 13 Dec 2016 23:16:53 +0200

On Tue, Dec 13, 2016 at 11:16:08AM -0800, Paul Hoffman wrote:
> worse than TLS. Why do want it to be an option here?
> 
> If what we invent has better characteristics than DTLS or TLS, that means
> that the TLS WG failed to find something that we could. That seems

If you mean state size per connection, doing better than TLS seems very
easy.

E.g. if you don't need rekeying, you don't need to keep ladders. Or
if you really want to save space, use the same keys in both directions,
with different nonce spaces.

-Ilari

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Dec 2016 22:40:09 +0000

(With no hats...)

On 13/12/16 19:44, Christian Huitema wrote:
> years. 

Yeah, I think QUIC might be good here. And maybe the 2 years
isn't so bad either...

Given that a fallback to TCP/TLS is likely needed even if the
right answer is QUIC, and given that however the WG decide to
address server authentication and session management should
work just as well for TCP/TLS as for QUIC... maybe the WG could
experiment with TCP/TLS in the medium term with the longer
term plan being to move to QUIC with TCP/TLS as the fallback
whenever QUIC seems ready for primetime.

There're probably some flaws in the above, but it might be a
plan.

Cheers,
S.

> Runs over UDP, uses TLS 1.3 key negotiation, encrypts pretty much
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Shane Kerr <[email-masked]>
Date: Wed, 14 Dec 2016 10:21:13 +0100

Stephen,

At 2016-12-13 22:40:09 +0000

> There're probably some flaws in the above, but it might be a

This seems reasonable to me. It basically implies that we should insure
some small amount of agility in the encrypted channel, which seems like
a good idea anyway.

This approach is independent of the trust problem, which I think is
trickier, but it means we could in principle get working
implementations in the near/medium-term. :)

Cheers,

--
Shane

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 14 Dec 2016 10:46:16 +0100

On Wed, Dec 14, 2016 at 10:21:13AM +0100,
 Shane Kerr <[email-masked]> wrote 
 a message of 90 lines which said:

> > address server authentication and session management should work
> > just as well for TCP/TLS as for QUIC... maybe the WG could
> > experiment with TCP/TLS in the medium term with the longer term
> > plan being to move to QUIC with TCP/TLS as the fallback whenever
> > QUIC seems ready for primetime.
...
> This seems reasonable to me. It basically implies that we should
> insure some small amount of agility in the encrypted channel, which
> seems like a good idea anyway.

I smell practical and programming issues there. Soon,we will have four
ways for a DNS client to talk to a name server, UDP, TCP, TLS+TCP,
DTLS+UDP, and no guidance on how to combine them, in which order to do
so (think of the "happy eyeballs" problem), what to do if some
fail... Adding a fifth, QUIC+TLS, won't help. What will the poor
client be supposed to do?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 14 Dec 2016 10:55:04 +0100

On Tue, Dec 13, 2016 at 11:16:08AM -0800,
 Paul Hoffman <[email-masked]> wrote 
 a message of 60 lines which said:

> means that the TLS WG failed to find something that we could. That
> seems *incredibly* unlikely, given the people active in the two WGs.

+1 for me.

It may be that we do something better than the TLS WG because they
have to do something generic, while we can tune for DNS
specificities. Even with that in mind, I'm skeptical we can design a
better protocol without creating new security issues.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 14 Dec 2016 12:18:17 +0100

Stephane,

At 2016-12-13 16:41:33 +0100

> <https://blog.imirhil.fr/2015/02/18/vie-privee-dns.html>

I suspect among the top 1M there is probably even more concentration,
given that companies are more likely to outsource hosting (both DNS
and web).

> <https://mailarchive.ietf.org/arch/msg/dns-privacy/U9bGDAOReP_zYc4tPZY4AdWc2eM>

So basically you are advocating a model where meta-data (specifically
lookups of NS records and their associated A/AAAA records) is public
and other data is private?

It's a "better than nothing" solution, but I'm going to push for a
complete solution if it is not too complex and/or expensive.
 
> This is for me a stopper.

Thinking about this a little more, there is no reason that multiple
authentication tokens could not be published. So Dyn could have token
1234 and FreeDNS have token 5678. When the Dyn servers present token
1234 a resolver could see that it is on the list of acceptable tokens.

Presumably this kind of logic would be necessary for key rollovers,
just like in the rest of DNSSEC, right?

Cheers,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Wed, 14 Dec 2016 12:34:54 +0100

Paul,

At 2016-12-13 11:16:08 -0800

> probably worse than TLS. Why do want it to be an option here?

IPsec seems desirable because somehow it seems better to be able to
layer on top of security at the lowest level possible? Layer 3 instead
of layer 4?

Although I guess the only extra information we would be exposing with
TLS or DTLS would be the port numbers, which seems minimally useful to
an attacker.

> available, and fall back to current authentication when it isn't.

CGA requires IPv6, and the hash is only 60-some bits long, so maybe it
is both too futuristic and not future-proofed at the same time. Like I
said, I really like it but I can see push-back.

> > Otherwise I think we should lean towards putting authentication
> > tokens in the DNS itself.  
> 

CGA authenticates IP addresses by encoding the public key in the
address itself. Because of this there is no need to publish a public
key; if you have the IP address you can already authenticate the holder
has the private key. There is literally nothing else for DNS to publish
beyond what it already does (the IP address of the authoritative DNS
server).

If we don't use CGA then we have to publish the public keys somehow.
Those keys are the authentication tokens that we have to publish, and I
think that DNS makes sense for this.

> possible, but don't limit yourself if you can't."

I think that's fair, but I'm not sure that we have to give up on full
encryption. Maybe, but lets see if we can figure something out! :)

Cheers,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Wed, 14 Dec 2016 12:37:39 +0100

Stephane,

At 2016-12-14 10:46:16 +0100

> client be supposed to do?

I agree this is a pain.

If only there was a way to publish information about a server's
preferences....

Cheers,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Wed, 14 Dec 2016 12:40:25 +0100

John,

At 2016-12-13 10:01:51 -0800

> Can you please clarify, what is the problem IPsec or novel crypto is

Encrypting the session between the resolver and the authority server? ;)

I am just enumerating the options as I understand them. As Stephane
points out, both IPsec and novel mechanisms have been proposed for this
problem; and neither by me!

Cheers,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Wed, 14 Dec 2016 12:58:28 +0100

Paul,

At 2016-12-13 11:24:29 -0500

> server anyway, there is no privacy lost by querying for its public key

That assumes that the server will be publishing its own information. I
don't think that this is necessarily true - although perhaps it can be
made a requirement (or recommendation) for encrypted communication?

But yes this is actually a fairly compelling observation. :)

Cheers,

--
Shane

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 14 Dec 2016 14:57:20 +0100

On Wed, Dec 14, 2016 at 12:37:39PM +0100,
 Shane Kerr <[email-masked]> wrote 

> If only there was a way to publish information about a server's

There is one: DANE (at least to express that you support - or not -
TLS and DTLS).

For UDP and TCP, may be using SRV?

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 14 Dec 2016 07:24:44 -0800

> TLS or DTLS would be the port numbers, which seems minimally useful to

Exactly. Further, you have to negotiate in IPsec which ports and 
addresses within the "range of one target address" the client has access 
to, and that (you would think simple) negotiation has proven too 
difficult for some IPsec developers in the past.

> said, I really like it but I can see push-back.

Got it. I thought you meant "CGA-like DNS", not actual CGA. DNScurve's 
method of having he key in a DNS label is "CGA-like DNS" to me. I happen 
to like it a lot.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 14 Dec 2016 10:46:19 -0500 (EST)

On Wed, 14 Dec 2016, Paul Hoffman wrote:

> Exactly. Further, you have to negotiate in IPsec which ports and addresses 
> within the "range of one target address" the client has access to, and that 
> (you would think simple) negotiation has proven too difficult for some IPsec 
> developers in the past.

It's not 1999 anymore. Negotiating IP addresses and ports for DNS is not
a problem in the slightest.

Paul

---

From: John Heidemann <[email-masked]>
Date: Wed, 14 Dec 2016 08:57:56 -0800

>Encrypting the session between the resolver and the authority server? ;)

Of course.  But rfc7858 could already cover that case with DNS-over-TLS,
so presumably you have some *additional* set of constraints you care
about, for which IPsec or novel crypto improves over rfc7858.

>problem; and neither by me!

Exploring and comparing options is well worth doing.  I was hoping to get a
clearer problem statement to make that comparison.

There's a bunch of possible trade-offs: client latency, server memory,
client memory, novelty vs. maturity of design, maturity of libraries,
support by other groups, design complexity, ...

You suggested earlier in the thread that rfc7858 was weaker than some
alternatives for recurisive-to-auth traffic, so I was trying to figure
out for which metrics you think it is weaker.

   -John

---

From: Shane Kerr <[email-masked]>
Date: Wed, 14 Dec 2016 17:58:31 +0100

Paul,

At 2016-12-14 07:24:44 -0800
> method of having he key in a DNS label is "CGA-like DNS" to me. I happen 

I agree, publishing the key in the DNS label is actually quite a clever
hack. But does this count as "novel security"? :)

To be honest, I don't see any major drawbacks to something like this
approach.

We could perhaps use something like "xn--" to identify names which
contain keys (I propose "djb--", although maybe we should ask Mr.
Bernstein before adopting that). That leaves 58 characters in a label,
which is enough for around 300 bits if encoded in base 36 (alphanumeric
only) - that seems enough for a fingerprint right? And multiple labels
are possible if needed.

Cheers,

--
Shane

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 15 Dec 2016 09:02:38 +0000

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of
> Stephen Farrell
> Sent: Wednesday, December 14, 2016 4:10 AM
> To: Christian Huitema <[email-masked]>; 'Paul Hoffman'
> <[email-masked]>; 'Shane Kerr' <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [dns-privacy] [Step 2] More discussion needed: state your opinion
> 
> 
> (With no hats...)
> 
> >> seems
> > Actually, QUIC might provide an answer, if you are willing to wait a
> > couple years.
> 
> Yeah, I think QUIC might be good here. And maybe the 2 years isn't so bad
> either...

How will DNS benefit from QUIC ?
DNS can use (D)TLS 1.3 just like QUIC using TLS 1.3.

-Tiru

> 
> Given that a fallback to TCP/TLS is likely needed even if the right answer is
> QUIC, and given that however the WG decide to address server authentication
> and session management should work just as well for TCP/TLS as for QUIC...
> maybe the WG could experiment with TCP/TLS in the medium term with the
> longer term plan being to move to QUIC with TCP/TLS as the fallback whenever
> There're probably some flaws in the above, but it might be a plan.
> 
> Cheers,
> S.
> 
> 
> > QUIC-flow model would provide better service than TCP because it does
> > not suffer from head of queue blocking, and better service than DTCP
> > because it does not limit the amount of data sent in queries and
> > response. But of course, the QUIC WG is just getting started, so it
> > will probably take two years before we can start deployment of something
> like DNS over QUIC.
> >
> > -- Christian Huitema
> >
> >
> >

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 15 Dec 2016 09:59:43 +0100

On Wed, Dec 14, 2016 at 12:18:17PM +0100,
 Shane Kerr <[email-masked]> wrote 
 a message of 87 lines which said:

> So basically you are advocating a model where meta-data
> (specifically lookups of NS records and their associated A/AAAA
> records) is public and other data is private?

Not at all. I'm suggesting (see the algorithm in
<https://tools.ietf.org/html/draft-bortzmeyer-dprive-step-2-04#section-3.2>
to switch to opportunistic mode (encrypt but do not try to
authenticate) when retrieving the DANE material. As soon as you get
enough information to authenticate, you go back to strict mode.

This is similar to what is suggested in
<https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-07#section-8.2.1>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 15 Dec 2016 10:09:16 +0100

On Wed, Dec 14, 2016 at 08:57:56AM -0800,
 John Heidemann <[email-masked]> wrote 
 a message of 49 lines which said:

> There's a bunch of possible trade-offs: client latency, server
> memory, client memory, novelty vs. maturity of design, maturity of
> libraries, support by other groups, design complexity, ...

Added to the future next version of the draft
<https://github.com/bortzmeyer/ietf-dprive-step-2/commit/5779cbf94605fbcd174bd5d57544150fc636e620>

> You suggested earlier in the thread that rfc7858 was weaker than
> some alternatives for recurisive-to-auth traffic, so I was trying to
> figure out for which metrics you think it is weaker.

The point was raised by Mukund Sivaraman at the Seoul meeting. If I
remember correctly, his main concern was the state to keep in the
client, because a resolver will talk to hundreds, even thousands of
authoritative name servers.

---

From: John Heidemann <[email-masked]>
Date: Thu, 15 Dec 2016 17:03:37 -0800

><https://github.com/bortzmeyer/ietf-dprive-step-2/commit/5779cbf94605fbcd174bd5d57544150fc636e620>

If you're updating, you might also add out protocol agility, something else that has
come up in this thread and before.

>authoritative name servers.

Thank you---state for outgoing connections on a recursive resolver
could be an issue, and to my knowledge it has not been studied yet.

My initial guess is it's not much different from state for incoming
connections on a large authoritative, and that resource limits can be
handled the same way (start closing when you're low on resources).  But
a careful study here would be useful.

And of course, there is still state on the recursive resolver if queries
are sent over DTLS or IPsec, it's just different state in a slightly
different place in the stack.

   -John Heidemann

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 15 Dec 2016 17:17:53 -0800

> DNS can use (D)TLS 1.3 just like QUIC using TLS 1.3.

Because QUIC allows for application messages of arbitrary length. That means there is no need with QUIC to fall back to TCP when the message exceeds a certain size, and that's a big advantage over DTLS.

-- Christian Huitema