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

[Patrick McManus <[e-mail]>]

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

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