Subject: [dns-privacy] wglc feedback draft-ietf-dprive-bcp-op

From: Patrick McManus <[email-masked]>
Date: Tue, 15 Oct 2019 17:59:24 -0700

Hi All,

Thanks for doing this work! (draft-ietf-dprive-bcp-op)

I have a few pretty small comments.

1] There is a reference to "run a .onion [RFC7686] service endpoint".

1a] The reference to RFC 7686 is not about a service endpoint - it is about
the name .onion and how clients encountering them use them. Its not going
to help with what this bcp suggests in terms of a service endpoint.

1b] As this is a BCP, I question whether this is really advice driven by
BCP. How often is this done, and when it is done how much traffic is driven
through it so that we really understand the implications of it? This feels
more like an idea than a BCP backed up by wide experience... and there is
reason to think it might fall down at scale if really adopted as a best
practice.

2] "Clients should not be required to use TLS session resumption [RFC5077]
with TLS 1.2" can be made a bit better.

2a] how does one require a client to use a resumption method (which is what
the text warns about) in any event? Maybe we should say the server should
not offer them if it does not want linkability?

2b] the explicit reference to session tickets with 1.2 leaves out a bunch
of equivalent mechanisms such as ID based resumption and 1.3 based PSKs
that create a similar issue. DoH used language like "some form of session
resumption mechanism, such as section 2.2 of RFC8446" to try and capture it
all. perhaps that's helpful here too.

3] "Automate the generation and publication of certificates" could be
changed to say "Automate the generation, publication, and renewal of
certificates" to explicitly capture the riskiest part. It should also, IMO,
include an explicit reference to ACME (as at least an example) as we've got
a lot of experience now that ACME is a good way to actively manage
certificates through automation.

4] I am also concerned that it is unreasonable to suggest TLSA in a BCP
document. What are the examples of existing DNS Privacy Services doing so
and what are the examples of the matching clients using it? At what scale?
Do we have comparable evidence about robust management of that vs the more
traditional TLS PKI and ACME and tools built for that? any experience of
tlsa with doh at scale before mentioning it as a BCP?

hth. thanks for the consideration.

-Patrick

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 18 Oct 2019 13:06:30 +0100

> On 16 Oct 2019, at 01:59, Patrick McManus <[email-masked]> wrote:
> 
> Hi All,
> 

Thanks for the review!

> 1a] The reference to RFC 7686 is not about a service endpoint - it is about the name ..onion and how clients encountering them use them. Its not going to help with what this bcp suggests in terms of a service endpoint.

The best reference I could find for setting up an onion endpoint is https://riseup.net/en/security/network-security/tor/onionservices-best-practices <https://riseup.net/en/security/network-security/tor/onionservices-best-practices>.  Would this work or do you have another reference to recommend?

> 
> 1b] As this is a BCP, I question whether this is really advice driven by BCP. How often is this done, and when it is done how much traffic is driven through it so that we really understand the implications of it? This feels more like an idea than a BCP backed up by wide experience... and there is reason to think it might fall down at scale if really adopted as a best practice.

I think it is true to say that the majority of the ‘mitigations’ and most of the ‘optimisations' in this document are implemented by one or more of the ‘large’ DoT/DoH providers (https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements <https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements> provides some details.) so it seems reasonable to publish as is. The plan is absolutely to do a -bis in the near future since the deployment is evolving and I hope that as ISPs and Enterprises deploy they will feedback into the -bis.

> 
> 2] "Clients should not be required to use TLS session resumption [RFC5077] with TLS 1.2" can be made a bit better. 
> 2a] how does one require a client to use a resumption method (which is what the text warns about) in any event? Maybe we should say the server should not offer them if it does not want linkability?
> 2b] the explicit reference to session tickets with 1.2 leaves out a bunch of equivalent mechanisms such as ID based resumption and 1.3 based PSKs that create a similar issue. DoH used language like "some form of session resumption mechanism, such as section 2.2 of RFC8446" to try and capture it all. perhaps that's helpful here too.

‘Servers should have no requirement that, to obtain service, clients are required to use any form of session resumption mechanism, such TLS session resumption [RFC5077] with TLS 1.2 or section 2.2 of RFC8446.”?

> 
> 3] "Automate the generation and publication of certificates" could be changed to say "Automate the generation, publication, and renewal of certificates" to explicitly capture the riskiest part. It should also, IMO, include an explicit reference to ACME (as at least an example) as we've got a lot of experience now that ACME is a good way to actively manage certificates through automation.

Good point. How about that bullet point becomes:

* Automate the generation, publication and renewal of certificates. For example, ACME [RFC8555] provides a mechanism to actively manage certificates through automation and has been implemented by a number of certificate authorities.

> 
> 4] I am also concerned that it is unreasonable to suggest TLSA in a BCP document. What are the examples of existing DNS Privacy Services doing so and what are the examples of the matching clients using it? At what scale? Do we have comparable evidence about robust management of that vs the more traditional TLS PKI and ACME and tools built for that? any experience of tlsa with doh at scale before mentioning it as a BCP?

It is currently mentioned as an optimisation - I had thought that after a previous comment on this we had downgraded it to just an ‘additional option’ which I think would be reasonable. There are a DoT few test servers that publish TLSA records: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers <https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers> (I’m not aware of any DoH servers doing this).

Would changing it to an ‘Additional option’ be acceptable or do you feel strongly that it should be removed completely?

Sara.

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 18 Oct 2019 14:34:07 +0200

On 10/16/19 2:59 AM, Patrick McManus wrote:
> 1b] As this is a BCP, I question whether this is really advice driven
> by BCP. How often is this done, and when it is done how much traffic
> is driven through it so that we really understand the implications of
> it? This feels more like an idea than a BCP backed up by wide
> experience... and there is reason to think it might fall down at scale
> if really adopted as a best practice.

I think we're in a chicken-egg situation (partially) where some kinds of
"DNS resolver operators" (e.g. ISPs) have only rarely deployed much of
this stuff, especially transport encryption, and they might like to get
inspired by at least some IETF-blessed advice, even if it won't be
perfect yet.  Example:
https://github.com/Encrypted-DNS-Deployment-Initiative/Workstreams/issues/3

> [...] the deployment is evolving and I hope that as ISPs and
> Enterprises deploy they will feedback into the -bis.
I also hope for that.  Having touched this initiative I linked above -
it seems mostly driven by ISPs who are trying to figure out operational
BCP for DNS encryption.

--Vladimir

---

From: Patrick McManus <[email-masked]>
Date: Fri, 18 Oct 2019 15:50:14 -0700

Hi Sara,

My comments about TLSA and Tor are specifically through the lens of BCP -
these mechanisms make a lot of sense in a non BCP document. But. imo, BCP
should give the reader almost a checklist of things that are known to be
widely implemented and successfully deployed(i.e best practices) and
generally at Internet scale (or at least described at the appropriate
scope). While both TLSA and Tor are pretty neat, neither are really a
current best practice as far as I know (but I ask that question in a
genuinely open minded way and would love to see the data) - what I do see
is a couple endpoints that have offerings/support for them but that's not
really the same thing. In other words, I think merely implemented in one or
more services is really too low of a bar for a BCP. The WG should have
confidence that it really works well at scale and can be recommended with
unambiguous guidance.

By way of analogy I have some favorite mechanisms in the HTTP space that
are I think are really valuable but aren't used widely. Alternative
Services is a good example. They are used in a number of places quite
successfully, but compared to the scale and scope of HTTP they don't
register. Work continues apace with them as a mechanism (including the
forthcoming QUIC specifications) which I think will make them grow in
importance over time, but right now Alt-Svc would not be a BCP - there just
isn't enough real world experience to say that.

Particularly with Tor there is reason to believe the Tor network -
necessary for the accessing of a .onion endpoint - could not handle the
same kind of traffic load with anywhere near the same kind of performance
that a pure IP based endpoint like many of the popular public resolvers
could.. and this is more of a factor of the limited capacity and inherently
inefficient routing of the overlay than it is of anything the endpoint
provisions. So is the BCP advice that a resolver should operate a .onion
endpoint but hope people don't use it except when they really need it? Or
they should only do it if they are really small? Or they should only do it
if their customers are ok with coming back tomorrow if it doesn't work
today? To be honest imo those _are_ the implict BCPs of Tor services today
but I don't think they are the best current practices of privacy aware
internet resolvers addressed by this document. I say this because in
practice the two worlds don't operate reliably and efficiently at the same
scales. Tor is a world of its own and before IETF BCPs start recommending
its operational use right along traditional IP we ought to be more certain
about the outcomes of people following that advice.

I look at the TLSA suggestions in a similar frame - though I know less
about usage of them (and have less reason to be proactively concerned). Are
those offerings being used by clients at rates approaching the web-pki
ones? Have they been robust? Have there been expiration related failures?
Basically, is it really an operational BCP? Any maybe the answer is yes -
I'm just asking because that would be new info to me if true. How confident
are we that this is really a documented best practice, instead of
advocating for a good idea? Minimally the TLSA reference should be
restricted to DoT as that's quite a leap for DoH.

On Fri, Oct 18, 2019 at 5:06 AM Sara Dickinson <[email-masked]> wrote:

>
>
> The best reference I could find for setting up an onion endpoint is
> https://riseup.net/en/security/network-security/tor/onionservices-best-practices.
> Would this work or do you have another reference to recommend?
>
>
I would prefer to drop the .onion text entirely. The fact that the Tor
protocol is not an open standard is a further complication but not at the
crux of the issue.

>
> ‘Servers should have no requirement that, to obtain service, clients are
> required to use any form of session resumption mechanism, such TLS
> session resumption [RFC5077] with TLS 1.2 or section 2.2 of RFC8446.”?
>
>
This is much better - but the "Servers should have no requirement" bit
still makes no sense to me. How could a server have such a requirement,
technically speaking? That's not how it works - there's always the
possibility that the client does not have resumption material and you need
to process the handshake that way. Its probably best to leave this up to
the client.. if the client binds resumption material to IP addresses the
risk is constant - resuming with the same address is fine (no new info),
resuming with a different address would be a good place to not resume to
avoid linkability.

>
> * Automate the generation, publication and renewal of certificates. For
> example, ACME [RFC8555] provides a mechanism to actively manage
> certificates through automation and has been implemented by a number of
> certificate authorities.
>
>
nice! thanks.

> It is currently mentioned as an optimisation - I had thought that after a
> previous comment on this we had downgraded it to just an ‘additional
> option’ which I think would be reasonable. There are a DoT few test servers
> that publish TLSA records:
> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers (I’m not
> aware of any DoH servers doing this).
>
> Would changing it to an ‘Additional option’ be acceptable or do you feel
> strongly that it should be removed completely?
>
> Sara.
>
>

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 29 Oct 2019 10:47:28 +0000

> On 18 Oct 2019, at 23:50, Patrick McManus <[email-masked]> wrote:
> 
> Hi Sara,
> 
> My comments about TLSA and Tor are specifically through the lens of BCP - these mechanisms make a lot of sense in a non BCP document. But. imo, BCP should give the reader almost a checklist of things that are known to be widely implemented and successfully deployed(i.e best practices) and generally at Internet scale (or at least described at the appropriate scope). While both TLSA and Tor are pretty neat, neither are really a current best practice as far as I know (but I ask that question in a genuinely open minded way and would love to see the data) - what I do see is a couple endpoints that have offerings/support for them but that's not really the same thing. In other words, I think merely implemented in one or more services is really too low of a bar for a BCP. The WG should have confidence that it really works well at scale and can be recommended with unambiguous guidance.
> 
> By way of analogy I have some favorite mechanisms in the HTTP space that are I think are really valuable but aren't used widely. Alternative Services is a good example. They are used in a number of places quite successfully, but compared to the scale and scope of HTTP they don't register. Work continues apace with them as a mechanism (including the forthcoming QUIC specifications) which I think will make them grow in importance over time, but right now Alt-Svc would not be a BCP - there just isn't enough real world experience to say that.
> 
> Particularly with Tor there is reason to believe the Tor network - necessary for the accessing of a .onion endpoint - could not handle the same kind of traffic load with anywhere near the same kind of performance that a pure IP based endpoint like many of the popular public resolvers could.. and this is more of a factor of the limited capacity and inherently inefficient routing of the overlay than it is of anything the endpoint provisions. So is the BCP advice that a resolver should operate a .onion endpoint but hope people don't use it except when they really need it? Or they should only do it if they are really small? Or they should only do it if their customers are ok with coming back tomorrow if it doesn't work today? To be honest imo those _are_ the implict BCPs of Tor services today but I don't think they are the best current practices of privacy aware internet resolvers addressed by this document. I say this because in practice the two worlds don't operate reliably and efficiently at the same scales. Tor is a world of its own and before IETF BCPs start recommending its operational use right along traditional IP we ought to be more certain about the outcomes of people following that advice.
> 
> I look at the TLSA suggestions in a similar frame - though I know less about usage of them (and have less reason to be proactively concerned). Are those offerings being used by clients at rates approaching the web-pki ones? Have they been robust? Have there been expiration related failures? Basically, is it really an operational BCP? Any maybe the answer is yes - I'm just asking because that would be new info to me if true. How confident are we that this is really a documented best practice, instead of advocating for a good idea? Minimally the TLSA reference should be restricted to DoT as that's quite a leap for DoH.

Thanks for the comments here, seems reasonable.

> 
> On Fri, Oct 18, 2019 at 5:06 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> I would prefer to drop the .onion text entirely. The fact that the Tor protocol is not an open standard is a further complication but not at the crux of the issue.

OK - I’ll remove it.

> This is much better - but the "Servers should have no requirement" bit still makes no sense to me. How could a server have such a requirement, technically speaking? That's not how it works - there's always the possibility that the client does not have resumption material and you need to process the handshake that way. Its probably best to leave this up to the client.. if the client binds resumption material to IP addresses the risk is constant - resuming with the same address is fine (no new info), resuming with a different address would be a good place to not resume to avoid linkability.

I think one of the concerns here was to ensure equity of service for clients that choose not to use these mechanism even if they impose a performance hit on the server. In principle a server could give lower priority to (or timeout) queries arriving on sessions that that didn’t use those mechanisms which might degrade service enough to cause an issue….. 

Would updating this to ’Servers should not degrade in any way the query service level provided to clients that do not use any form….’ work?

> Would changing it to an ‘Additional option’ be acceptable or do you feel strongly that it should be removed completely?

I’ll remove this too for this version until there is more data.

Sara.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 29 Oct 2019 10:29:00 -0600

Sara, I sincerely appreciate the consideration..

> I think one of the concerns here was to ensure equity of service for
> clients that choose not to use these mechanism even if they impose a
> performance hit on the server. In principle a server could give lower
> priority to (or timeout) queries arriving on sessions that that didn’t use
> those mechanisms which might degrade service enough to cause an issue…..
>
> Would updating this to ’Servers should not degrade in any way the query
> service level provided to clients that do not use any form….’ work?
>
>
got it. I like the new text - and now I understand the mechanism the text
is concerned about.

thanks.

-P