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

[Sara Dickinson <[e-mail]>]

> On 18 Oct 2019, at 23:50, Patrick McManus <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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 <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.

OK - I’ll remove it.

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

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?

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

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

Sara.

> 
> Sara. 
>