**********************************************************************           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. 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 ... ... 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. **********************************************************************           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. 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 ... ... 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.