Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Minutes IETF107: add
minutes-107-add-00

Versions:

Meeting Minutes		Adaptive DNS Discovery (add) WG
Date and time		2020-03-24 20:00 Meeting Local UTC
Title		Minutes IETF107: add
State		Active
Other versions		plain text
Last updated		2020-03-27

minutes-107-add-00

**********************************************************************
Agenda & Minutes
**********************************************************************
Chairs: Glenn Deen and David Lawrence
Notes: Barbara Stark (hopefully with help)
Jabber Scribe:

Etherpad is at:
https://etherpad.ietf.org:9009/p/notes-ietf-107-add?useMonospaceFont=true

Webex is at: (220 on webex)
https://ietf.webex.com/ietf/j.php?MTID=m342b913bf84bd74824d9dec9b153b872

Jabber is: add@jabber.ietf.org (104 people on jabber)

Blue Sheets are at the bottom of this etherpad page

ADD Agenda for IETF107
======================

1. Introduction to ADD WG [Chairs ]

2. Agenda Bash

3. 15min draft-arkko-abcd-distributed-resolver-selection [Jari Arkko/Ted
Hardie]

4. 15min discovery-selection directions [Tommy Pauly]

5. 20min draft-btw-add-home [Dan Wing]

6. 10min draft-reddy-add-server-policy-selection [Dan Wing]

7. 15min draft-mglt-add-rdp [Daniel Migault]

8. 15min ADD Q&A [Chairs et al]

*********************************************************************
Minutes
*********************************************************************
1&2. Introduction to ADD WG and Agenda Bash
Main Agenda:
https://datatracker.ietf.org/meeting/107/materials/slides-107-add-agenda

Glenn Deen started the meeting. Note the instructions on the first slide.
And note the Note Well.
No bashing of the agenda on slide 4.
Glenn provided ADD history, while displaying the really nice pictures of the
chairs on slide 5.

Barry Leiba: As AD, had no comments at this time.

*********************************************************
3. draft-arkko-abcd-distributed-resolver-selection [Jari Arkko/Ted Hardie ]
Ted Hardie presented. Slides:
https://datatracker.ietf.org/meeting/107/materials/slides-107-add-dns-resolver-selection-arkko-hardie

Tommy Pauly: Thank you for coming up with this. First, when you have ordering
of common types, I would expect network resolver to be most common. It's
important for local network interaction to view local network resolver as
status quo. Otherwise, many assumptions will break, e.g., about provisioning
domains, etc. Reducing concetration of info is useful, but need to consider
privacy impacts not just in resolution but also in context of entire connection.

Mohit Sethi: Question about interface selection. I assume by interfaces you
mean wifi, eth, etc.? And then you use different resolver per interface? Some
devices can only do one interface at a time. What are impacts if interface is
not up? Do you allow use of a resolver discovered on an interface that is no
longer up and running?

Ted Hardie: If you have multiple ifaces, each with different resolver, it's ok
to have name resolution associated to specific iface. Do mechanisms developed
take this optimization into account?

David Lawrence (chair): Will close mic line after Warren.

Pete Resnick: Suggestion -- it does seem VPN case is subsumed by multiple
interface case because the VPN case is just multi iface where 1 iface is VPN.
So no need to separate out. Question -- If WG answers yes to first question,
what happens. Is this a WG doc? Is this just a use case doc?

Ted Hardie: This isn't really a good place to discuss the draft. But various
possible outcomes exist. It may also be that we decide we cannot achieve this
optimization.

Ben Schwartz: Yes, the WG should consider approaches that result in multiple
resolvers being discovered. As for optimization question, that relies on WG to
have increased understanding of where queries go. So maybe just say configs
that alter the concentration and leave it to future users/implementers to
decide what is optimal. As for 3rd question, we shouldn't guess at some of
these.

David Lawrence: 5 people left in queue. Please keep comments brief.

Sanjay Mishra: WG should look at these issues. Did you (draft authors) have
chance to see what impact different resolvers would have on performance.

Ted Hardie: No.

Sanjay Mishra: Would you consider looking at this?

Ted Hardie: The WG will need to answer performance questions more broadly.

Eric Rescorla (EKR): I think the best place for this draft would be as an
analysis draft. Please don't say we should treat network resolvers as status
quo.

Ted Hardie: There are some cases where we cannot assume sets of resolvers are
equivalent. <described several cases of how this might play out>

EKR: I'm suggesting focusing on the 2nd of the cases you described.

Chris Box: Using multiple resolvers imples multiple privacy policies. Some may
be "better" than others.

Glenn Deen: Thank you.

*************************************
4. discovery-selection directions [Tommy Pauly]
Tommy Pauly presented. Slides:
https://datatracker.ietf.org/meeting/107/materials/slides-107-add-adaptive-dns-paully

EKR: Once you control DNS, ESNI is lost. But that isn't necessarily true here.
Larger point is this seems to have some large failure cases. Take case of
resolvers A and B where A gets 90% of traffic. In this case, temporary traffic
shifts are hard to fix.

Tommy Pauly: ESNI does require DNSSEC -- that's true. But just because we
present this way doesn't mean DNSSEC isn't there.

EKR: Every ISP will want to advertise itself as authoritative. My concern is
that makes the traffic allocation at any point in time stable and hard to
change.

Tommy Pauly: I do want to get more input from the group on ths. I see 2
deployment scenarios. There could be a DoH resolver in charge of splitting
traffic between 2. Or there is no reason there cannot be 2 designated
load-balanced servers.

Erik Nygren: Is it accurate that ... <bad audio quality> ... and I'll put that
in the jabber chat.

erik: To EKR's concern, one approach would be that the
.well-known/pvd would have its domain be the SvcDomainName in
the HTTPSSVC record. For example with: "www.example.com 7200
IN CNAME foo.cdn1.example." and "foo.cdn1.example. 7200
HTTPSSVC 1 ." then if the policy is on
"https://cdn1.example/.well-known/pvd" it would apply for just
that one CDN. And since it is the A/AAAA records for
"foo.cdn1.example" which want to have lower TTLs and the
CDN-controlled mapping then this addresses the issue.

Tommy Pauly: Thanks. I'll look at that.

Andrew Campling: How do I as a user express my preferences? It looks like the
machine is taking control. How can I say I only want certain resolvers?

Tommy Pauly: Good question. That's something the WG needs to talk about. This
here is just about discovery of resolvers. I think what you describe is
follow-on discussion that's needed.

Ralf Weber: There might be some situations where this provides more info about
the client than the way things are now. The DoH or DoT server will get all
client info. Maybe that's something you can improve on.

Tommy Pauly: Good point. We need to take into account which resolver you're
using. If we could limit so that for google.com I'm only talking to Google
server, hopefully we can keep info from going elsewhere.

Ralf Weber: There are other requirements, too. Not just top level, 2nd level.

Puneet Sood: This works well where connectivity and DNS are operated by same
entity. For small ISPs, this may not be the case. In that case, there will not
be a net improvement for the client.

Ben Schwartz (from jabber): I understand how this scheme improves privacy when
combined with Oblivious DNS, but in the absence of Oblivious DNS (which is out
of scope for ADD) I think this is only a privacy improvement for certain
assumptions about TTLs, and some queries will leak when TTLs expire. I'd like
to see those assumptions clarified, and see if there is a simpler solution,
such as using long-lived CNAMEs. I'd also want some consideration about
whether these long TTLs are a tracking vector.

Tommy Pauly: Good comment and a discussion we should continue having.

Warren Kumari: I don't know what a Google name is. There are 1000s of names. If
I know a priori what maps then I don't need to ask a resolver. If I don't know,
then I have to ask a resolver.

Tommy Pauly: You can switch after you disover that something is a Google name.

******************************
5. draft-btw-add-home [Dan Wing]
Dan Wing presented. Slides:
https://datatracker.ietf.org/meeting/107/materials/slides-107-add-btw-add-home-wing

Jim Reid: Question about verified resolvers.

Dan Wing: The intent is that if you're a subscriber to Comcast, you would say
"I want Comcast-signed DoH servers" and then use them.

Martin Thomson: I think it's sad there are lists at endpoints. CPE don't get
upgraded in my experience.

Dan Wing: I'm familiar with and agree with that analysis.

Ralf Weber: The CPE angle is one I've thought ablout. There are ISPs who manage
their CPE, and those can be relied on to be up-to-date. Why DoH and not DoT
between client and CPE?

Dan Wing: the only thing preventing this from including DoT is the HTTP
redirect that can be used on DoH (caught this right?)

Ralf Weber: Maybe there is room to work on another protocol?

Dan Wing: We could consider that.

Wes Hardaker: You suffer with cached queries across resolvers. There are
choices to make.

Dan Wing: And also about prevent delays from short TTL.

Wes Hardaker: Pre-fetching can lead to pre-fetching of entire Internet.

**************************
6. draft-reddy-add-server-policy-selection [Dan Wing]
Dan Wing presented. Slides:
https://datatracker.ietf.org/meeting/107/materials/slides-107-add-redd-add-server-policy-selection-wing

Jim Reid: Would you expect it to be signed?

Dan Wing: Do53 could be interfered with by someone on path so it presents wider
attack vetors.

John Todd: Push seems very complex. Is there some reason other possibilities
were not considered, like TTL?

Dan Wing: TTL seems like it might be a nivce way to solve.

Allison Mankin: There is advice on creating privacy policy in draft in dprive.

*******************************
7. draft-mglt-add-rdp [Daniel Migault]
Daniel Migault presented. Slides:
https://datatracker.ietf.org/meeting/107/materials/slides-107-add-dns-resolver-discovery-protocol

Puneet Sood: This may tie in well with draft Dan and I wrote. Who is generating
list of available resolvers? When the client is getting the response, where is
the server with the list of resolver names?

Daniel Migault: Companies will have to register to have their DN pointed there.
That's on slide 8. I don't know who will take care of that. It could be IANA?

Puneet Sood: 2nd question?

Daniel Migault: Go to slide 9. Does that answer 2nd question? The person
responsible for example.com...

Puneet Sood: Who is responsible for server that is responding to client? Are
you envisioning a new operator?

Daniel Migault: I'm envisioning something shared by operators. Like IANA.

David Lawrence: Take this off-line.

Ben Schwartz (from jaber): https://public-dns.info/ has 11,000 resolvers. Do
you propose to publish them

Daniel Migault: Yes.

Harald Alvestrand: If you define business model where someone has monopoly on
who gets to participate, you're asking for trouble. We shouldn't do that.

Daniel Migault: I think this list will exist anyway. As long as the process is
open I think it's solvable. I do understand the risk.

Harald Alvestrand: You might want to look into complexities currently
experienced with authorizing CAs.

*************************************
ADD Q&A [Chairs et al]

Glenn Deen: This is your opportunity to make a comment.

Martin Thomson: I saw a lot of concentration on topic of discovery mechanisms
without really understanding the principles and requirements driving. There
were different approaches presented. Are we talking about networks providing
info or something else?

Paul Hoffman: One of the things that drove creation of this WG was question of
how can I upgrade from unencrypted to encrypted DNS. It seems that would be
easy to solve but I saw no proposals.

Simon Hicks: We're looking at technical details; but when are we going to talk
about the user experience (talk about all of this from the user perspective)?
We seem to be lacking the ability to allow user choice.

David Lawrence (hatless): This seems to me to be a pervasive consideration
rather than something that needs to be brought up in each of the docs.

Chris Box: I want to agree with Martin Thomson. We need to discuss principles
and requirements first. But it is tricky.

Jim Reid: Need to look at impact to enterprise networks of various solutions.

Andrew Campling: Going back to point about user. Note that user might be
enterprise administrator or parent. We need to make sure this isn't just about
providing the client with options. The "user" who needs to be considered may
not be the literal user of the client.