Subject: [Add] The ADD WG has placed draft-pauly-add-deer in state "Call For Adoption By WG Issued"

From: IETF Secretariat <[email-masked]>
Date: Thu, 14 Jan 2021 17:35:36 -0800

The ADD WG has placed draft-pauly-add-deer in state
Call For Adoption By WG Issued (entered by Glenn Deen)

The document is available at
https://datatracker.ietf.org/doc/draft-pauly-add-deer/

Comment:
Call open until January 26th

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Jan 2021 15:13:03 +0000

Hiya,

> Call For Adoption By WG Issued (entered by Glenn Deen)

The mechanism defined here (using SVCB) is fine so I'm not
against adoption but ISTM the draft is currently based on
some false premises, the first of which is IMO likely to
lead to extended and mostly-pointless debate:

- The equivalence called for here won't apply in many cases,
neither in terms of some (impossible?) functional definition
for equivalence, nor in terms of involving the "same entity."
I think this all looks like an RFC6919 "MUST (but we know
you won't)" and I don't see how we benefit from adding that
to an already controversial and complicated area. I'd say
better to not insist on any particular semantics except
that using SVCB like this ought always result in an as-good
or better TLS setup, so (were it up to me, which it's not)
I'd re-title this as something like "Discovering Encrypted
Related Resolvers" and re-word a good bit accordingly.

- 4.1 will call for a SAN containing an IP address that
cannot be authenticated by a CA in many cases (the address
of the unencrypted resolver) - I don't see the utility of
that TBH. (This is separate from use of private addresses.)

- 4.2's insistence on the same IP address seems odd to me.
I suspect there's an underlying difference in interpretation
of the term opportunistic there, which isn't uncommon - IMO
even very "weak" opportunistic modes are useful if they can
lead deployments towards use of a fully authenticated mode
but the text here seems to instead consider opportunistic
mode as an undesirable end-state and not as an intermediate
state. I doubt we'll all agree on that based on this draft
though, as this has been an ongoing disagreement for a
bunch of years already:-)

In case the above isn't clear: again, I'm not against
adoption but would argue we'd all be better of if the
above were fixed first.

One other change that (if needed) would be fine to fix
after adoption is that I'm unsure that all of the clients
we'd like to do this will be able to handle, and keep up
with, the full complexity of SVCB. Could be the best way
to handle that is to wait and see what people implement
and then profile down to requiring use of SVCB records
that are supported by all known implementations. OTOH,
if it turns out everyone uses some well-tested and capable
SVCB library, then this'd likely be moot. I'm not aware
there is any such library at the moment though.

Cheers,
S.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 20 Jan 2021 10:29:31 -0500

I share many of Stephen's concerns.  I've proposed some changes to the
draft that I think would address many of them:
https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/pull/147/files

I think the draft represents a good starting point, but I expect it to be
significantly revised by the working group.

On Wed, Jan 20, 2021 at 10:13 AM Stephen Farrell <[email-masked]>
wrote:

> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 20 Jan 2021 08:32:41 -0800

> On Jan 20, 2021, at 7:13 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

The name and terminology is based on the discussion going on in the ADD working group previously; I think I’m speaking for all the authors when I say that that terminology can certainly and should change, and would be certainly eligible to refine even after adoption.

> that TBH. (This is separate from use of private addresses.)

Again, this is a point we can continue to discuss or change. I think it is useful given that some resolvers can and indeed do support such certificates already, but that can be decided by the WG.

> adoption but would argue we'd all be better of if the

While that’s certainly a direction, I’d prefer to see such decisions be made as a matter of working group consensus and agreement, and not under individual authorship.

Thanks,
Tommy

> <OpenPGP_0x5AB2FAF17B172BEA.asc>-- 
> Add mailing list
> [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Jan 2021 16:57:28 +0000

Hi Tommy,

On 20/01/2021 16:32, Tommy Pauly wrote:
>>> The ADD WG has placed draft-pauly-add-deer in state Call For
>>> Adoption By WG Issued (entered by Glenn Deen)
>> 
>> The mechanism defined here (using SVCB) is fine so I'm not against
>> adoption but ISTM the draft is currently based on some false
>> premises, the first of which is IMO likely to lead to extended and
>> mostly-pointless debate:
>> 
>> neither in terms of some (impossible?) functional definition for
>> equivalence, nor in terms of involving the "same entity." I think
>> this all looks like an RFC6919 "MUST (but we know you won't)" and I
>> don't see how we benefit from adding that to an already
>> controversial and complicated area. I'd say better to not insist on
>> any particular semantics except that using SVCB like this ought
>> always result in an as-good or better TLS setup, so (were it up to
>> me, which it's not) I'd re-title this as something like
>> "Discovering Encrypted Related Resolvers" and re-word a good bit
>> accordingly.
> 
> The name and terminology is based on the discussion going on in the
> ADD working group previously;

 From my POV, I don't think this is really a matter of
terminology - it's more about whether or not we're ok with
producing another RFC6919 case-study:-)

> I think I’m speaking for all the
> authors when I say that that terminology can certainly and should
> change, and would be certainly eligible to refine even after
> adoption.

ISTM, if the authors aren't actually that stuck on requiring
a well-defined equivalence, then it'd be a good bit easier to
just fix that before adoption, as I suspect it may be hard
to reach consensus in the WG if we start from text that
assumes such a definition is possible or useful. (I think
the same is true wrt the other two points so won't repeat
myself:-)

I do agree that the WG will be able to fix all this, but just
think it'd be easier for the WG if the text surrounding the
use of SVCB were changed before adoption. It's fine if the
chairs figure I'm in the rough there, as looks possible from
the other mail in this thread. (OTOH, many of the supportive
mails are bare assertions of support, free of any comment on
the text, so I find it hard to tell myself.)

Cheers,
S.

>> - 4.1 will call for a SAN containing an IP address that cannot be
>> authenticated by a CA in many cases (the address of the unencrypted
>> resolver) - I don't see the utility of that TBH. (This is separate
>> from use of private addresses.)
> 
> Again, this is a point we can continue to discuss or change. I think
> it is useful given that some resolvers can and indeed do support such
> certificates already, but that can be decided by the WG.
> 
>> 
>> - 4.2's insistence on the same IP address seems odd to me. I
>> suspect there's an underlying difference in interpretation of the
>> term opportunistic there, which isn't uncommon - IMO even very
>> "weak" opportunistic modes are useful if they can lead deployments
>> towards use of a fully authenticated mode but the text here seems
>> to instead consider opportunistic mode as an undesirable end-state
>> and not as an intermediate state. I doubt we'll all agree on that
>> based on this draft though, as this has been an ongoing
>> disagreement for a bunch of years already:-)
>> 
>> In case the above isn't clear: again, I'm not against adoption but
>> would argue we'd all be better of if the above were fixed first.
> 
> While that’s certainly a direction, I’d prefer to see such decisions
> be made as a matter of working group consensus and agreement, and not
> under individual authorship.
> 
> Thanks, Tommy
> 
>> 
>> One other change that (if needed) would be fine to fix after
>> adoption is that I'm unsure that all of the clients we'd like to do
>> this will be able to handle, and keep up with, the full complexity
>> of SVCB. Could be the best way to handle that is to wait and see
>> what people implement and then profile down to requiring use of
>> SVCB records that are supported by all known implementations.
>> OTOH, if it turns out everyone uses some well-tested and capable 
>> SVCB library, then this'd likely be moot. I'm not aware there is
>> any such library at the moment though.
>> 
>> Cheers, S.
>> 
>> 
>> <OpenPGP_0x5AB2FAF17B172BEA.asc>-- Add mailing list [email-masked]

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 20 Jan 2021 17:10:09 +0000

Additional context for use of IP addresses: this comes down to which CA is used. Google, Cloudflare, Quad9, and OpenDNS domains all do issue certs with IP addresses today. The main challenge is ACME CAs such as Let's Encrypt don't support IP address ownership confirmation. However, RFC8738 is a relatively recent development that does allow that. I'd say there is a path forward here even if many DoH resolvers depend on CA feature adoption first.

Thanks,
Tommy

-----Original Message-----
From: Add <[email-masked]> On Behalf Of Stephen Farrell
Sent: Wednesday, January 20, 2021 8:57 AM
To: Tommy Pauly <tpauly=[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [Add] The ADD WG has placed draft-pauly-add-deer in state "Call For Adoption By WG Issued"

Hi Tommy,

On 20/01/2021 16:32, Tommy Pauly wrote:
>> - The equivalence called for here won't apply in many cases, neither 
>> in terms of some (impossible?) functional definition for equivalence, 
>> nor in terms of involving the "same entity." I think this all looks 
>> like an RFC6919 "MUST (but we know you won't)" and I don't see how we 
>> benefit from adding that to an already controversial and complicated 
>> area. I'd say better to not insist on any particular semantics except 
>> that using SVCB like this ought always result in an as-good or better 
>> TLS setup, so (were it up to me, which it's not) I'd re-title this as 
>> something like "Discovering Encrypted Related Resolvers" and re-word 
>> a good bit accordingly.
> 

 From my POV, I don't think this is really a matter of terminology - it's more about whether or not we're ok with producing another RFC6919 case-study:-)

> I think I'm speaking for all the
> change, and would be certainly eligible to refine even after adoption.

ISTM, if the authors aren't actually that stuck on requiring a well-defined equivalence, then it'd be a good bit easier to just fix that before adoption, as I suspect it may be hard to reach consensus in the WG if we start from text that assumes such a definition is possible or useful. (I think the same is true wrt the other two points so won't repeat
myself:-)

I do agree that the WG will be able to fix all this, but just think it'd be easier for the WG if the text surrounding the use of SVCB were changed before adoption. It's fine if the chairs figure I'm in the rough there, as looks possible from the other mail in this thread. (OTOH, many of the supportive mails are bare assertions of support, free of any comment on the text, so I find it hard to tell myself.)

Cheers,
S.

>> - 4.2's insistence on the same IP address seems odd to me. I suspect 
>> there's an underlying difference in interpretation of the term 
>> opportunistic there, which isn't uncommon - IMO even very "weak" 
>> opportunistic modes are useful if they can lead deployments towards 
>> use of a fully authenticated mode but the text here seems to instead 
>> consider opportunistic mode as an undesirable end-state and not as an 
>> intermediate state. I doubt we'll all agree on that based on this 
>> draft though, as this has been an ongoing disagreement for a bunch of 
>> years already:-)
>> 
> While that's certainly a direction, I'd prefer to see such decisions 
>> One other change that (if needed) would be fine to fix after adoption 
>> is that I'm unsure that all of the clients we'd like to do this will 
>> be able to handle, and keep up with, the full complexity of SVCB. 
>> Could be the best way to handle that is to wait and see what people 
>> implement and then profile down to requiring use of SVCB records that 
>> are supported by all known implementations.
>> OTOH, if it turns out everyone uses some well-tested and capable SVCB 
>> library, then this'd likely be moot. I'm not aware there is any such 
>> library at the moment though.
>> 
>> Cheers, S.
>> 
>> 
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=04%7C01%7CJensen.Thomas
>> %40microsoft.com%7C656d456c2d0c4e32442308d8bd64a232%7C72f988bf86f141a
>> f91ab2d7cd011db47%7C1%7C0%7C637467587228785767%7CUnknown%7CTWFpbGZsb3
>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>> 7C1000&amp;sdata=N%2BwSiUouvR0VrjyKgQONLux2uF%2Bn3oQWDc8M8zwsc5A%3D&a
>> mp;reserved=0
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Jan 2021 17:26:06 +0000

Hiya,

On 20/01/2021 17:10, Tommy Jensen wrote:
> Additional context for use of IP addresses: this comes down to which
> CA is used. Google, Cloudflare, Quad9, and OpenDNS domains all do
> issue certs with IP addresses today. The main challenge is ACME CAs
> such as Let's Encrypt don't support IP address ownership
> confirmation. However, RFC8738 is a relatively recent development
> that does allow that. I'd say there is a path forward here even if
> many DoH resolvers depend on CA feature adoption first.

That's fair. But paraphrasing your description, the status
quo in PKI and the current draft text could end up favouring
centralisation of the kind that some WG participants (me
included) find problematic. That specific text would of
course be much less of an issue if it were agreed that
the final output from the WG needs to also work well for
recursive operators without any affiliation with more
"global" services such as those you mention.

I'm not sure if it'd be worth stating something like
that in the draft, but ISTM a real requirement here and
one that doesn't appear to sit that well with the current
draft text. (That said, I've just read the thing fairly
quickly, so it could be I'm worrying to much about this;-)

Cheers,
S.

> 
> Thanks, Tommy
> 
> -----Original Message----- From: Add <[email-masked]> On Behalf
> Of Stephen Farrell Sent: Wednesday, January 20, 2021 8:57 AM To:
> Tommy Pauly <tpauly=[email-masked]> Cc: [email-masked] 
> Subject: [EXTERNAL] Re: [Add] The ADD WG has placed
> draft-pauly-add-deer in state "Call For Adoption By WG Issued"
> 
> 
> Hi Tommy,
> 
>>> against adoption but ISTM the draft is currently based on some
>>> false premises, the first of which is IMO likely to lead to
>>> extended and mostly-pointless debate:
>>> 
>>> this all looks like an RFC6919 "MUST (but we know you won't)" and
>>> I don't see how we benefit from adding that to an already
>>> controversial and complicated area. I'd say better to not insist
>>> on any particular semantics except that using SVCB like this
>>> ought always result in an as-good or better TLS setup, so (were
>>> it up to me, which it's not) I'd re-title this as something like
>> The name and terminology is based on the discussion going on in
>> the ADD working group previously;
> 
> From my POV, I don't think this is really a matter of terminology -
> it's more about whether or not we're ok with producing another
> RFC6919 case-study:-)
> 
>> I think I'm speaking for all the authors when I say that that
>> terminology can certainly and should change, and would be certainly
>> eligible to refine even after adoption.
> 
> ISTM, if the authors aren't actually that stuck on requiring a
> well-defined equivalence, then it'd be a good bit easier to just fix
> that before adoption, as I suspect it may be hard to reach consensus
> in the WG if we start from text that assumes such a definition is
> possible or useful. (I think the same is true wrt the other two
> points so won't repeat myself:-)
> 
> I do agree that the WG will be able to fix all this, but just think
> it'd be easier for the WG if the text surrounding the use of SVCB
> were changed before adoption. It's fine if the chairs figure I'm in
> the rough there, as looks possible from the other mail in this
> thread. (OTOH, many of the supportive mails are bare assertions of
> support, free of any comment on the text, so I find it hard to tell
> myself.)
> 
> Cheers, S.
> 
>>> - 4.1 will call for a SAN containing an IP address that cannot
>>> be authenticated by a CA in many cases (the address of the
>>> unencrypted resolver) - I don't see the utility of that TBH.
>>> (This is separate from use of private addresses.)
>> 
>> Again, this is a point we can continue to discuss or change. I
>> think it is useful given that some resolvers can and indeed do
>> support such certificates already, but that can be decided by the
>> WG.
>> 
>>> 
>>> "weak" opportunistic modes are useful if they can lead
>>> deployments towards use of a fully authenticated mode but the
>>> text here seems to instead consider opportunistic mode as an
>>> undesirable end-state and not as an intermediate state. I doubt
>>> we'll all agree on that based on this draft though, as this has
>>> been an ongoing disagreement for a bunch of years already:-)
>>> 
>>> In case the above isn't clear: again, I'm not against adoption
>>> but would argue we'd all be better of if the above were fixed
>>> first.
>> 
>> While that's certainly a direction, I'd prefer to see such
>> decisions be made as a matter of working group consensus and
>> agreement, and not under individual authorship.
>> 
>> Thanks, Tommy
>> 
>>> 
>>> adoption is that I'm unsure that all of the clients we'd like to
>>> do this will be able to handle, and keep up with, the full
>>> complexity of SVCB. Could be the best way to handle that is to
>>> wait and see what people implement and then profile down to
>>> requiring use of SVCB records that are supported by all known
>>> implementations. OTOH, if it turns out everyone uses some
>>> well-tested and capable SVCB library, then this'd likely be moot.
>>> I'm not aware there is any such library at the moment though.
>>> 
>>> Cheers, S.
>>> 
>>>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Jan 2021 09:47:56 -0800

> "global" services such as those you mention.

I'm not following. While LE doesn't presently issue IP address certificates,
as Tommy says, it's quite possible for non-"global" operators to get them.

Surely the standard here isn't "LE supports it"

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Jan 2021 18:03:01 +0000

Hiya,

> as Tommy says, it's quite possible for non-"global" operators to get them.

That wasn't how I interpreted what Tommy said - my reading
was that today one needed to be associated with some global
entity to get such a cert that'd be widely verifiable. (I
haven't tried myself though to get such a cert though so
maybe it's less restrictive than I think.)

> Surely the standard here isn't "LE supports it"

Of course. But "a wide range of deployed ACME clients and
servers support it" seems like a fine requirement.

S.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Jan 2021 10:20:51 -0800

> maybe it's less restrictive than I think.)

As far as I can tell, there are a number of CAs which currently support
this, such as Comodo.

> servers support it" seems like a fine requirement.

I don't agree with this. We published plenty of RFCs that depend on PKI
before ACME even existed. I agree that ACME support is good, but I don't
think it's a reasonable requirement.

-Ekr

---

From: Eric Orth <[email-masked]>
Date: Wed, 20 Jan 2021 13:39:27 -0500

I want to explicitly state that I support adopting this draft now and
discussing these points in greater detail after adoption.  My perception is
that the WG is overwhelmingly supportive of the general ideas of this draft.

On Wed, Jan 20, 2021 at 1:22 PM Eric Rescorla <[email-masked]> wrote:

>
>
> On Wed, Jan 20, 2021 at 10:03 AM Stephen Farrell <
> [email-masked]> wrote:
>
>>
>> Hiya,
>>

---

From: Andrew Campling <[email-masked]>
Date: Wed, 20 Jan 2021 18:50:01 +0000

On Wed, Jan 20, 2021 at 18:39 Eric Orth <[email-masked]<mailto:[email-masked]>> wrote:

> I want to explicitly state that I support adopting this draft now and discussing these points in greater detail after adoption.  My perception is that the WG is overwhelmingly supportive of the general ideas of this draft.

+1, noting that the general principle of not wanting to aid centralisation seems like a good aim (I don’t recall that being included in RFC 8890, it should be).  I’d also like to see the working group adopt draft-box-add-requirements.

Andrew

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 20 Jan 2021 14:15:26 -0500

On Wed, Jan 20, 2021 at 1:50 PM Andrew Campling
<[email-masked]> wrote:

> On Wed, Jan 20, 2021 at 18:39 Eric Orth <[email-masked]> wrote:
>
>
>
> +1, noting that the general principle of not wanting to aid centralisation
> seems like a good aim (I don’t recall that being included in RFC 8890, it
> should be).  I’d also like to see the working group adopt
> draft-box-add-requirements.
>

Agreeing with Andrew and Eric.  Stephen's note made me go back and reread
the draft.
I'm not as concerned as Stephen is, because the WG can work out these
details once its adopted.

tim

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 21 Jan 2021 18:52:08 +0000

> The name and terminology is based on the discussion going on in the ADD
> working group previously; I think I’m speaking for all the authors when I say
> that that terminology can certainly and should change, and would be
> certainly eligible to refine even after adoption.
> 
> >
> Again, this is a point we can continue to discuss or change. I think it is useful
> given that some resolvers can and indeed do support such certificates
> already, but that can be decided by the WG.

FWIW, I did read the current draft and have followed the extensive discussion around it. I recognized the call for adoption was being done on the -00 individual draft, that the authors almost certainly have a lot of changes they're expecting to make (or have been making) as a result of the discussion, and I'm comfortable with waiting until after adoption to see this updated version and starting more discussion. I didn't provide comments with my support for adoption (1) because I'd prefer to first see these updates before starting a new round of discussion and (2) because I trust this set of authors to faithfully work with the WG consistent with my expectations of how IETF should work. I believe the described approach, at a high level (creating the new DNS records, etc.), is a good approach that the WG should proceed to refine. It's well-enough defined that I feel like I understand where it's headed. I'm not a fan of what I've seen in some other WGs, where people try to withhold adoption until the draft is ready for WGLC (because of lack of trust).
Barbara

---

From: Daniel Migault <[email-masked]>
Date: Mon, 25 Jan 2021 12:54:25 -0500

I believe the draft represents a good starting point, and will also
probably help to steer a path through the other use cases. I would also
like - if possible - the WG to find/design other ways than the use of a
special fqdn.

I am happy to contribute/review once adopted.

Yours,
Daniel

On Thu, Jan 21, 2021 at 1:52 PM STARK, BARBARA H <[email-masked]> wrote:

> FWIW, I did read the current draft and have followed the extensive
> discussion around it. I recognized the call for adoption was being done on
> the -00 individual draft, that the authors almost certainly have a lot of
> changes they're expecting to make (or have been making) as a result of the
> discussion, and I'm comfortable with waiting until after adoption to see
> this updated version and starting more discussion. I didn't provide
> comments with my support for adoption (1) because I'd prefer to first see
> these updates before starting a new round of discussion and (2) because I
> trust this set of authors to faithfully work with the WG consistent with my
> expectations of how IETF should work. I believe the described approach, at
> a high level (creating the new DNS records, etc.), is a good approach that
> the WG should proceed to refine. It's well-enough defined that I feel like
> I understand where it's headed. I'm not a fan of what I've seen in some
> other WGs, where people try to withhold adoption until the draft is ready
> for WGLC (because of lack of trust).
> Barbara
> --
> Add mailing list
> [email-masked]

-- 
Daniel Migault
Ericsson