Skip to main content

Minutes for DPRIVE at IETF-95
minutes-95-dprive-1

Meeting Minutes DNS PRIVate Exchange (dprive) WG
Date and time 2016-04-06 13:00
Title Minutes for DPRIVE at IETF-95
State Active
Other versions plain text
Last updated 2016-04-06

minutes-95-dprive-1
WG:                     DNS PRIVate Exchange (dprive)
Meeting:                IETF 95, Buenos Aires
Location:               Atlantico C
Date:                   2016-06-06 (Wednesday 6 April 2016)
Time:                   10:00-12:00 ART (13:00-15:00 UTC)
Chairs:                 Tim Wicinski <tjw.ietf@gmail.com>
                        Warren Kumari <warren@kumari.net>
Minutes:                Shane Kerr <shane@time-travellers.org>

# Document status

# https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/
Dan Wing

Ready for working group last call

Sara Dickinson:
Have made comments that handling of sessions still slightly
unspecified.  More closely aligned to DNS over TLS than specified.
More alignment would help. A whole number of things that need to be
taken into account.

Dan Wing:
Achieve realignment... how?

Sara Dickinson:
Similarity and differences would make it easier for implementors.

Sara Dickinson:
Wondering what implementation status is. Questions about how it will
work in practice.

---

Paul Hoffman:
Which way to do comparison? We ended up having to add a lot of TCP-ish
stuff which you don't have. If you follow the same order as in UDP
stuff it would be a lot clearer.

Paul Hoffman:
I disagree that we need to have implementations. In the IETF we don't
do that.

---

Ted Hardie:
Note RTC web data channel (SCTP over DTLS), which is a "Foo over TLS".
You may want to contact them.

---

Sara Dickinson:
Wondering if we can make it an experimental? Is that an option.

Dan Wing:
It's a working group document. Whatever you want to do.

Warren Kumari:
One issue is getting review. Only small number of people providing
comments.

Warren Kumari:
After rearranging we can start a working group last call.


# https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/
Sara Dickinson

Ted Hardie:
Like this presentation. However, maybe opportunistic is covering too
much ground, and we should split it into the case of encrypted versus
fallback to clear text. Might be clearer to people looking at these
labels as to what these look like.

Sara Dickinson:
I agree. There are slides later which talk about that.

----

Christian Huitema:
Confused about the useage. It's a VPN to your resolver. That resolver
in my mind is authenticated by the client. "This is the resolver I
trust." That trust means it won't lie to me, share my data, do nasty
stuff with the DNS, etc. I want my DNS packet to go there.

Sara Dickinson:
That's "strict".

Christian Huitema:
When I read your draft I see a different model. My fallback case may
be that I don't send all of my traffic to a server. The interaction
between the dynamic model and the other model is not clear in the
draft.

Sara Dickinson:
The distinction is "choose whether to be strict or not", and then how
you choose to do that is a secondary consideration.

Christian Huitema:
But look at the information leak. The reason we do dprive is because I
don't want the guys in the coffee shop to know which DNS names I am
using. If I use opportunistic servers then it is almost the same as
disclosing my names.

Sara Dickinson:
In that situation you will either use strict or not. You're not going
to jump around.

Christian Huitema:
My suggestion is: there should be a usage model for this document.

----

Ted Lemon:
Confusion about opportunistic means that it is broken.

Sara Dickinson:
We didn't have "no privacy" to begin with, we added it for

----

Stuart Cheshire:
We're using DNS server to mean two different things, because of
historical accident. I was understanding this to mean "this is my
first hop to my recursive". If I configure 8.8.8.8 then I have privacy
to that. If other people are reading that differently, then there is
miscommunication.

Sara Dickinson:
We explicitly say that.

Stuart Cheshire:
I agree, but if there is confusion...

----

Christian Huitema:
Lookups are typically done gethostbyname() or somewhere in the bowels.
I don't get how the USER will make the decision?

Sara Dickinson:
It's not in the spec. That's one of the reason we worked on getdns to
expose the work to the user. But I agree.

Christian Huitema:
Am I supposed to pop up a warning to the user? "Hey grandma, we have a
decision where we can't reach a trusted resolver." Is that what we
want to do?

----

Stephane Bortyzmeyer:
I'm not sure I understand questions about usage models. But if I
understood, then I disagree. There are MANY MANY usage models. Too
many to list. So I like the approach of this draft, because it could
be realistic. We need something in between, even if it not easy to
describe it.

Stephane Bortyzmeyer:
Now for UI. There are a few UI points in the draft. It's typically not
our business. There are many ways to interact with the user, and we
don't know all of them. It's generally not a good idea to turn us in
to user interface experts. Up to software authors to give a choice.

----

Paul Hoffman:
Authentication by domain name only in scope. I think that's a mistake
since DHCP gives an address.

Sara Dickinson:
But you need a trusted and secure DHCP. Which you don't have...

Paul Hoffman:
Saying this is only or coffee shops is too limited. Or if you have a
DHCP that says 8.8.8.8 and it has a certificate then you should be
able to use it.

Sara Dickinson:
I could see this happening in the future, but I don't want it to block
this document.

Paul Hoffman:
No, don't block just say it...

----

Christian Huitema:
Problem not discussed: what happens in enterprise network where you
*really* want to use the enterprise server. Versus when you are in a
coffee shop where you want to use your pre-configured resolver.

Sara Dickinson:
Do you see that as something we should specify?

Christian Huitema:
Describe the problem. It's a question of configuration.

Warren Kumari:
Would you be willing to provide a document that discusses this?

Christian Huitema:
Yes.

---

Stephane Bortyzmeyer:
Is it possible in a typical CA to get a cert for an IP address?
Describe the problem. It's a question of configuration.

Phillip Hallam-Baker:
Yes you could, but no you can't. I think that every service should be
accessible by a domain name, particularly in IPv6.

Dan Khan Gillmor (dkg):
I want to agree with Phil there. People want to be authenticating to a
server where they know what it is.

----

[refused to identify] (not dkg):
It seems to me that there are 2 scenarios:

1. We have a human-entered name. Mapped somehow to key material.
2. Machine-entered doo-dad, which came from somewhere else. Might be
   nice to have lookup for the key material...  but that won't work
   out well and you should either deliver a domain name or also
   include the key material.

----

Phillip Hallam-Baker:
Recently in Turkey people were posting "8.8.8.8" everywhere. The
problem there is that it was very fragile. What we saw is during the
middle of the day the traffic quadruplied at our public DNS when
8.8.8.8 was blocked. You only need to do this binding once, you don't
need to acquire the DNS address every time.

# Google DNS over HTTPS disclaimer

Warren Kumari:
Google DNS over HTTPS not designed to compare with DNS over TLS.

# TLS 1.3 update
Dan Khan Gillmor (dkg)

0RT (0 round trip) data has a number of subtle differences.

Differences:
1. Can't do client authentication.
2. Forward secrecy guarantees are different and less.
3. No replay detection.
4. Client privacy (sessions can be tracked across the network).

Shane Kerr:
No client authentication?

Dan Khan Gillmor (dkg):
Only for 0RT, which is session resumption.

----

Ted Hardie:
You can handle this with client limits (like time).

Dan Khan Gillmor (dkg):
Yes, as long as the server can store that state. In anycast situation
we don't have any guarantees that this will happen.

Dan Khan Gillmor (dkg):
There are mitigation strategies.

Ted Hardie:
There are strategies to limit this. In anycast your 0RT resumption may
only be valid for the server you got to first.

----

Paul Hoffman:
Correction. Only the first query is replayable.

Dan Khan Gillmor (dkg):
All queries in the 0RTT.

Paul Hoffman:
If you have 1 query, then that is 1 query.

Dan Khan Gillmor (dkg):
Until you have gotten the 2nd part of TLS back, you can replay.

----

Stephen Farrell
Good analysis. Hope other FOO over TLS do the same thing.

Stephen Farrell
Reasonable to do recursive to authority?

Dan Khan Gillmor (dkg):
Yes. Also, client has the option to construct a profile that avoids
showing the session ID, but not for resumption. Important to insure
that DNS over TLS clients only resume a given session.

----

Christian Huitema:
Should have a discussion about TLS privacy issues discussion. Not DNS
specific.

Dan Khan Gillmor (dkg):
I agree. But as a DNS community we can say "you must use this kind of
profile as a DNS client".

----

Ted Hardie:
If I get session resumption ticket, if I use that resumption ticket on
that network for the first time then it is safe because I can link it
to the recursor but not to the client. So never *re-use* on a new
network.

Dan Khan Gillmor (dkg):
I think we need to be sure that queries coming from the same IP
address may not be from the same client.

Ted Hardie:
That's worth writing down.

----

[refused to identify] (not dkg):
In (TLS) 1.2 if you wish to have new sessions you must re-issue new
connections.

Dan Khan Gillmor (dkg):
Yes.

----

Allison Mankin:
Should we have have text in the DNS over TLS documents?

Terry Manderson (AD):
I don't want to see this text in those documents. I'd like to see it
in a separate document for dprive.

----

Phillip Hallam-Baker:
There are ways you can do it if you allow server state...

Dan Khan Gillmor (dkg):
Sounds like we are brainstorming TLS resumption patterns, and maybe we
should do this somewhere else....