Minutes for DPRIVE at IETF-92
minutes-92-dprive-3

[ The chairs wish to thank Aziz Mohaisen for taking minutes ]

Meeting: DPRIVE meeting
Monday, March 23, 2015

What: DPRIVE
When: MONDAY, March 23, 2015, 1520-1650
Where: Venetian

Administrivia
---------------
Warren / Tim
10 minutes
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dprive-4.pdf
Chairs (Warren speaking)

Note well (the slide wasn’t there, but everybody agreed that they had seen it
before)

Status update:
DNS privacy consideration document was submitted to IESG for publication
Plan for this meeting:
Need to decide on way forward and get one of the three documents to move
forward. Perhaps will choose multiple and one of them will likely not move
forward.
=================================================

Evaluation of Privacy for DNS Private Exchange
-----------------------------------------------
Allison Mankin
10 minutes
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dprive-5.pdf

Notes:
Asked for adoption of the draft in the WG upon implementing some updates
proposed by the WG (mainly Stephane B.) Issues 1 addressed in the draft passive
pervasive monitor. Active monitor: we define this to allow people to talk
precisely about what kind of attackers they are defending against. Quick key
overview of the system model Quick key overview of attack model, system model,
mechanism parameters, privacy goals, and evaluation of the various techniques.
Issue 2 (TODO): add the broker into the system model so that it’s easy to
address some of the issues not being captured in other systems. Expand system
model – monitor that is in systems. Fill the TODO (including evaluation
templates)

Comments and Questions:
Stephane: it’s a good exercise to read the document and use by others. Please
go ahead and do that.

Marcos: it is striking that the problem statement does not use this
terminology. It’s confusing. I know this is not the problem statement; but we
should be consistent.

Stephane: we should be consistent with other documents, and be careful not
using attacker by eavesdropper and observer; the essence of RFC 6973

Andrew S: if the terminology draft is that important, we should get it out as
soon as possible so that we are consistent across different documents
(including this one).
======================================

Private-DNS
--------------
Phillip Hallam-Baker
20 minutes
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dprive-6.pdf

Notes:
Objectives:
Privacy: Traffic analysis resistance and Confidentiality
Authenticity: eliminate response spoofing, and guarantee user’s choice of
resolvers.

Service: protect resolver and protect third parties.

Constraints: must work in 100% network circumstances, cannot increase latency,
and a modest performance penalty is acceptable for dealing with edge cases
(they are driven from OCSP experience).

Browser vendor question: I am very wary of comparing to OCSP for performance
guidelines. Philip: when I suggested a protocol for doing the OCSP, they
(browser vendors) said these are the requirements to consider.

Architecture: a long-term connection to your DNS service providers specified by
the users; json-format that uses TLS to establish a connection to the server.

Connection life is determined by the needed property; short for better privacy

Comments and Questions:
Allison M comment: there’s a lot of similarity in the long/short circuit time
with Tor, and certain privacy concerns are there – an attacker can correlate.

Willem Toorop: the end user would use their DNS providers and stick with it.
However, most places don’t have web DNS to support this.

Philip: it’s a requirement and you have at least to have that as an option. The
way it’s done in this work is that DNS privacy protection is being bundled with
antivirus.

Resolution protocol: on top of UDP; simple session layer with one packet
request and 0-16 response packets, where every message is authenticated and
encrypted. A message can contain padding to guard against traffic analysis
attacks.

TLS wrap above the packers in HTTPS or TLS in addition; provides a fallback
protocol with near 100% connectivity.

Eric from Mozilla: circle to the example where a user can choose his DNS
provider in the coffee shop; however you have to view your adversary as a
passive or active attacker. Answer (Warren): we aren’t decided which adversary
model is the one considered in this context. We assume that the user will
perhaps use one DNS service and stick with it.

Applications: anonymous use where requests are not authenticated and enterprise
connections come with other features.

Complexity strategy: resolution protocol is very simple, framing is described
in 2 pages using the TLS schema syntax;

Open questions:
Is there an additional layer for crypto? Can easily add an intermediary layer
of crypto, and waiting for the CFRG ECC outcomes.

Questions:
Andrew: based on the architecture you have, we could be doing it anyway with
DNS 2. Why don’t just do DNS 2? Philip. I mentioned that I am compatible with
DNS 2; this work provides an escape path. Jon from NLLab: the service is
provided with antivirus, so why do you bring it here? Philip: we wish we could
this over standard. Paul Huffman: the charter says “this wg would provide
confidentiality between users and DNS resolvers”.

===============================================

Why not progressing my stand-alone proposals
Paul Hoffman
5 minutes
Slides: None.

The drafts are expiring and going away. A dual system that I will describe is
going to cover some of the ideas in some of the previous documents.

==============================================

draft-hzhwm-dprive-start-tls-for-dns
--------------------------------------
Allison Mankin
20 minutes
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dprive-0.pdf

Notes:
Draft presentation (DNS over TLS)

Protocol overview
Provided an overview since things have changed from the last IETF meeting.

Design choices
The DNS infrastructure is still same, but the client needs to be modified
some middle boxes block unassigned tcp ports, but some middle boxes still block
tcp/53. Our proposal works with authenticated and opportunistic tls

Eric: three observation; if you get the ip address through dhcp, then
validating the certificate cannot help you very much; 2) you can slightly
enhance the interface by telling the resolver some additional information and
give it a certificate (or a domain name; fingerprint; etc.); 3) if you are
going to the opportunistic and not opportunistic path, then you should provide
a way to fall back.

Paul (Answer for the last point): it’s unlikely that someone would be
connecting to a computer for any reason, and not having access to DNS.

Continuing the discussion (additions since the last version):
It’s now a two step process: try a port-based, and if that does not work go to
TLS Added more about motivation throughout the document Documented a few more
open issues, and added Paul as a co-author.

(Switching to Allison Mankin) We have an implementation out there, and the
implementation is not changed. We have a lot of experience with DNS over TCP.
Note that there is no reason to open and close TCP between stub and recursive;
they are long lived; tuning matters – a few seconds as opposed to few packets

Peter: the part with the initial synchronization should be up for some
discussion. Allison: yes Peter: what is the assumption of the end system that
uses the resolver? Demon, applications using stateless resolvers, among others
(end-points). The number of TCP queries might be a bit bigger than one can
envision here. Allison: there is the dns-op document which specifies when a
client is using tcp; it implies that a client would reuse the existing
solution. Paul Huffman (follow up on the answer): we don’t have a model; it
could be a model, but it’s not part of the specs. Paul (not Huffman): we use
encryption anyway, so I am not sure what the document adds. I am a little
confused; as I am not sure if this document is addressing any issue. John
Heidemann: there is a number of people who use public dns, where they don’t
have vpn. West (?): having a problem finding out how this is going to solve
bootstrapping problem for authentication. Philip: TCP can do anycast really
badly. Changing that ups the cost immensely. The other way is to do with
deployment; opportunistic shouldn’t be something we should architect for. --:
scaling TCP (having 3 browsers on the same host) is not known to be scaled
well.. --: blocking tcp is different from blocking unauthorized tcp;
middleboxes do intelligent decisions and they may fail, but unauthorized tcp is
blocked in anyway. --: is there any encryption over UDP? Allison: the next talk.

====================================

draft-wijngaards-dnsop-confidentialdns
Glen Wiley
10 minutes
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dprive-1.pdf

Uses both TCP and UDP; algorithm agility, cacheable IPv4and6 on port 53
Not adding much latency
From the prior version, we simplified a bit; others are increasingly complex.
Also encrypt dns rcode and optional authenticated keys with DNSSEC. Requires an
RRtype ENCRYPT; there’s rollback if encryption fails for any reason.

Comments and Questions:
Question (Tim) is it tested?
Glen: only in our dreams
Paul: I don’t think this is TCP/UDP in anyway. The other issue, with the
current specs, you are not doing a DH (he meant the diffie hellaman key
exchange) to get a symmetric key, and if it’s used but it’s not forced so the
client has to do more computations than TLS. I am not convinced on that we can
do it over UDP. Glen: those are things that are worth looking at. Philip: you
don’t want to do any ECC / public key work before getting authenticating of
source ip addresses. Before you forward your packet to an A; you are forced to
do some public key operations, which opens a window for a denial of service
attack. -- (question): this is the first attack that smells like DNS; with the
other solutions that do lightweight authentication (cookies), I think this can
be made to work. --: what’s the plan for addressing head of the line blocking.
Glen: we didn’t try to solve some of the specifics, so this is something to
look at. --: who is going to switch to TCP? Allison: 5966 explains that you can
pipeline.

=======================================

The way forward…
Warren / Tim
15 minutes
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dprive-3.pdf

Notes:
The way forward. One draft or many?

This doesn’t have to be final as things may change as we go forward.

Multiple options:
Private-dns
Draft-hzhwm
Draft-wijngaards

Hums:
Adopt 1
Adopt multiple
Don’t have enough information so we can decide

Peter: What does it mean that you don’t know enough?
Warren: Go home, read the drafts, and vote later on the mailing list.

Warren: the first hum will be “I would like to adopt a document”.
“I would like to adopt multiple documents”
“we cannot make a decision at this point”

No conclusion; spend some time on the mailing list.

Question: is there any way to do a binary decision on any of them.
Yes: yes, we can do that.

--: I am more interested in having this problem solved than having my work
accepted. I want those who adopt to come along and accept whatever we agree on.

Warren: having a select few of people to decide the way forward is not the way
the IETF works.

From Christian Huitema, Microsoft: why I personally like option B (hzhwm)– it’s
the one the makes the least possible innovation.

Voting and hums:
Overwhelming vote in favor of hzhwm
Overwhelming hum against private DNS
Neutral hum for confidential DNS