Minutes for DPRIVE at IETF-94
minutes-94-dprive-2

WG:                     DNS PRIVate Exchange (dprive)
Meeting:                IETF 94, Yokohama
Location:               Pacifico Yokohama
Date:                   2 Nov 2015
Time:                   17:10-19:10
Chairs:                 Warren Kumari
                        Tim Wicinski
Minutes:                Shane Kerr


---- Administrivia Warren / Tim 10 minutes

Status report from WG chairs

----
DNS over DTLS
draft-ietf-dprive-dnsodtls
Dan Wing
20 minutes

https://tools.ietf.org/html?draft=draft-ietf-dprive-dns-over-tls

Fragmentation and reassembly in DTLS

Shane Kerr: We have a separate draft for fragmentation. I think it
makes sense to treat fragmentation as a separate issue outside of
DTLS. I am not sure that fragmentation is a good idea, but I think it
is worth exploring in the general case.

Andrew Sullivan: It gives me hives. It's just not good. I get what
you're trying to do, but there is a point where the complexity will
tip you over the benefit you are trying to get. There are other
pressures that are making us look at DNS over DTLS... at what point is
it going to be the last straw. The complexity of this may be that.

Andrew Sullivan: The complexity of RR changing while fragmenting may
mean that the server should know that it is fragmenting, so that
complexity can go away. I agree that if you are going to pursue it you
should unify it.

Paul Hoffman: I agree that we have to do it all or not do it. There
has to be at least 4 areas and 12 working groups that have dealt with
this over time. I tend to go towards "don't do it". I don't mean it is
not a problem, but the SOLUTION is such a big problem... "don't do
it".

Paul Hoffman: I disagree with Andrew that the server should marshall
the whole answer... that is the right solution if the server is going
to do it. I believe that asking the server to do that is going to risk
failure. Not doing it is not a problem.

Warren Kumari: The fragmentation seems really scary. There's
fragmentation in IP and we found scary security issues. There's
fragmentation in IPv6 and we found scary issues.

Dan Wing: On security concerns... this is above the DTLS layer. So any
fragments will have passed the DTLS.

Christian Huitema: There are already 3 or 4 ways of doing this. I
would rather punt the problem until we have DTLS last call and not
doing it.

Ted Hardie: The tl;dr version is: fallback to TCP. Introduce it more
generally that anyone running over TLS can. Shane's proposal to move
it out as the general solution seems good.

Ted Hardie: I still think it is worth doing. Sending larger things
over UDP and the record layer will still be useful. I think it will be
valuable in other cases, so you can leverage those other values to get
people interested in the work.

Ted Hardie: I don't think it belongs in the "giant bucket". I think it
is a constrainable problem.

Ray Bellis: Whether I feel fragmentation is good or not, I think it
should be independent of the DTLS. I also agree with Andrew Sullivan
about maintaining the RRSET.

John Dickinson: So many things wrong, I think we should pull it.

Dan Wing: Okay, we will pull it.

----
DNS over TLS
draft-ietf-dprive-dns-over-tls
Allison
30 minutes

https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-01

Duane Wessels presents.

Sara Dickinson presents.

Duane Wessels asks audience for questions & feedback.

Tim Wicinski: Does anyone have anything against putting profiles in
another document?

Wolfgang Beck: My main question: how many sessions can you run in
parallel? 10000? This is the basic problem. We have 1 million per
server, but...

Duane Wessels: The document gives advice on optimizing performance in
this area, and cites some research one of the co-authors is doing. For
the most part the document does not make claims.

Stephane Bortzymeyer: I agree with moving profiles to a future draft.
I would also like that TLS and DTLS will be able to refer to the same
document. I have a question whether the DTLS folks are happy with this
solution.

Sara Dickinson: We have had some discussions between us, and we agree
that a combined, separate draft will work.

Dan Wing: That is the best way to insure consistency.

Andrew Sullivan: It strikes me that these are fairly fundamental
changes to a document at end-of-last-call. I recognize that in the
implementation it is not fundamental, but in terms of understanding
the document, it feels a bit rushed. I wonder if we need more
experience?

Sara Dickinson: Perhaps we have misrepresented. There are only two
changes, apart from the profiles.

Andrew Sullivan: I get that. It feels to me that the document - not
the software or the approach - we are moving things around that is
changing things.

Allison Mankin: This is a very extended last call. There are 2 weeks
left of it.

Andrew Sullivan: I am just asking. I am not trying to say "no".

Paul Hoffman: We might shift stuff into this security document. That
may change over time. I suspect that this will happen once people
start reading about opportunistic. Every time this has come up in the
IETF people very much cared about specific wording and specific
scenarios. I would not be surprised if it too months, simply because
of opportunistic encryption. I don't wish for that, but...

Allison Mankin: I think proposed changes are on the order of 3 or 4
sentences.

Christian Huitema: I like the change, I like the different scenarios.
This implies that there has to be some sort of client authentication.
It is probably goinig to be quite some draft.

Sara Dickinson: There are some things we can explore, not just in the
case of TLS certificates. We may be able to use DANE, or the whole
chain.

Christian Huitima: There is another issue there. If we look at serious
deployment in a large-scale service, I am a bit concerned that we will
have a merging of security for a large number of credentials.

Daniel Kahn Gillmor: Your first question was about client
authentication. I hear what you were saying about wanting a client
authentication, but I don't think that is the idea of having a
separate document.

Christian Huitima: I understand that. But it costs a whole lot of
money if I have 100 million customers. It costs me a couple of lines
each, so I need to have some way to control that.

Daniel Kahn Gillmor: I would be very interested in documenting more
about client authentication, but the first document is about server
authentication.  I would be interested in exploring client
authentication and privacy.

Warren Kumari: Does anyone think that we should split into separate
document?

<some hums>

Warren Kumari: Does anyone think that we should NOT do this?

<silence>

Warren Kumari: whoo hoo!

----
Stateless DNS Encryption
draft-krecicki-dnsenc
Ray Bellis / Mukund Sivaraman
15 minutes

Mukund Sivaraman presents.

Mukund Sivaraman: How many have read this draft. Okay... that's not
many.

Roy Arens: What's the fallback mechanism? Plaintext?

Ray Bellis: It's Mukund's first IETF, and it's not his work, so be
kind. :)

Roy Arens: I think you did very well, thank you for your presentation.

<applause>

Paul Wouters: If I insist on crypto then I can. I like the idea. I
have been a little reluctant to add baggage. But again, I am wondering
why not just set up IPSEC and do it that way. I'm not sure adding more
crypto solutions is a good idea.

Paul Wouters: We've also been trying to convey trust on the local
system for the AD bit. It turns out there are just way to many stupid
programs rewriting and updating /etc/resolv.conf. Perhaps the document
should just say "configure locally".

Paul Hoffman: I don't really like your draft for a number of reasons,
which I might like later, but I suspect that I won't. This opens up a
trivial DoS on servers. It is much easier for a client to create a
bogus message that the server has to spend a lot of effort on to
decrypt. If you add more state you can probably avoid DoS, but that
will open up another, and another, and in the end you have DTLS.

Paul Hoffman: The nice thing about TLS and DTLS is that when you are
under attack you can reject connections. This is why other working
groups have chosen not to do truly stateless. You will end up with
where we are already at. I think it will be semantically equivalent to
DTLS. I don't think we need a second thing.

Paul Hoffman: Also, this working group is supposed to focus on
stub-to-resolver. This draft requires entering in resolver into the
reverse tree. This is not possible for everyone operationally. You may
want to move your server a little - this is easy locally with DHCP. I
think this has some nice ideas but until they are worked out you are
better with DTLS.

Witold Krecicki <from jabber>: Using the reverse tree is only one of
two options.

Sara Dickinson: The discussion about overhead in terms of 10's of
bytes, this will be offset by whether you choose to pad to offset
query analysis.

Marc Mosko: I don't believe that returning a key under a key that has
been compromised will give you forward security. Putting a key in the
DNS record means you have a man in the middle attack.

Mukund Sivaraman: It's DNSSEC protected.

Andrew Sullivan: I want to thank you and your colleague for presenting
your work.

Mukund Sivaraman: It's only my colleague.

Andrew Sullivan: Thank you anyway.

Andrew Sullivan: The worry that I have is that this is quite a
different direction from other stuff that we have been working on.
It's really underspecified. At least 3 parts of it are excellent
solutions for a different Internet other than the one we have. The
problem of the reverse tree is an issue. To get this to work really
well we need to get our parents work with us. This seems like a really
big problem. Even though there are promising ideas here, this may be
the wrong solution.

<applause>

----
The Eval Document
Allison Mankin
10 minutes

Warren Kumari: How many people have read this?

Almost no hands.

Warren Kumari: The working group asked for this and the authors worked
really hard on this, so it would be nice if people read it.

Allison Mankin presents.

Allison Mankin: Will you adopt this? We can make it a bit shorter. Do
you want to keep references to out-of-scope work or not?

Warren Kumari: The working group asked for this. 80% of the room at
the last meeting seemed to think we should move forward. Who is
willing to commit to review this.

Paul Hoffman
Sara Dickinson
Andrew Sullivan
Ted Hardie
Benno Overeinder
Stephane Bortzmeyer
John Dickinson
Dan Wing
Wendy Seltzer

Warren Kumari: Who thinks we should adopt this document. Hum now.

Andrew Sullivan: I cannot believe we have a working group where we had
4 or 5 last time and 1 or 3 who claimed to have read it since the last
time. I think it's nuts to adopt it. Put it on the charter!

Warren Kumari: We can skip the adoption.

Andrew Sullivan: I would be happy if in 2 weeks we had 5 people who
wrote to the list saying they read it.

----
DPRIVE TLS/DTLS Profile and Message Flows
draft-wing-dprive-profile-and-msg-flows
Dan Wing
15 minutes

Dan Wing presents.

Allison Mankin: Has TLS heartbeat been analyzed for risk?

Dan Wing: I don't know the answer, but we need a way to keep
NAT/firewall alive.

Christian Huitima: Heartbeat is just one way. The general rule is that
there is no way that works all the time.

Dan Wing: Absolutely. With networking nothing is sure to work.

Christian Huitima: Especially with NAT. It is unclear whether the best
solution is heartbeat or fast resume.

Dan Wing: Should we solve that? Or just pick heartbeat? Or just fast
resume?

Eric Rescorla: The failure mode if unsure about the state of the NAT or the
server is that you send packets out and don't get anything back and
timeout. Is there a guarantee where the NAT is confused that no
packets come back at all?

Dan Wing: No.

Eric Rescorla: It is very different to have fast-resume with fast-fail
than fast-resume with slow-fail.

Dan Wing: Anyway we need to pull that out and put it into a separate
document....

Dan Wing continues and finishes.

Paul Hoffman: I think that we can publish the flows draft when we
understand it. I think that when we talk about flows that we wait for
TLS/DTLS 1.3, because we know that there is significant enough change
that it is worth waiting.

Sara Dickinson: If you isolate from the document the message XXX part.
How much is DNS specific. It looks like it could be generalized. Maybe
better placed in the TLS working group. Did I miss something?

Dan Wing: Currently that is true for what it says right now. We don't
have anything that says how DTLS fails over to TLS. I would like this
document talk about DTLS.

Sara Dickinson: Failover is about DTLS fail to TLS.

Dan Wing: Actually failing back and forth from DTLS to TLS.

Sara Dickinson: It might be better in the TLS working group though.

Eric Rescorla: I have not read the draft so I cannot comment.

Paul Hoffman: I would support it staying here. There are not other
places where people have said "we might do it over TLS or DTLS". I
would want the TLS people to look at it and make it right.

Warren Kumari: I am a little concerned we don't have the right set of
knowledge.

Paul Hoffman: Not currently, but we also don't have a draft. Also
hopefully TLS 1.3 will be done and they will have time to look at
this. I am not worried that we will not have enough review.

Paul Hoffman: There is also a workshop (TRON) to get people who are
not active in the IETF to look at TLS 1.3 and tell us if we got it
right. If this is a working group document by then, I am sure some
eyes at TRON will look at it.

Dan Wing: There is also presumption that people want this as a working
group document.

Warren Kumari: How many people have read the document?

[About 5 or 6 hands]

Warren Kumari: How many people will read it?

Eric Rescorla and Christian Huitema raised hands.

----
The way forward...
Warren / Tim
15 minutes

Warren Kumari discusses the plan.

Asks for people to read the DTLS document.

Toerless Eckert
Christian Huitema
Sara Dickinson
Stephane Bortzmeyer

Warren Kumari: What is the next step?

Stephane Bortzymeyer: Recursive to Authority. More and more people
will have their own resolver due to lying resolvers (legal reasons).
But if you run your own resolver you are not behind a large, shared
cache. It is very important that we address this step.

Daniel Kahn Gillmor: I would be very sad if we don't try to tackle the
authority resolver step. Also operational guidance for people who want
to deploy this.

Daniel Kahn Gillmor: I know it's not my place to ask for adoption for
other people's drafts, but EDNS padding should be adopted somewhere.
Then if someone wanted to do good research on what good padding
policies are they could do that.

Warren Kumari: Do the authors want it to be adopted?

Allison Mankin: I agree strongly that we should work on this.

Mark Andrews <from jabber>: Another problem is that people don't trust
recursive servers.

Tim Wicinski: I think we should be chasing performance, and make a
testbed on the TCP stuff.

Warren Kumari: That seems interesting and useful but not necessarily
DPRIVE.

Tim Wicinski: I don't think we

Tim Wicinski: As co-chair of DNSOP, the padding will stay here.

Paul Hoffman: I think it is premature to deal with recursive to auth
until we have some experience with it. The assumptions that people are
making about round trips from recursive to auth need work. We should
get implementation experience. The biggest question for recursive to
auth will be TLS or DTLS.

Shane Kerr: I think that any recursive to the group will look a lot ,
why wait

Paul Hoffman: We needed experience to get going. Say we do push it out
and we sort of get it wrong. If we make a mistake on authoritative
servers it will be a much longer deployment cycle. I would like to
feel more confident about that one. I don't want to wait a long time.

Allison Mankin: I have been think we have a window of opportunity.
People get used to privacy violation - we are aware of that now.

Warren Kumari: It sounds like people are interested and willing.

----
Performance art / interpretive dance.
5 minutes

https://www.youtube.com/watch?v=QHZR9SA5pOg