Minutes IETF109: add
minutes-109-add-00

Session 2: Friday, November 20, 2020
Session link, minutes, jabber
Meetecho remote
participation
Minutes
Meeting chat
IETF 109 ADD Session Times
ADD has 2 sessions during IETF109: Session 1 is Monday November 16; Session 2
is Friday November 19

Session 2: Friday, November 20, 2020 (UTC+7)
Time in different zones:

ICT: 12:00-14:00 (UTC+7) IETF Agenda TZ and Bangkok meeting “location” time
IST: 10:30-12:30 (UTC+5.5)
CET: 06:00-08:00 (UTC+1)
UTC: 05:00-07:00 (UTC+0)
EST: 00:00-02:00 (UTC-5) Note: This is Midnight Thursday into Friday in EST
PST: 21:00-23:00 (UTC-8) Note: This is Thursday November 19 in PST
Session 2 Agenda
Welcome
NOTE WELL
Scribe selection Chris Wood/Tim Wicinski
Agenda bashing
Drafts
(Agenda bashing)

Martin: What do we expect to gain from IP address cert discussion?
Glenn: There’ve been some issues about them (would it work? is it practical?) – the goal is sort out these issues.

Discussions
Continue to Discuss Concept of Equivalent Resolvers found in
Draft-pauly-add-deer-00
and draft-box-add-requirements-01

Eric Orth:

if things are working well, keep working well (including latency, cache characteristics, and other relevant UX properties).
Privacy perspective - user trust or privacy preferences should not change or deviate from what they selected. Identical results are not sufficient if the resolver is not trusted like the user’s choice.
EKR: Agree w/Eric, two properties - results and connecting to them and not third party. A resolver that answers identically but also does other suspicious things (publish queries on Twitter) is not equivalent. Hard to describe response similarity when performance characteristics change, but perhaps easier to describe in terms of resolver authenticity. Last sentence in the definition should be struck entirely.

Ben Schwartz: Asking resolver to be equivilant, and what the client can do to identify and verify equivilant resolver. There are some
observable properties that we want client to verify. Clients verify A has operation al control over B and B is the item in control by A

EKR: Suppose an ISP that operates a Do53 resolver is too lazy to run DoH and instead just wants to forward queries to 1.1.1.1. Is this an equivalent resolver?

Glenn: Goal 1 is to get upgrade equivalent to current behavior. Goal 2 is discovery of what’s available (possible?) and what information to convey back to the client to make an informed choice.

Ralf Webber: We initially said an equivalent reoslver is done by the same entity, but some people said that’s insufficient. Shouldn’t this simple definition work for most cases (but not the lazy ISP example)?

Ben: along EKR’s line, abusing term equivilant. “designated encrypted
resolver” is pehraps a more accurate (and achievable) definition.

Joey Salazar: Equivilancy thru same entity and equilivancy through same resolution answers, plus their verification. We should focus on the simpler scenario of same entity and its verification, then move towards the other user-cases including equivalent resolution and designated resolvers, along with their implications on service expectations and user consent and such.

Martin Thomson: EKR’s example highligted - need to throw equivWhat is relevant and what is not is somewhat irrelevant without differences in privacy policies. Expectation about privacy posture end with what the network gives you.

Andrew Campling: Moving away from equivalent to designated may change privacy properties and user expectations (and may have implications on things like GDPR). “Equivalence” is important for same-provider-auto-upgrade. Equivalence matters for some contexts, but not all, and that has to include “the same parties, and the same results.” Equivalence may require some sort of user permission first.

Daniel Migault: From the begining of this session, I tend to understand that the authorized or equivalent designated resolver is being managed by the same entity as the one managing the initial Do53 resolver. From the last session is seems that some raised the issue that is too restrictive and I am wondering what use cases they have in mind where an enquivalent resolver would not be managed by the same entity as the initial Do53. It also seems that we are restricting the discovery to a “single” encrypted resolver and I believe that we should consider a list of authorized resolvers instead. As a result, the discovery mechanism should enable the discovery of a list of resolvers. I see the discovery mechanism as a mean to derive the list of authorized/equivaent resolvers from an IP address - the one of an initial Do53 resolver for example, but the list should also be discovered from the other encrypted resolvers.

Ted Hardie: Equivalence means access to the same pool of names and same behavior with query data, or plainly about what data these resolvers can access. This is different from privacy properties, and should perhaps be an orthogonal statement, as statements about privacy posture (posting to Twitter or not) is much harder to verify. TL;DR: perhaps we need two statements: one on data access, and one about privacy policy

EKR: What are we trying to solve here? (Scope properties of the actual protocol.) The functional property is “designate a resolver”. The security properties are about limiting attacks in relevant threat models. Equivalence should take into account properties we need the system to have. Self-operated and affiliated is not necessary for the system, so preventing it may not be helpful. What we’re trying to accomplish is, “here’s a pointer.”

Ben Schwartz: Proving equivalence is fine motivating text, but probably shouldn’t be an actual requirement given it’s so challenging to prove. Maybe the requirement is “designated resolvers SHOULD be equivalent”? And equivalence should consider observable and non-observable properties.

Eric Orth: We’re in the policy area. We need multiple definitions for different concepts. Network-designated resolver, resolver-designated resolver, equivalent resolver, same-party resolver. Given them, and mechanisms to discover them, let clients implement their own policy.

Lars-Johan Liman:Decision about equilvance sits with client – not server. Perhaps “alternate” is a better term? Clients can decide if alternate resolvers are acceptable or not. We should focus on providing information to clients so it can make decisions about alternative resolvers. It’s not up to the resolver, RA, DHCP, etc. to declare equivalence. The picture may shift depending on who determines equivalence.

Kirsty P: Equivalence should consider circumstances or use cases like split DNS or “sketchy” resolvers. e.g. if I have splitDNS in my enterprise, I don’t want my internal private network leaked to a resolver I don’t expect. I don’t want my world view or DNS results changed based on an ‘upgrade’. We should separate the technical mechanism for A to recommend B, and conditions for when A should recommend B

Wes Hardaker: Ability to define equivalence is useful, but we need to give clients a way to verify certain properties.

Glenn Deen: Put in context: this proposal may have gained some legs without understanding the original context. The -01 version is a narrowed set of use cases where people wanted to work on it initially; this is not a necessary requirement for all upgrades but for that particular use case. Piece of information conveyed through discovery. This might fit into other use cases on the way.

Martin Thomson: Liked Ben’s proposal. Enable delegation from the network. That delegation has properties that are no worse than authentication properties one gets from talking to the Do53 server. And we would recommend that in addition to providing encrypted transport the resolver SHOULD do other useful things with respect to data.

Harald Alvestrand: Equivalence is misleading. It should be removed, and replaced with recomendations. (BCP-style?)

Puneet Sood: Using newer terms may make discussion easier to follow.

Eric Orth: (privacy/operator equivalence may help adoption by clients)

Andrew Campling: r.e. “entity operating the resolver doesn’t matter,” the entity operating the resolver does matter. If the entity changes, the user may need to be consulted.

Martin Thomson: We might care about who operates the resolver, but we’re explicitly talking here about no expressed preference beyond what the network instructs you to do.

Lars-Johan Liman: What we’re talking here is not equivlance, but rather what is (or is not) “acceptable” to the client.

EKR: Agree with Martin. DoH/DoT-aside, the network can steer you to any Do53 resolver with DHCP. Having generically stricter requirements about what kind of entity you can be steered to doesn’t make sense. DEER has good material about not making the situation worse. Requirements should say that we can include metadata for client selection. Technical requirement is basically “tell me where the thing is,” and that’s what DEER does.

Ben Schwartz: Heard couple of comments about non-delegation rule. Circumstances where DNS traffic not be steered to a different entity. Non-delegation is not an option, since clients can’t enforce it. DNS forwarder is indistinguishable from an iterative resolver.

Vittorio Bertola: At most we can make recommendations in this area. (we should focus on the mechanism to communicate a recommendation to the client)

Tommy Jensen: Some clients connect to servers to get DNS and have no opinions. There are other cases where the client has some a priori information (IP address) and wants to confirm that it’s talking to the “right” entity. Maybe split resolver-identified into resolver-identified-generic, and resolver-identified-specific? Separate use cases.

Andrew Campling: We should not try and second guess the user. For some users DHCP may be sufficient, so trying to do anything more (assuming that’s equivalent to user’s making no choice preference) seems wrong. We should go with equivalent with whatever the current settings are.

Lars-Johan Liman: We should primarily care about suggesting equivalent/alternative resolvers. Determining equivalence is then the task of the client as a secondary, followup task.

Ralf Weber: [note to chairs: capture notes starting around Time +1:05m into recording]

Ted Hardie: Probing will be error-prone (e.g. split-DNS property is hard to probe).

Daniel Migault: Going back to EKR’s comments. It’s important to understand the entity providing the list vs. the the entity operating the resolver.

Lars-Johan Liman: Do not see how resolver can declare equivalence. Who I trust as a client is a policy decision. Mechanisms to point clients to resolvers are simple and fine. We should focus on this mechanism, so we can give clients all they need to make an informed decision (according to policy).

Ted Hardie: designation or hint. semantic of what that “pro-tip” means must be pretty clear. some protocol mechanism is what the hint is.

EKR: We have a requirements document, and we have DEER. Suggest putting this on the shelf and whether or not we should adopt DEER.

Lars-Johan Liman: Mechanisms should include intended meaning of information, as that’s important for client decisions.

Puneet Sood: Agree with Ekr. Fundamental question is how much do we trust this information?

Tirumaleswar Reddy.K:

Tommy Pauly: A lot of bike shedding and word smithing, but little disagreement on the mechanism. It makes sense to unblock adoption of mechanisms, and keep them up to date with defintiions we happen to nail down during continued discussions. Also posit that it’s more productive for people to make textual proposals for terminology as PRs or email so we can review them at large.

Andrew Campling: Same entities and answers does matter in some cases. No problem with progressing other stuff.

Time Permitting: IP Addresses in Certificates
EKR: IP address certificates are available. LetsEncrypt does not currently do it.

Martin Thomson: IP address certificates are widely supported in clients (all browsers, curls, etc).

Tiru: Confirmed that LE does not provide IP address certificates as of now.

Jonathan Reed: It may be easy to get an IP address cert if you control the server and IP space, but not true for servers providing recursive or authoritative DNS as a service. Or any sort of appliation or service provider (?)

Tommy Pauly: Not all stacks support hard-coded (by IP address) resolvers.

Martin Thomson: IP SANs do make sense for 1918 addresses (with additional steps of course).

Ben Schwartz: Reading of DEER is that it assumes the IP address is sent over a secure channel.

Martin Thomson: DEER does have that posture, but it may not be the right posture.

Planning & Wrap up
10 min - Wrap up + Future Planning
Glenn: We're considering an Interim meeting for late January ahead of IETF110 in March. We'll be sending more informatino to the ADD list about it.

Session 2: Friday, November 20, 2020
Session link, minutes, jabber
Meetecho remote
participation
Minutes
Meeting chat
IETF 109 ADD Session Times
ADD has 2 sessions during IETF109: Session 1 is Monday November 16; Session 2
is Friday November 19

Session 2: Friday, November 20, 2020 (UTC+7)
Time in different zones:

ICT: 12:00-14:00 (UTC+7) IETF Agenda TZ and Bangkok meeting “location” time
IST: 10:30-12:30 (UTC+5.5)
CET: 06:00-08:00 (UTC+1)
UTC: 05:00-07:00 (UTC+0)
EST: 00:00-02:00 (UTC-5) Note: This is Midnight Thursday into Friday in EST
PST: 21:00-23:00 (UTC-8) Note: This is Thursday November 19 in PST
Session 2 Agenda
Welcome
NOTE WELL
Scribe selection Chris Wood/Tim Wicinski
Agenda bashing
Drafts
(Agenda bashing)

Martin: What do we expect to gain from IP address cert discussion?
Glenn: There’ve been some issues about them (would it work? is it practical?) – the goal is sort out these issues.

Discussions
Continue to Discuss Concept of Equivalent Resolvers found in
Draft-pauly-add-deer-00
and draft-box-add-requirements-01

Eric Orth:

if things are working well, keep working well (including latency, cache characteristics, and other relevant UX properties).
Privacy perspective - user trust or privacy preferences should not change or deviate from what they selected. Identical results are not sufficient if the resolver is not trusted like the user’s choice.
EKR: Agree w/Eric, two properties - results and connecting to them and not third party. A resolver that answers identically but also does other suspicious things (publish queries on Twitter) is not equivalent. Hard to describe response similarity when performance characteristics change, but perhaps easier to describe in terms of resolver authenticity. Last sentence in the definition should be struck entirely.

Ben Schwartz: Asking resolver to be equivilant, and what the client can do to identify and verify equivilant resolver. There are some
observable properties that we want client to verify. Clients verify A has operation al control over B and B is the item in control by A

EKR: Suppose an ISP that operates a Do53 resolver is too lazy to run DoH and instead just wants to forward queries to 1.1.1.1. Is this an equivalent resolver?

Glenn: Goal 1 is to get upgrade equivalent to current behavior. Goal 2 is discovery of what’s available (possible?) and what information to convey back to the client to make an informed choice.

Ralf Webber: We initially said an equivalent reoslver is done by the same entity, but some people said that’s insufficient. Shouldn’t this simple definition work for most cases (but not the lazy ISP example)?

Ben: along EKR’s line, abusing term equivilant. “designated encrypted
resolver” is pehraps a more accurate (and achievable) definition.

Joey Salazar: Equivilancy thru same entity and equilivancy through same resolution answers, plus their verification. We should focus on the simpler scenario of same entity and its verification, then move towards the other user-cases including equivalent resolution and designated resolvers, along with their implications on service expectations and user consent and such.

Martin Thomson: EKR’s example highligted - need to throw equivWhat is relevant and what is not is somewhat irrelevant without differences in privacy policies. Expectation about privacy posture end with what the network gives you.

Andrew Campling: Moving away from equivalent to designated may change privacy properties and user expectations (and may have implications on things like GDPR). “Equivalence” is important for same-provider-auto-upgrade. Equivalence matters for some contexts, but not all, and that has to include “the same parties, and the same results.” Equivalence may require some sort of user permission first.

Daniel Migault: From the begining of this session, I tend to understand that the authorized or equivalent designated resolver is being managed by the same entity as the one managing the initial Do53 resolver. From the last session is seems that some raised the issue that is too restrictive and I am wondering what use cases they have in mind where an enquivalent resolver would not be managed by the same entity as the initial Do53. It also seems that we are restricting the discovery to a “single” encrypted resolver and I believe that we should consider a list of authorized resolvers instead. As a result, the discovery mechanism should enable the discovery of a list of resolvers. I see the discovery mechanism as a mean to derive the list of authorized/equivaent resolvers from an IP address - the one of an initial Do53 resolver for example, but the list should also be discovered from the other encrypted resolvers.

Ted Hardie: Equivalence means access to the same pool of names and same behavior with query data, or plainly about what data these resolvers can access. This is different from privacy properties, and should perhaps be an orthogonal statement, as statements about privacy posture (posting to Twitter or not) is much harder to verify. TL;DR: perhaps we need two statements: one on data access, and one about privacy policy

EKR: What are we trying to solve here? (Scope properties of the actual protocol.) The functional property is “designate a resolver”. The security properties are about limiting attacks in relevant threat models. Equivalence should take into account properties we need the system to have. Self-operated and affiliated is not necessary for the system, so preventing it may not be helpful. What we’re trying to accomplish is, “here’s a pointer.”

Ben Schwartz: Proving equivalence is fine motivating text, but probably shouldn’t be an actual requirement given it’s so challenging to prove. Maybe the requirement is “designated resolvers SHOULD be equivalent”? And equivalence should consider observable and non-observable properties.

Eric Orth: We’re in the policy area. We need multiple definitions for different concepts. Network-designated resolver, resolver-designated resolver, equivalent resolver, same-party resolver. Given them, and mechanisms to discover them, let clients implement their own policy.

Lars-Johan Liman:Decision about equilvance sits with client – not server. Perhaps “alternate” is a better term? Clients can decide if alternate resolvers are acceptable or not. We should focus on providing information to clients so it can make decisions about alternative resolvers. It’s not up to the resolver, RA, DHCP, etc. to declare equivalence. The picture may shift depending on who determines equivalence.

Kirsty P: Equivalence should consider circumstances or use cases like split DNS or “sketchy” resolvers. e.g. if I have splitDNS in my enterprise, I don’t want my internal private network leaked to a resolver I don’t expect. I don’t want my world view or DNS results changed based on an ‘upgrade’. We should separate the technical mechanism for A to recommend B, and conditions for when A should recommend B

Wes Hardaker: Ability to define equivalence is useful, but we need to give clients a way to verify certain properties.

Glenn Deen: Put in context: this proposal may have gained some legs without understanding the original context. The -01 version is a narrowed set of use cases where people wanted to work on it initially; this is not a necessary requirement for all upgrades but for that particular use case. Piece of information conveyed through discovery. This might fit into other use cases on the way.

Martin Thomson: Liked Ben’s proposal. Enable delegation from the network. That delegation has properties that are no worse than authentication properties one gets from talking to the Do53 server. And we would recommend that in addition to providing encrypted transport the resolver SHOULD do other useful things with respect to data.

Harald Alvestrand: Equivalence is misleading. It should be removed, and replaced with recomendations. (BCP-style?)

Puneet Sood: Using newer terms may make discussion easier to follow.

Eric Orth: (privacy/operator equivalence may help adoption by clients)

Andrew Campling: r.e. “entity operating the resolver doesn’t matter,” the entity operating the resolver does matter. If the entity changes, the user may need to be consulted.

Martin Thomson: We might care about who operates the resolver, but we’re explicitly talking here about no expressed preference beyond what the network instructs you to do.

Lars-Johan Liman: What we’re talking here is not equivlance, but rather what is (or is not) “acceptable” to the client.

EKR: Agree with Martin. DoH/DoT-aside, the network can steer you to any Do53 resolver with DHCP. Having generically stricter requirements about what kind of entity you can be steered to doesn’t make sense. DEER has good material about not making the situation worse. Requirements should say that we can include metadata for client selection. Technical requirement is basically “tell me where the thing is,” and that’s what DEER does.

Ben Schwartz: Heard couple of comments about non-delegation rule. Circumstances where DNS traffic not be steered to a different entity. Non-delegation is not an option, since clients can’t enforce it. DNS forwarder is indistinguishable from an iterative resolver.

Vittorio Bertola: At most we can make recommendations in this area. (we should focus on the mechanism to communicate a recommendation to the client)

Tommy Jensen: Some clients connect to servers to get DNS and have no opinions. There are other cases where the client has some a priori information (IP address) and wants to confirm that it’s talking to the “right” entity. Maybe split resolver-identified into resolver-identified-generic, and resolver-identified-specific? Separate use cases.

Andrew Campling: We should not try and second guess the user. For some users DHCP may be sufficient, so trying to do anything more (assuming that’s equivalent to user’s making no choice preference) seems wrong. We should go with equivalent with whatever the current settings are.

Lars-Johan Liman: We should primarily care about suggesting equivalent/alternative resolvers. Determining equivalence is then the task of the client as a secondary, followup task.

Ralf Weber: [note to chairs: capture notes starting around Time +1:05m into recording]

Ted Hardie: Probing will be error-prone (e.g. split-DNS property is hard to probe).

Daniel Migault: Going back to EKR’s comments. It’s important to understand the entity providing the list vs. the the entity operating the resolver.

Lars-Johan Liman: Do not see how resolver can declare equivalence. Who I trust as a client is a policy decision. Mechanisms to point clients to resolvers are simple and fine. We should focus on this mechanism, so we can give clients all they need to make an informed decision (according to policy).

Ted Hardie: designation or hint. semantic of what that “pro-tip” means must be pretty clear. some protocol mechanism is what the hint is.

EKR: We have a requirements document, and we have DEER. Suggest putting this on the shelf and whether or not we should adopt DEER.

Lars-Johan Liman: Mechanisms should include intended meaning of information, as that’s important for client decisions.

Puneet Sood: Agree with Ekr. Fundamental question is how much do we trust this information?

Tirumaleswar Reddy.K:

Tommy Pauly: A lot of bike shedding and word smithing, but little disagreement on the mechanism. It makes sense to unblock adoption of mechanisms, and keep them up to date with defintiions we happen to nail down during continued discussions. Also posit that it’s more productive for people to make textual proposals for terminology as PRs or email so we can review them at large.

Andrew Campling: Same entities and answers does matter in some cases. No problem with progressing other stuff.

Time Permitting: IP Addresses in Certificates
EKR: IP address certificates are available. LetsEncrypt does not currently do it.

Martin Thomson: IP address certificates are widely supported in clients (all browsers, curls, etc).

Tiru: Confirmed that LE does not provide IP address certificates as of now.

Jonathan Reed: It may be easy to get an IP address cert if you control the server and IP space, but not true for servers providing recursive or authoritative DNS as a service. Or any sort of appliation or service provider (?)

Tommy Pauly: Not all stacks support hard-coded (by IP address) resolvers.

Martin Thomson: IP SANs do make sense for 1918 addresses (with additional steps of course).

Ben Schwartz: Reading of DEER is that it assumes the IP address is sent over a secure channel.

Martin Thomson: DEER does have that posture, but it may not be the right posture.

Planning & Wrap up
10 min - Wrap up + Future Planning
Glenn: We're considering an Interim meeting for late January ahead of IETF110 in March. We'll be sending more informatino to the ADD list about it.

• end of session -Session 2: Friday, November 20, 2020
  Session link, minutes, jabber
  Meetecho remote
  participation
  Minutes
  Meeting chat
  IETF 109 ADD Session Times
  ADD has 2 sessions during IETF109: Session 1 is Monday November 16; Session 2
  is Friday November 19

Session 2: Friday, November 20, 2020 (UTC+7)
Time in different zones:

ICT: 12:00-14:00 (UTC+7) IETF Agenda TZ and Bangkok meeting “location” time
IST: 10:30-12:30 (UTC+5.5)
CET: 06:00-08:00 (UTC+1)
UTC: 05:00-07:00 (UTC+0)
EST: 00:00-02:00 (UTC-5) Note: This is Midnight Thursday into Friday in EST
PST: 21:00-23:00 (UTC-8) Note: This is Thursday November 19 in PST
Session 2 Agenda
Welcome
NOTE WELL
Scribe selection Chris Wood/Tim Wicinski
Agenda bashing
Drafts
(Agenda bashing)

Martin: What do we expect to gain from IP address cert discussion?
Glenn: There’ve been some issues about them (would it work? is it practical?) – the goal is sort out these issues.

Discussions
Continue to Discuss Concept of Equivalent Resolvers found in
Draft-pauly-add-deer-00
and draft-box-add-requirements-01

Eric Orth:

if things are working well, keep working well (including latency, cache characteristics, and other relevant UX properties).
Privacy perspective - user trust or privacy preferences should not change or deviate from what they selected. Identical results are not sufficient if the resolver is not trusted like the user’s choice.
EKR: Agree w/Eric, two properties - results and connecting to them and not third party. A resolver that answers identically but also does other suspicious things (publish queries on Twitter) is not equivalent. Hard to describe response similarity when performance characteristics change, but perhaps easier to describe in terms of resolver authenticity. Last sentence in the definition should be struck entirely.

Ben Schwartz: Asking resolver to be equivilant, and what the client can do to identify and verify equivilant resolver. There are some
observable properties that we want client to verify. Clients verify A has operation al control over B and B is the item in control by A

EKR: Suppose an ISP that operates a Do53 resolver is too lazy to run DoH and instead just wants to forward queries to 1.1.1.1. Is this an equivalent resolver?

Glenn: Goal 1 is to get upgrade equivalent to current behavior. Goal 2 is discovery of what’s available (possible?) and what information to convey back to the client to make an informed choice.

Ralf Webber: We initially said an equivalent reoslver is done by the same entity, but some people said that’s insufficient. Shouldn’t this simple definition work for most cases (but not the lazy ISP example)?

Ben: along EKR’s line, abusing term equivilant. “designated encrypted
resolver” is pehraps a more accurate (and achievable) definition.

Joey Salazar: Equivilancy thru same entity and equilivancy through same resolution answers, plus their verification. We should focus on the simpler scenario of same entity and its verification, then move towards the other user-cases including equivalent resolution and designated resolvers, along with their implications on service expectations and user consent and such.

Martin Thomson: EKR’s example highligted - need to throw equivWhat is relevant and what is not is somewhat irrelevant without differences in privacy policies. Expectation about privacy posture end with what the network gives you.

Andrew Campling: Moving away from equivalent to designated may change privacy properties and user expectations (and may have implications on things like GDPR). “Equivalence” is important for same-provider-auto-upgrade. Equivalence matters for some contexts, but not all, and that has to include “the same parties, and the same results.” Equivalence may require some sort of user permission first.

Daniel Migault: From the begining of this session, I tend to understand that the authorized or equivalent designated resolver is being managed by the same entity as the one managing the initial Do53 resolver. From the last session is seems that some raised the issue that is too restrictive and I am wondering what use cases they have in mind where an enquivalent resolver would not be managed by the same entity as the initial Do53. It also seems that we are restricting the discovery to a “single” encrypted resolver and I believe that we should consider a list of authorized resolvers instead. As a result, the discovery mechanism should enable the discovery of a list of resolvers. I see the discovery mechanism as a mean to derive the list of authorized/equivaent resolvers from an IP address - the one of an initial Do53 resolver for example, but the list should also be discovered from the other encrypted resolvers.

Ted Hardie: Equivalence means access to the same pool of names and same behavior with query data, or plainly about what data these resolvers can access. This is different from privacy properties, and should perhaps be an orthogonal statement, as statements about privacy posture (posting to Twitter or not) is much harder to verify. TL;DR: perhaps we need two statements: one on data access, and one about privacy policy

EKR: What are we trying to solve here? (Scope properties of the actual protocol.) The functional property is “designate a resolver”. The security properties are about limiting attacks in relevant threat models. Equivalence should take into account properties we need the system to have. Self-operated and affiliated is not necessary for the system, so preventing it may not be helpful. What we’re trying to accomplish is, “here’s a pointer.”

Ben Schwartz: Proving equivalence is fine motivating text, but probably shouldn’t be an actual requirement given it’s so challenging to prove. Maybe the requirement is “designated resolvers SHOULD be equivalent”? And equivalence should consider observable and non-observable properties.

Eric Orth: We’re in the policy area. We need multiple definitions for different concepts. Network-designated resolver, resolver-designated resolver, equivalent resolver, same-party resolver. Given them, and mechanisms to discover them, let clients implement their own policy.

Lars-Johan Liman:Decision about equilvance sits with client – not server. Perhaps “alternate” is a better term? Clients can decide if alternate resolvers are acceptable or not. We should focus on providing information to clients so it can make decisions about alternative resolvers. It’s not up to the resolver, RA, DHCP, etc. to declare equivalence. The picture may shift depending on who determines equivalence.

Kirsty P: Equivalence should consider circumstances or use cases like split DNS or “sketchy” resolvers. e.g. if I have splitDNS in my enterprise, I don’t want my internal private network leaked to a resolver I don’t expect. I don’t want my world view or DNS results changed based on an ‘upgrade’. We should separate the technical mechanism for A to recommend B, and conditions for when A should recommend B

Wes Hardaker: Ability to define equivalence is useful, but we need to give clients a way to verify certain properties.

Glenn Deen: Put in context: this proposal may have gained some legs without understanding the original context. The -01 version is a narrowed set of use cases where people wanted to work on it initially; this is not a necessary requirement for all upgrades but for that particular use case. Piece of information conveyed through discovery. This might fit into other use cases on the way.

Martin Thomson: Liked Ben’s proposal. Enable delegation from the network. That delegation has properties that are no worse than authentication properties one gets from talking to the Do53 server. And we would recommend that in addition to providing encrypted transport the resolver SHOULD do other useful things with respect to data.

Harald Alvestrand: Equivalence is misleading. It should be removed, and replaced with recomendations. (BCP-style?)

Puneet Sood: Using newer terms may make discussion easier to follow.

Eric Orth: (privacy/operator equivalence may help adoption by clients)

Andrew Campling: r.e. “entity operating the resolver doesn’t matter,” the entity operating the resolver does matter. If the entity changes, the user may need to be consulted.

Martin Thomson: We might care about who operates the resolver, but we’re explicitly talking here about no expressed preference beyond what the network instructs you to do.

Lars-Johan Liman: What we’re talking here is not equivlance, but rather what is (or is not) “acceptable” to the client.

EKR: Agree with Martin. DoH/DoT-aside, the network can steer you to any Do53 resolver with DHCP. Having generically stricter requirements about what kind of entity you can be steered to doesn’t make sense. DEER has good material about not making the situation worse. Requirements should say that we can include metadata for client selection. Technical requirement is basically “tell me where the thing is,” and that’s what DEER does.

Ben Schwartz: Heard couple of comments about non-delegation rule. Circumstances where DNS traffic not be steered to a different entity. Non-delegation is not an option, since clients can’t enforce it. DNS forwarder is indistinguishable from an iterative resolver.

Vittorio Bertola: At most we can make recommendations in this area. (we should focus on the mechanism to communicate a recommendation to the client)

Tommy Jensen: Some clients connect to servers to get DNS and have no opinions. There are other cases where the client has some a priori information (IP address) and wants to confirm that it’s talking to the “right” entity. Maybe split resolver-identified into resolver-identified-generic, and resolver-identified-specific? Separate use cases.

Andrew Campling: We should not try and second guess the user. For some users DHCP may be sufficient, so trying to do anything more (assuming that’s equivalent to user’s making no choice preference) seems wrong. We should go with equivalent with whatever the current settings are.

Lars-Johan Liman: We should primarily care about suggesting equivalent/alternative resolvers. Determining equivalence is then the task of the client as a secondary, followup task.

Ralf Weber: [note to chairs: capture notes starting around Time +1:05m into recording]

Ted Hardie: Probing will be error-prone (e.g. split-DNS property is hard to probe).

Daniel Migault: Going back to EKR’s comments. It’s important to understand the entity providing the list vs. the the entity operating the resolver.

Lars-Johan Liman: Do not see how resolver can declare equivalence. Who I trust as a client is a policy decision. Mechanisms to point clients to resolvers are simple and fine. We should focus on this mechanism, so we can give clients all they need to make an informed decision (according to policy).

Ted Hardie: designation or hint. semantic of what that “pro-tip” means must be pretty clear. some protocol mechanism is what the hint is.

EKR: We have a requirements document, and we have DEER. Suggest putting this on the shelf and whether or not we should adopt DEER.

Lars-Johan Liman: Mechanisms should include intended meaning of information, as that’s important for client decisions.

Puneet Sood: Agree with Ekr. Fundamental question is how much do we trust this information?

Tirumaleswar Reddy.K:

Tommy Pauly: A lot of bike shedding and word smithing, but little disagreement on the mechanism. It makes sense to unblock adoption of mechanisms, and keep them up to date with defintiions we happen to nail down during continued discussions. Also posit that it’s more productive for people to make textual proposals for terminology as PRs or email so we can review them at large.

Andrew Campling: Same entities and answers does matter in some cases. No problem with progressing other stuff.

Time Permitting: IP Addresses in Certificates
EKR: IP address certificates are available. LetsEncrypt does not currently do it.

Martin Thomson: IP address certificates are widely supported in clients (all browsers, curls, etc).

Tiru: Confirmed that LE does not provide IP address certificates as of now.

Jonathan Reed: It may be easy to get an IP address cert if you control the server and IP space, but not true for servers providing recursive or authoritative DNS as a service. Or any sort of appliation or service provider (?)

Tommy Pauly: Not all stacks support hard-coded (by IP address) resolvers.

Martin Thomson: IP SANs do make sense for 1918 addresses (with additional steps of course).

Ben Schwartz: Reading of DEER is that it assumes the IP address is sent over a secure channel.

Martin Thomson: DEER does have that posture, but it may not be the right posture.

Planning & Wrap up
10 min - Wrap up + Future Planning
Glenn: We're considering an Interim meeting for late January ahead of IETF110 in March. We'll be sending more informatino to the ADD list about it.

• end of session -Session 2: Friday, November 20, 2020
  Session link, minutes, jabber
  Meetecho remote
  participation
  Minutes
  Meeting chat
  IETF 109 ADD Session Times
  ADD has 2 sessions during IETF109: Session 1 is Monday November 16; Session 2
  is Friday November 19

Session 2: Friday, November 20, 2020 (UTC+7)
Time in different zones:

ICT: 12:00-14:00 (UTC+7) IETF Agenda TZ and Bangkok meeting “location” time
IST: 10:30-12:30 (UTC+5.5)
CET: 06:00-08:00 (UTC+1)
UTC: 05:00-07:00 (UTC+0)
EST: 00:00-02:00 (UTC-5) Note: This is Midnight Thursday into Friday in EST
PST: 21:00-23:00 (UTC-8) Note: This is Thursday November 19 in PST
Session 2 Agenda
Welcome
NOTE WELL
Scribe selection Chris Wood/Tim Wicinski
Agenda bashing
Drafts
(Agenda bashing)

Martin: What do we expect to gain from IP address cert discussion?
Glenn: There’ve been some issues about them (would it work? is it practical?) – the goal is sort out these issues.

Discussions
Continue to Discuss Concept of Equivalent Resolvers found in
Draft-pauly-add-deer-00
and draft-box-add-requirements-01

Eric Orth:

if things are working well, keep working well (including latency, cache characteristics, and other relevant UX properties).
Privacy perspective - user trust or privacy preferences should not change or deviate from what they selected. Identical results are not sufficient if the resolver is not trusted like the user’s choice.
EKR: Agree w/Eric, two properties - results and connecting to them and not third party. A resolver that answers identically but also does other suspicious things (publish queries on Twitter) is not equivalent. Hard to describe response similarity when performance characteristics change, but perhaps easier to describe in terms of resolver authenticity. Last sentence in the definition should be struck entirely.

Ben Schwartz: Asking resolver to be equivilant, and what the client can do to identify and verify equivilant resolver. There are some
observable properties that we want client to verify. Clients verify A has operation al control over B and B is the item in control by A

EKR: Suppose an ISP that operates a Do53 resolver is too lazy to run DoH and instead just wants to forward queries to 1.1.1.1. Is this an equivalent resolver?

Glenn: Goal 1 is to get upgrade equivalent to current behavior. Goal 2 is discovery of what’s available (possible?) and what information to convey back to the client to make an informed choice.

Ralf Webber: We initially said an equivalent reoslver is done by the same entity, but some people said that’s insufficient. Shouldn’t this simple definition work for most cases (but not the lazy ISP example)?

Ben: along EKR’s line, abusing term equivilant. “designated encrypted
resolver” is pehraps a more accurate (and achievable) definition.

Joey Salazar: Equivilancy thru same entity and equilivancy through same resolution answers, plus their verification. We should focus on the simpler scenario of same entity and its verification, then move towards the other user-cases including equivalent resolution and designated resolvers, along with their implications on service expectations and user consent and such.

Martin Thomson: EKR’s example highligted - need to throw equivWhat is relevant and what is not is somewhat irrelevant without differences in privacy policies. Expectation about privacy posture end with what the network gives you.

Andrew Campling: Moving away from equivalent to designated may change privacy properties and user expectations (and may have implications on things like GDPR). “Equivalence” is important for same-provider-auto-upgrade. Equivalence matters for some contexts, but not all, and that has to include “the same parties, and the same results.” Equivalence may require some sort of user permission first.

Daniel Migault: From the begining of this session, I tend to understand that the authorized or equivalent designated resolver is being managed by the same entity as the one managing the initial Do53 resolver. From the last session is seems that some raised the issue that is too restrictive and I am wondering what use cases they have in mind where an enquivalent resolver would not be managed by the same entity as the initial Do53. It also seems that we are restricting the discovery to a “single” encrypted resolver and I believe that we should consider a list of authorized resolvers instead. As a result, the discovery mechanism should enable the discovery of a list of resolvers. I see the discovery mechanism as a mean to derive the list of authorized/equivaent resolvers from an IP address - the one of an initial Do53 resolver for example, but the list should also be discovered from the other encrypted resolvers.

Ted Hardie: Equivalence means access to the same pool of names and same behavior with query data, or plainly about what data these resolvers can access. This is different from privacy properties, and should perhaps be an orthogonal statement, as statements about privacy posture (posting to Twitter or not) is much harder to verify. TL;DR: perhaps we need two statements: one on data access, and one about privacy policy

EKR: What are we trying to solve here? (Scope properties of the actual protocol.) The functional property is “designate a resolver”. The security properties are about limiting attacks in relevant threat models. Equivalence should take into account properties we need the system to have. Self-operated and affiliated is not necessary for the system, so preventing it may not be helpful. What we’re trying to accomplish is, “here’s a pointer.”

Ben Schwartz: Proving equivalence is fine motivating text, but probably shouldn’t be an actual requirement given it’s so challenging to prove. Maybe the requirement is “designated resolvers SHOULD be equivalent”? And equivalence should consider observable and non-observable properties.

Eric Orth: We’re in the policy area. We need multiple definitions for different concepts. Network-designated resolver, resolver-designated resolver, equivalent resolver, same-party resolver. Given them, and mechanisms to discover them, let clients implement their own policy.

Lars-Johan Liman:Decision about equilvance sits with client – not server. Perhaps “alternate” is a better term? Clients can decide if alternate resolvers are acceptable or not. We should focus on providing information to clients so it can make decisions about alternative resolvers. It’s not up to the resolver, RA, DHCP, etc. to declare equivalence. The picture may shift depending on who determines equivalence.

Kirsty P: Equivalence should consider circumstances or use cases like split DNS or “sketchy” resolvers. e.g. if I have splitDNS in my enterprise, I don’t want my internal private network leaked to a resolver I don’t expect. I don’t want my world view or DNS results changed based on an ‘upgrade’. We should separate the technical mechanism for A to recommend B, and conditions for when A should recommend B

Wes Hardaker: Ability to define equivalence is useful, but we need to give clients a way to verify certain properties.

Glenn Deen: Put in context: this proposal may have gained some legs without understanding the original context. The -01 version is a narrowed set of use cases where people wanted to work on it initially; this is not a necessary requirement for all upgrades but for that particular use case. Piece of information conveyed through discovery. This might fit into other use cases on the way.

Martin Thomson: Liked Ben’s proposal. Enable delegation from the network. That delegation has properties that are no worse than authentication properties one gets from talking to the Do53 server. And we would recommend that in addition to providing encrypted transport the resolver SHOULD do other useful things with respect to data.

Harald Alvestrand: Equivalence is misleading. It should be removed, and replaced with recomendations. (BCP-style?)

Puneet Sood: Using newer terms may make discussion easier to follow.

Eric Orth: (privacy/operator equivalence may help adoption by clients)

Andrew Campling: r.e. “entity operating the resolver doesn’t matter,” the entity operating the resolver does matter. If the entity changes, the user may need to be consulted.

Martin Thomson: We might care about who operates the resolver, but we’re explicitly talking here about no expressed preference beyond what the network instructs you to do.

Lars-Johan Liman: What we’re talking here is not equivlance, but rather what is (or is not) “acceptable” to the client.

EKR: Agree with Martin. DoH/DoT-aside, the network can steer you to any Do53 resolver with DHCP. Having generically stricter requirements about what kind of entity you can be steered to doesn’t make sense. DEER has good material about not making the situation worse. Requirements should say that we can include metadata for client selection. Technical requirement is basically “tell me where the thing is,” and that’s what DEER does.

Ben Schwartz: Heard couple of comments about non-delegation rule. Circumstances where DNS traffic not be steered to a different entity. Non-delegation is not an option, since clients can’t enforce it. DNS forwarder is indistinguishable from an iterative resolver.

Vittorio Bertola: At most we can make recommendations in this area. (we should focus on the mechanism to communicate a recommendation to the client)

Tommy Jensen: Some clients connect to servers to get DNS and have no opinions. There are other cases where the client has some a priori information (IP address) and wants to confirm that it’s talking to the “right” entity. Maybe split resolver-identified into resolver-identified-generic, and resolver-identified-specific? Separate use cases.

Andrew Campling: We should not try and second guess the user. For some users DHCP may be sufficient, so trying to do anything more (assuming that’s equivalent to user’s making no choice preference) seems wrong. We should go with equivalent with whatever the current settings are.

Lars-Johan Liman: We should primarily care about suggesting equivalent/alternative resolvers. Determining equivalence is then the task of the client as a secondary, followup task.

Ralf Weber: [note to chairs: capture notes starting around Time +1:05m into recording]

Ted Hardie: Probing will be error-prone (e.g. split-DNS property is hard to probe).

Daniel Migault: Going back to EKR’s comments. It’s important to understand the entity providing the list vs. the the entity operating the resolver.

Lars-Johan Liman: Do not see how resolver can declare equivalence. Who I trust as a client is a policy decision. Mechanisms to point clients to resolvers are simple and fine. We should focus on this mechanism, so we can give clients all they need to make an informed decision (according to policy).

Ted Hardie: designation or hint. semantic of what that “pro-tip” means must be pretty clear. some protocol mechanism is what the hint is.

EKR: We have a requirements document, and we have DEER. Suggest putting this on the shelf and whether or not we should adopt DEER.

Lars-Johan Liman: Mechanisms should include intended meaning of information, as that’s important for client decisions.

Puneet Sood: Agree with Ekr. Fundamental question is how much do we trust this information?

Tirumaleswar Reddy.K:

Tommy Pauly: A lot of bike shedding and word smithing, but little disagreement on the mechanism. It makes sense to unblock adoption of mechanisms, and keep them up to date with defintiions we happen to nail down during continued discussions. Also posit that it’s more productive for people to make textual proposals for terminology as PRs or email so we can review them at large.

Andrew Campling: Same entities and answers does matter in some cases. No problem with progressing other stuff.

Time Permitting: IP Addresses in Certificates
EKR: IP address certificates are available. LetsEncrypt does not currently do it.

Martin Thomson: IP address certificates are widely supported in clients (all browsers, curls, etc).

Tiru: Confirmed that LE does not provide IP address certificates as of now.

Jonathan Reed: It may be easy to get an IP address cert if you control the server and IP space, but not true for servers providing recursive or authoritative DNS as a service. Or any sort of appliation or service provider (?)

Tommy Pauly: Not all stacks support hard-coded (by IP address) resolvers.

Martin Thomson: IP SANs do make sense for 1918 addresses (with additional steps of course).

Ben Schwartz: Reading of DEER is that it assumes the IP address is sent over a secure channel.

Martin Thomson: DEER does have that posture, but it may not be the right posture.

Planning & Wrap up
10 min - Wrap up + Future Planning
Glenn: We're considering an Interim meeting for late January ahead of IETF110 in March. We'll be sending more informatino to the ADD list about it.

END OF SESSION 2