Re: [dns-privacy] how can we ADoT?

Peter van Dijk wrote: > > What I think I mean to say there is 'if an auth NS responds on port 853, > it had better offer me all the data it also has to offer on 53'. Yes, I think that makes the most sense. > > * Authenticate the server by `subjectAltName` `iPAddress`. [snip] > > For DOTPIN,

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

Peter van Dijk wrote: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/ > > As I understand the draft, the revalidation can happen in parallel to > the actual query the user is waiting for. Any setup/discovery of secure > transports would have to happen before that, so I'm

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

Brian Dickson wrote: > On Tue, Nov 17, 2020 at 3:30 PM Tony Finch wrote: > > > > Even so I think delegations should be signed. > > So, the parental NS records are not authoritative, and thus not supposed to > be signed. Yes, that was the logic, but it was a mistake :-)

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

Paul Wouters wrote: > On Tue, 17 Nov 2020, Tony Finch wrote: > > > Any serious attempt at improving delegations needs to deal convincingly > > with the quesion of why support for CDS, CDNSKEY, and CSYNC is so > > appallingly bad. > > Because IETF does not enforce su

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

Peter van Dijk wrote: > On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote: > > > Using NS names in a separate zone or zones (for each DNS operator) is > > scalable, and facilitates DNSSEC signing, at little to no incremental > > cost and little to no operational complexity > > The

Re: [dns-privacy] Amortization techniques for less popular name server names

Brian Dickson wrote: > Attempting to do XFR for many name servers which are infrequently used > would have scalability issues from any resolver, if the server names are > in a large number of zones. One approach to reducing this issue is > aggregating server names inside many fewer zones. Doing

Re: [dns-privacy] how can we ADoT?

Thanks for reading and providing feedback! Peter van Dijk wrote: > On Wed, 2020-11-11 at 19:07 +0000, Tony Finch wrote: > > > > * Encryption would apply to the server as a whole, whereas the > > working group consensus is that it should be possible for > >

Re: [dns-privacy] how can we ADoT? (with github url)

Manu Bretelle wrote: > The "cloud provider" case, e.g few name servers for many zones is also > tricky. I prefer to think of this as the normal common case, since I'm not a cloud provider and I have many more zones than servers :-) > I think in those cases, TLSA may be the best bet as this is

Re: [dns-privacy] how can we ADoT? (with github url)

Manu Bretelle wrote: > > Totally fair, pretty sure there were no speaker notes ;) . The > presentation is available at https://youtu.be/MIapQ6UXrdg?t=5387 . > Originally, there was this draft > https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-01 > and the solutions

Re: [dns-privacy] how can we ADoT?

Eric Rescorla wrote: > On Wed, Nov 11, 2020 at 11:07 AM Tony Finch wrote: > > > 2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the > > resolver starts by connecting in the clear, and upgrades to an > > encrypted connection if the autho

Re: [dns-privacy] how can we ADoT?

Hollenbeck, Scott wrote: > > It's not an EPP limitation. We can always define an EPP extension to add > information to the parent zone. The issue is if the zone administrator > can/will publish that information in the zone and if EPP clients are able and > willing to provide it. True! I am using

[dns-privacy] how can we ADoT?

I haven't seen anything written down that explains why it is difficult to do DoT to authoritative servers. There was a good discussion earlier this year about draft-vandijk-dprive-ds-dot-signal-and-pin which covered some of the issues. I have done a braindump that attempts to cover all the angles

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

Brian Dickson wrote: > > I think a better comparison (better meaning more relevance and closer > tracking of the transition and operation) would be the transition of SMTP > to SMTP using TLS without downgrade susceptibility. Yes. That was made a lot more difficult because it went through an

Re: [dns-privacy] Revised opportunistic encryption draft

Paul Wouters wrote: > > I still believe the cost of authenticating a DNS(SEC) server is so low > these days (with ACME available at no cost and with full automation) > that this draft is better not done. +1 Tony. -- f.anthony.n.finchhttp://dotat.at/ South Utsire: Northwesterly 4 to 6,

[dns-privacy] the rec/auth dot problem, was Re: Call for adoption: draft-vandijk-dprive-ds-dot-signal-and-pin

Peter van Dijk wrote: > > (and I agree with Paul Hoffman and others that we have plenty of > proposals, fully worked out or not, but not a lot of agreement on what > the actual shape is of the problem we are solving.) At what level of detail is it not clear? The problem I see is that none of the

Re: [dns-privacy] Possible use case: Opportunistic encryption for recursive to authoritative

Paul Wouters wrote: > > At the IETF, we have done a REALLY bad job at keeping secure DNS as an > optional feature. The more we treat it that way, the more others will > treat it that way. We should really do the opposite. DNS without DNSSEC > is legacy. It's irresponsible. It's vulnerable. It's

Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt

Sara Dickinson wrote: > > On 13 Jul 2020, at 23:35, Tony Finch wrote: > > > > 7 authentication > > Belated responses on this topic! And a few more thoughts from me, pruned for length ... > Well the goal was to compare and contrast the set of existing control &

Re: [dns-privacy] Registry framework for draft-ietf-dprive-early-data

Ilari Liusvaara wrote: > > Then there is RRSIG, which seems bit alarming. While direct queries > should not do anything special, I noticed two troublesome properties: > > 1) The answers can be pretty large (amplification hazard with UDP). > 2) The queries can be really slow compared to other

Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt

Sara Dickinson wrote: > > Hi Tony, > > Many thanks for the detailed review! You're welcome! Your changes sound good, so I'll just answer a few quesions... > > Is there a reason for allowing concurrent AXFRs of the same zone? > > Actually, thinking about this more generally, I can't see a way in

Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt

I've had a read through and here are a few, er, I mean several things that caught my eye: In the intro, I think it's too strong to say that RFC 5155 was "to prevent" zone enumeration - its abstract says it "provides measures against" which is a more accurate guide to NSEC3's effectiveness. Also

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

Peter van Dijk wrote: > On Thu, 2020-05-28 at 00:43 +0100, Tony Finch wrote: > > > > This made me wonder if this pseudorecord should be a KEY instead, and then > > I wondered how hard it would be to persuade existing code to generate a DS > > from a KEY. > &g

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

Peter van Dijk wrote: > On Tue, 2020-05-26 at 09:10 +0200, Ondřej Surý wrote: > > > > 1. Bit 7 of the Flags fields needs to be 0. > > Definitely [...] I noted earlier that whatever flags we might need, it's > definitely *not* ZONE and SEP. > > > 2. This needs a new Protocol number > > I

Re: [dns-privacy] Datatracker State Update Notice:

Jim Reid wrote: > Could the people on this thread *please* trim their postings? Yes, more RFC 1855, please! Tony. -- .-_|\f.anthony.n.finch / \ McQuary ->*.--._/http://dotat.at/ v ___

Re: [dns-privacy] Fwd: New Version Notification for draft-huitema-dprive-dnsoquic-00.txt

Christian Huitema wrote: > We just resubmitted the DNS over QUIC draft to DPRIVE. Thanks in advance > for the feedback! Looks promising! I have a few comments: Is the ALPN "dq" or "doq"? 4.1 and 4.1.1 appear to disagree. 8.1 seems to disagree with itself. Section 4.3 (idle timeouts): it's

Re: [dns-privacy] [Ext] Threat Model

John Levine wrote: > In article you write: > >> That's per-zone, though, whereas DoT support is per-server. > > > >Maybe that's ideal, but one would expect that a zone only rolls this > >out once all their nameservers support it. > > Most of my zones have a secondary run by somebody else, whose

Re: [dns-privacy] [Ext] Threat Model

Paul Wouters wrote: > > The right way to do this is a DNSKEY flag, which is protected by the > signed DS at the parent. Similar to draft-powerbind for the > delegation-only domain. That's per-zone, though, whereas DoT support is per-server. DS records that somehow encode NS target names in

Re: [dns-privacy] ADoT requirements for authentication?

Some miscellaneous thoughts vaguely related to the discussion ... ## nameserver hostnames in certificates It's not uncommon for zones to use in-bailiwick aliases for their nameservers, which avoids transitive configuration dependencies and speeds up resolution because the resolver gets glue with

Re: [dns-privacy] New Version Notification for draft-zatda-dprive-xfr-using-dso-00.txt

Tom Pusateri wrote: > > In 7.1.1.1, there is mention of efficiently packing stream data into > TCP segments. This is also in the PUSH draft but I think it should be > removed from there and from here as well because once the data is > encoded in a TLS session, it’s much more difficult for the

Re: [dns-privacy] Some additional signalling ideas

Ilari Liusvaara wrote: > > Adding another RRtype with needed magic properties would take Standards > Action (as expert review requires RRtype not to be magic) and then > updating parent nameservers to be able to deal with the RRtype (since > it can not be generically handled). Don't forget the

Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt

> >> This proposal actually reminds me a lot of idea I had that actually > >> used DS records instead of new record type. > >> > >> AFAIK: > >> - DNSsec ignores any such record (unknown algorithm) > >> -> No interference with DNSsec. > >> - CDS does not ignore such records. > >> -> Automated

Re: [dns-privacy] Fwd: New Version Notification for draft-hzpa-dprive-xfr-over-tls-01.txt

Sara Dickinson wrote: > > A new draft has been submitted outlining using DNS-over-TLS for zone > transfers. I've had a brief skim. It's entirely driven by zone confidentiality, which is a fine thing, but from my point of view the interesting possibility is to get transport integrity (like

Re: [dns-privacy] Alternative signalling propsals

Wes Hardaker wrote: > > My list for putting a TLSA or similar record at the reverse zone > include: > > pros: > - the authoritative server more likely in control of its reverse zone than all > the forward zones its serving Reverse zones plural (v4 + v6) :-) > - the number of reverse zone

Re: [dns-privacy] Issues with encoding keys in nameserver DNS names

Daniel Kahn Gillmor wrote: > On Fri 2018-12-14 19:12:41 +0100, A. Schulze wrote: > > > > 5. Encoding a key as DNS name of a nameserver makes key rotation harder. > >Not impossible, but really much harder. > > i agree that it makes it harder, but i'm not convinced that it is *much* > harder.

Re: [dns-privacy] Implementer Perspective

Brian Haberman wrote: > This week (10/15 - 10/21) let's focus on the implementer's > perspective on DNS privacy between recursive resolvers and authoritative > servers. Olafur's RIPE talk discusses this to some degree, advocating the advantages of better transport protocol engineering ...

Re: [dns-privacy] Authoritative Server Operator Perspective

Apart from the basic mechanics that we have already mentioned, I think the interesting question here is how to manage scalability to lots of zones: if we publish encryption/authentication information about nameservers in the DNS: * is it published per server, associated with the server’s

Re: [dns-privacy] [Ext] Authoritative Server Operator Perspective

Paul Hoffman wrote: > > 1) An interoperable specification for how to encrypt messages > 1a) If it is layer 4, it is likely to be TLS > 1b) If it is layer 7, it is likely to be CMS > > 2) An interoperable method to tell resolvers who might want encrypted > responses how to send them. 3) An

Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective

Paul Hoffman wrote: > > If I have a path with authentication and a path without, and I prefer > (not demand) the path with authentication, I am taking advantage of it. Right, but is the authenticated path securely authenticated? i.e. can the client tell that an attacker is monkeying around with

Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective

Paul Hoffman wrote: > On Oct 2, 2018, at 3:12 AM, Tony Finch wrote: > > Paul Hoffman wrote: > >> > >> I do not have a scenario where the client (the resolver in this case) > >> needs downgrade protection for privacy. > > > > In that case ther

Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective

Paul Hoffman wrote: > > I do not have a scenario where the client (the resolver in this case) > needs downgrade protection for privacy. In that case there's no need to worry about authentication at all. (But I disagree.) More generally, I don't think the term "opportunistic" is very helpful,

Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective

Paul Hoffman wrote: > On Oct 1, 2018, at 8:50 AM, Tony Finch wrote: > > > > Paul Hoffman wrote: > >> > >> During earlier discussions of opportunistic encryption in the IETF, > >> attempted-but-not-required authentication was strongly preferred ove

Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective

Paul Hoffman wrote: > > During earlier discussions of opportunistic encryption in the IETF, > attempted-but-not-required authentication was strongly preferred over > "don't even attempt to authenticate". This is only worthwhile if there is downgrade protection, i.e. the client needs to be able

Re: [dns-privacy] User Perspective

Christian Huitema wrote: > > An attacker could replay the 0-RTT packet, and observe whether it > creates a particular side effect at the server end. For example, replay > the traffic from client to recursive, and observe whether the resolver > issues a query to particular DNS server. Ah, yes, if

Re: [dns-privacy] User Perspective

Christian Huitema wrote: > > The basic QUIC handshake will be 1-RTT before sending the first query, > with two exceptions: Thanks for those details! > Using 0-RTT is a trade-off between security and performance, because > 0-RTT packets can be subject to replay attacks. That's true for 0-RTT in

Re: [dns-privacy] User Perspective

Mukund Sivaraman wrote: > > During the "how-to-achieve-it" phase, attention should be given to not > adding extra roundtrips (to keep it as close as possible to the RFC 1035 > UDP scenario). Various new facilities such as TCP's fast open, TLS false > start, etc. should not be taken for granted -

Re: [dns-privacy] User Perspective

Amelia Andersdotter wrote: > > I have difficulties seeing how a user (within the meaning of individual > internet consumer) has any practical choice to other than to share PII > with a DNS provider? Yes, me too. Since the overall topic is recursive -> authoritative, the questions imply some

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

Martin Hoffmann wrote: > > Downgrade seems to be an issue with all proposals. The tradeoffs seem to revolve around how much you leak before you work out whether you can use strict DoT, and how much added latency that costs. If you are talking to a nameserver via its canonical name, then asking

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

Warren Kumari wrote: > > If the NS records / labels were _ta.a.iana-servers.net and _ > ta.b.iana-servers.net, that could be used as a positive signal that the > resolver (or if the underscore freaks people out, > dns-o-tls.a.iana-servers.net) is listening on 853 and that an inability > to

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

Paul Wouters wrote: > On Wed, 12 Sep 2018, Tony Finch wrote: > > > > RFC 7901 doesn't work when asking authoritative servers because they > > don't have a copy of the chain. > > You can set the start of the chain to the zone, so as long as any > chainin

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

Paul Wouters wrote: > > Then use RFC 7901 DNS chain queries (or the hopefully soon > tls-dnssec-chain TLS extension) RFC 7901 doesn't work when asking authoritative servers because they don't have a copy of the chain. tls-dnssec-chain will not help iterative resolvers because they will already

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

Erik Kline wrote: > On Wed, 12 Sep 2018 at 15:38, Shane Kerr wrote: > > > > Note that we can also use the RTT of this query to set a reasonable > > timeout for our port 853 traffic. A DNS server administrator may have > > configured port 853 support, but the network administrator may block > >

[dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

In the most general terms, when upgrading a protocol from cleartext to TLS, there are a couple of questions the client has to answer: 1. Does this server support TLS? 2. How can I authenticate it? And there are a couple of approaches to answering them: A. opportunistic B. explicit

Re: [dns-privacy] Oblivious DNS

Willem Toorop wrote: > > ODNS queries could be nested. I.e. > > {{{www.foo.bar}k.odns.google.com}k.odns.quad9.net}k.odns.cloudflare.com OnionDNS :-) Tony. -- f.anthony.n.finch http://dotat.at/ West Fitzroy: Northwesterly 7 to severe gale 9, veering

Re: [dns-privacy] Potential re-charter text

Let's retry the tests with a hot cache, since that's maybe a bit more fair. I've picked the shortest times I could get, which involved heating up the resolver until it was no longer waiting 10s or 30s on lame authoritative servers. Unbound 1.6.0 TCP 8s Unbound 1.6.0 UDP 0.4s BIND 9.11 TCP 0.5s

Re: [dns-privacy] I-D Action: draft-ietf-dprive-padding-policy-01.txt

Shane Kerr wrote: > > I'm curious what you mean by this. Do you really mean to propose an > option to pad every query and response message to 65K bytes? Reasonable values might be the MTU or the EDNS buffer size. Tony. -- f.anthony.n.finch

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

Section 3.2.2 HTTP/1 Is there a SP missing between the request-target and the HTTP-version in the diagram of the shortest possible request? Section 4.3 Opcode / 4.6 ANCOUNT NSCOUNT Do you want to support UPDATE? If not it should probably be ruled out up front, since it changes some of the

Re: [dns-privacy] DNS-over-TLS query/answer framing.

Simon Kelley wrote: > The current proposal is a huge pain, because 1035 framing only allows > one query-in-flight per TCP/TLS connection. No it doesn't. The reason DNS over TCP has query IDs like UDP is to support pipelined queries and out-of-order responses. You can

Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt

Paul Hoffman paul.hoff...@vpnc.org wrote: On May 12, 2015, at 11:40 AM, Simon Josefsson si...@josefsson.org wrote: For SMTP, IMAP, POP etc the reason for having both port-based and upgrade-based is legacy and historic reasons: back in the days the STARTTLS approach wasn't invented, so

Re: [dns-privacy] DPRIVE over UDP or TCP

Not all: see my message from Friday: http://www.ietf.org/mail-archive/web/dns-privacy/current/msg00758.html I assume other large anycast TLS providers have similar setups to Cloudflare. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at On 27 Apr 2015, at 21:17, Paul Hoffman

Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)

Tirumaleswar Reddy (tireddy) tire...@cisco.com wrote: Any specific reason for the firewalls to permit TCP/53 other than for zone transfer ? RFC 5966 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Utsire, Northeast Forties: Easterly 4 or 5, increasing 6 or 7. Slight or