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 protected]> 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. > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
