[dns-privacy] CFP for DINR 2024 virtual workshop, Apr. 4, 2024, for early DNS research
We would like to invite you to our upcoming virtual workshop on "DNS and Internet Naming Research Directions - 2024" (DINR-2024). We will be holding this workshop virtually over Zoom on Thursday 2024-04-04 from 14:00 to 20:00 UTC (that's 07:00-13:00 PDT on the US west coast). This year, we have a particular focus on privacy and security of the DNS both now and in the future. For example, how has DNS-over-TLS and HTTPS or QUIC changed privacy for their users? Or operations for providers? However, we continue to welcome all DNS-related topics on infrastructure, tools, and any early DNS and general name space related work as well as any important updates about previous work. If you have work in these areas to share, or you want to hear about what the community is doing, we'd love to have you join us for DINR-2024. Like previous years, we're planning for a very interactive day of short talks followed by longer discussions. We are soliciting short abstracts (suggested 1 page text + 1 page references) from people who are interested presenting at the workshop. Abstracts are due soon on 2024-03-04, but as a reminder they need not be lengthy. 1-page maximum contributions are preferred. Co-chairs are John Heidemann and Wes Hardaker (both at USC/ISI), with Allison Mankin (Salesforce) and Moritz Müller (SIDN Labs) on the Technical Program Committee. If you wish to attend but not present, please submit a paragraph stating you wish to attend only and provide a brief background about your involvement with the DNS and identification. For details about DINR2024, see https://ant.isi.edu/events/dinr2024/ . (For information about DINR in prior years, see https://ant.isi.edu/events/ .) Please let us know if you're interested, or register your abstract at https://ant.isi.edu/dinr2024sub . -John and Wes on behalf of the DINR2024 TPC -- Wes Hardaker USC/ISI ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Intended Status for draft-ietf-dprive-unilateral-probing
then return it (and potentially keep processing if needed as well if not done itself)". 6. I'd think for DOT multiple simultaneous sessions may be desired up to some (small) maximum in order to prevent head-of-line blocking that DOQ solves, eg. I'd have to think more of this, but maybe just the notion that unordered responses must be sufficient is ok. 7. I'm not sure the early-data discussion is needed. It seems overly specified and dives too much into the transport layer (how TLS/QUIC are specified). APIs may not even be available in some stacks to even expose that level of request to the underlying library (really: I have no idea and haven't written TLS 1.3 code). And does early DNS data need to be a full packet size? 8. 5.6.7: could just do throttling or reopen the session immediately? That's what I wrote in my notes, but I'd need to go back to re-think through it before having a discussion about what I wrote. Essentially, I'm not sure the timing for re-opening sessions is fully baked. But it's a first-pass read only. 9. 4.6.2: I think there is a downgrade attack viable here, no? If a response over Do53 comes more quickly than a response over DOT/etc... Another full read may squash some of the above, and clearly the authors should feel free to disregard any of my statements and questions if they think I'm wrong. [1]: https://b.root-servers.org/news/2023/02/28/tls.html [2]: https://ant.isi.edu/events/dinr2023/S/s43.pdf -- Wes Hardaker USC/ISI ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] reminder: dinr2023 submissions due soon
For those doing DNS research and wish to attend our DINR2023 virtual workshop, a reminder that submissions are due this week. We would like to invite you to our upcoming virtual workshop on "DNS and Internet Naming Research Directions - 2023" (DINR-2023). We will be holding this workshop virtually over Zoom on Wednesday 2023-02-22 from 14:00 to 20:00 UTC (that's 07:00-13:00 PDT on the US west coast). This year, we have a particular focus on making naming data usable: labeling data, use of machine learning over labeled, data, and how anonymization interacts with analysis. However, we continue to welcome all DNS-related topics on infrastructure, tools, and any early DNS and general name space related work. If you have work in these areas to share, or you want to hear about what the community is doing, we'd love to have you join us for DINR-2023. Like previous years, we're planning for a very interactive day of short talks followed by longer discussions. We are soliciting short abstracts (suggested 1 page text + 1 page references) from people who are interested presenting at the workshop. Abstracts are due soon after the start of the new year (2023-01-18), but as a reminder they need not be lengthy. Co-chairs are John Heidemann and Wes Hardaker (both at USC/ISI), with Goeff Huston (APNIC) and Giovane Moura (SIDN Labs) on the Technical Program Committee. For details about DINR2023, see https://ant.isi.edu/events/dinr2023/ . (For information about prior versions DINR2021 and DINR2020, see https://ant.isi.edu/events/ .) In addition, we will have a short tutorial about the DIINER experimental produced datasets and our DNS testbed on 2022-02-23. For details about the tutorial, see https://ant.isi.edu/events/dinr2023#tutorial Please let us know if you're interested, or register your abstract at https://ant.isi.edu/dinr2023sub . -- Wes Hardaker USC/ISI ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] CFP for DINR 2023 virtual workshop, Feb. 22 2023, for early DNS research
We would like to invite you to our upcoming virtual workshop on "DNS and Internet Naming Research Directions - 2023" (DINR-2023). We will be holding this workshop virtually over Zoom on Wednesday 2023-02-22 from 14:00 to 20:00 UTC (that's 07:00-13:00 PDT on the US west coast). This year, we have a particular focus on making naming data usable: labeling data, use of machine learning over labeled, data, and how anonymization interacts with analysis. However, we continue to welcome all DNS-related topics on infrastructure, tools, and any early DNS and general name space related work. If you have work in these areas to share, or you want to hear about what the community is doing, we'd love to have you join us for DINR-2023. Like previous years, we're planning for a very interactive day of short talks followed by longer discussions. We are soliciting short abstracts (suggested 1 page text + 1 page references) from people who are interested presenting at the workshop. Abstracts are due soon after the start of the new year (2023-01-18), but as a reminder they need not be lengthy. Co-chairs are John Heidemann and Wes Hardaker (both at USC/ISI), with Goeff Huston (APNIC) and Giovane Moura (SIDN Labs) on the Technical Program Committee. For details about DINR2023, see https://ant.isi.edu/events/dinr2023/ . (For information about prior versions DINR2021 and DINR2020, see https://ant.isi.edu/events/ .) In addition, we will have a short tutorial about the DIINER experimental produced datasets and our DNS testbed on 2022-02-23. For details about the tutorial, see https://ant.isi.edu/events/dinr2023#tutorial Please let us know if you're interested, or register your abstract at https://ant.isi.edu/dinr2023sub . -John and Wes -- Wes Hardaker USC/ISI ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] [Wes Hardaker] CFP for DINR 2021 workshop-Nov. 16 for early DNS research
We failed to send out a reminder, unfortunately, so we're extending the submission date to this Friday (29 Oct 2021 11:59:59pm PDT). As a reminder: they're expected to be short abstracts about things you wish to discuss or research you're working on -- IE, it shouldn't be a huge effort to submit something. Start of forwarded message From: Wes Hardaker To: dpr...@ietf.org Cc: John Heidemann Subject: CFP for DINR 2021 workshop-Nov. 16 for early DNS research Date: Mon, 04 Oct 2021 14:08:38 -0700 Greetings, dprive. Last year we held a virtual research conference called "DINR". I've asked the dprive chairs if it would be ok to post the CFP for this years workshop here, as I think many of you might be interested. So without further ado: - We would like to invite you to our upcoming virtual workshop on "DNS and Internet Naming Research Directions" (DINR). We will be holding this workshop virtually over Zoom on 2021-11-16 from 14:00 to 20:00 UTC (that's 07:00-13:00 PDT on the US west coast). If you're intereseted in DNS-related topics, infrastructure, have early early DNS or naming work to share, or you want to hear about other people's work in those areas, we'd love to have you join us. The principle focus of the workshop will be on DNS and Internet naming, particularly on open problems, preliminary work, and tools that help both. We're planning for a very interactive day of discussion and short talks. We are soliciting short (1 page text + 1 page references) abstracts from people who are interested presenting. Abstracts are due soon (October 26), but they're short. Co-chairs are John Heidemann and Wes Hardaker (both at USC/ISI). For details about DINR2021, see https://ant.isi.edu/events/dinr2021/ . It builds on last year's DINR2020, see https://ant.isi.edu/events/dinr2020/ what we learned. In addition, we will have a short tutorial about the DIINER experimental DNS testbed and datasets on Nov. 18. For details about the tutorial, see https://ant.isi.edu/events/dinr2021#tutorial Please let us know if you're interested, or register your abstract at https://ant.isi.edu/dinr2021sub . -John and Wes -- Wes Hardaker USC/ISI End of forwarded message ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] CFP for DINR 2021 workshop-Nov. 16 for early DNS research
Greetings, dprive. Last year we held a virtual research conference called "DINR". I've asked the dprive chairs if it would be ok to post the CFP for this years workshop here, as I think many of you might be interested. So without further ado: - We would like to invite you to our upcoming virtual workshop on "DNS and Internet Naming Research Directions" (DINR). We will be holding this workshop virtually over Zoom on 2021-11-16 from 14:00 to 20:00 UTC (that's 07:00-13:00 PDT on the US west coast). If you're intereseted in DNS-related topics, infrastructure, have early early DNS or naming work to share, or you want to hear about other people's work in those areas, we'd love to have you join us. The principle focus of the workshop will be on DNS and Internet naming, particularly on open problems, preliminary work, and tools that help both. We're planning for a very interactive day of discussion and short talks. We are soliciting short (1 page text + 1 page references) abstracts from people who are interested presenting. Abstracts are due soon (October 26), but they're short. Co-chairs are John Heidemann and Wes Hardaker (both at USC/ISI). For details about DINR2021, see https://ant.isi.edu/events/dinr2021/ . It builds on last year's DINR2020, see https://ant.isi.edu/events/dinr2020/ what we learned. In addition, we will have a short tutorial about the DIINER experimental DNS testbed and datasets on Nov. 18. For details about the tutorial, see https://ant.isi.edu/events/dinr2021#tutorial Please let us know if you're interested, or register your abstract at https://ant.isi.edu/dinr2021sub . -John and Wes -- Wes Hardaker USC/ISI ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Root Server Operators Statement on DNS Encryption
Brian Haberman writes: > That would be a first step. Does anyone have an idea of how widely used > 8806 is today? As a (single-ish) data point: localroot.isi.edu has > 100 registered people, with ~90 registered servers and slowly growing (with upward spikes after presentations at various venues by various people). I need to collect better stats for "recently active" too (I have them, but I don't trust them at the moment). -- Wes Hardaker My Pictures: http://capturedonearth.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] WG Call for Adoption: draft-pauly-dprive-oblivious-doh
"Martin Thomson" writes: TL;DR: don't adopt > I would question the value of publishing the experimental > approximately-but-not-quite-O-HTTP version then. Unless we fail > majestically in chartering and executing there, we're not talking > about significant delays. It seems silly to me to write up a document that is decoupled from the parallel O-HTTP work when it would be better off depending on the results of that work. Otherwise we'll have potentially two different protocols that are subtly different enough to increase code complexity in stacks trying to offer support for both. I'm not sure where that intersection will exist (browsers?), but I doubt it's zero implementations. IMHO, ODoH is a useful goal and protocol but should be a small document describing the additions needed beyond the eventual O-HTTP. If the current proposal does get adopted, I'd argue for experimental being a much better track. I strongly doubt, without evidence, that this will be the final solution to this newly targeted problem. -- (as proof that I'm not opposed to the technology proposed in general: https://datatracker.ietf.org/doc/draft-hardaker-dnse-split-key-dns/ from 2014) -- Wes Hardaker USC/ISI ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
Warren Kumari writes: > I've tried contacting my ISPs over the years, and the responses have been: > 1: "OK, click Start, then Shutdown... Now press the power key and and we'll > wait for it > to boot" > 2: "What? Um. Have you tried turning it off and on again?" > 3: "What? Huh. Nope, never heard of that." > 4: "You are a dynamic customer. We cannot do anything like that for dynamic > customers... > Sorry, no we don't do static IPs for residential. Oh! You have a static > subnet routed to > you?! Weird, I didn't know we did that... " > 5: "Yes, we have plans to support IPv6 in the future" [no idea what that > has to do > with anything ] > 6: "We don't allow users to run servers, and so there is no need for you to > have reserve > DNS". my situation: 7: "Hey Wes, how's things? Yeah, I know we supported everything for you in the past because you're smart, we're smart and we're small enough to pretty much help everyone. But to get you the speed you wanted, we had to outsource your connection and address space to and they won't let us do reverse DNS for you even though you're static. Sorry." -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://blog.capturedonearth.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Use of separate caches for plain and secure transports
Daniel Kahn Gillmor writes: > I hope Wes will answer this question on his own Basically, one of the reasons the DNS protocol has been so robust is because of the caching behavior. It greatly reduces traffic, greatly speeds up lookups. Turning off caching would disable much of this critical infrastructure that the DNS was designed with. Recent work has proven that longer TTLs enable zones to survive DDoS attacks because of caching (https://www.isi.edu/~johnh/PAPERS/Moura18a.pdf). Instead, we could maybe cache the delay instead and do something like "if privacy mode is enabled for first query missing the cache for name X, then store [X, delay] for the resolution time. For all future requests up until the first non-privacy protected query for X, force a delay response but respond from the cache". That's kinda messy, but at least may balance the need to keep the cache with privacy. > , but i wanted to note that privacy is not only harmed by caches. it > can also be helped by caches. Yep. I did some experiments around this at the beginning of 2018 for the NDSS DNS privacy workshop. Paper: http://www.isi.edu/~hardaker/papers/2018-02-ndss-analyzing-root-privacy.pdf Youtube 1: https://youtu.be/bSKBRMNQ7s0 Youtube 2: https://youtu.be/9YYH8JFH_bY?t=21m0s -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://blog.capturedonearth.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
"Reed, Jon" writes: > On the call, someone (Wes?) proposed an alternative such as records in > the reverse zones. Yes, I think this solves a number of issues and creates new ones. IE, the list of pros and cons for all solutions includes no item with zero "cons" unfortunately. 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 - the number of reverse zone records to update on a key change is 1 per ip address. The number of name server NS records to update per key change is 1 per zone supported, which is very very large for some servers [1]. - it feels cleaner cons: - not everyone controls their reverse zone easily, especially for those that don't hold at least a /24 allocation. Ironically, I fall into this camp but still think this is a better solution than a name-based one. - requires more lookups - requires the reverse tree for that address be fully signed And probably more pros and cons I'm not thinking of at the moment. [1]: the latest huge DANE support jump at https://stats.dnssec-tools.org/ is due to a large number of zones suddenly enabling DANE/SMTP on one.com. That shows the scale of some of the larger zone holders. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://blog.capturedonearth.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Use of separate caches for plain and secure transports
Daniel Kahn Gillmor writes: > I have *not* done any analysis of the larger, less-corner-y cases to > see whether there's a strong argument for or against treating data > that came in under confidential cover differently once it's in the > cache. Technically, it's near impossible to completely protect privacy unless you don't use a cache. Imagine the case where someone goes to a coffee shop first thing every morning that supports a TLS based resolver. A second "customer" 5 minutes later can then perform queries to the resolver (regardless of TLS or not) for a slew of names to find which were "in cache" and responding quickly. You now know that person #1 went to sites A, X and Y since they returned in < 5ms, but not the rest of the alphabet which returned in > 5ms. However, I don't think this changes the nature of whether or not the caches should be separate. If anything, it may argue for a shared cache so that normal traffic from non-privacy protected lookups will mean someone snooping caches for private-protected lookups won't know it came from a TLS-based user. [And, no, we shouldn't go down the road of "privacy requires you disable the cache"] -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://blog.capturedonearth.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
Paul Hoffman writes: > >> During the development of the DoH standard, people from many DNS > >> vendors (including the one you work for) contributed to the spec > >> without objection in the WG. [snip other comments] One issue with the IETF specifications is that we allow for, and should allow for, publication of specifications that enable interoperability. What we fail to do (well) is provide guidance on when a specification is applicable to a problem space, and when it should and when it SHOULD NOT be used. Sometimes on "Operational Considerations" section helps out in this regard, but frequently not fully in part because people/companies/etc find new and unique ways of using new protocols in ways people hadn't thought of. But I digress from the real problem... So the question is: Yes, if it's possible to do DNS over HTTP should everyone use it? This is where the discussion seems to be concentrating, and is what we should be discussing. However, I argue that this has nothing to do with whether or not it should have been published as an RFC. Personally speaking, I don't think it's the right solution for "most uses". Much of the time I may trust my local, small ISP more than the large corporations that are offering some of the global DoH or even generic DNS resolution services. And as I switch places, my trust may change (my local, interdependent coffee shop is a "maybe" but a large chain, "probably not"). I really need a "which do you trust more? A or B?" choice when making network switches (with saving of preference). But, a few wise large entities are making the decisions for us instead. A we large companies are standing up expensive infrastructure and advertising them using easy addresses saying 'use us, use us'. Other organizations are hard(ish)-coding what you should use in their software, often pointing toward these large DoH resolver beds. So now we are trending toward a lot of software sending all DNS queries to a single or a small set of companies implementing global infrastructure. Now, no where above am I saying "this is bad" or "that is bad". I'm not sure which is preferred. Which is better: a light weight protocol with local caching that is potentially manipulated or sniffed by local on-path-attackers (which could be someone you have no choice but to use), or a more complex set of multiple layering protocols that point toward a small number of service providers? The answer is likely different per person, per organization, etc. What I want where I live is likely very different than what I might want behind a border with significant DNS rewriting. So, DoH is hardly "bad" itself. It's the wrong decision for me in some locations at some times. But the standardization of an interoperable specification in an RFC doesn't ramp up use (as Paul has been saying). The use was ramping up because a few smart companies realized they could follow Google's model of standing up a public resolver that everyone would want to use, then negotiating the use of those resolvers with some software companies to get it deployed. I don't object to DoH. I think it's a critically important protocol for protecting the privacy and usability of DNS is certain situations. That doesn't mean I want to use it everywhere, even though that's what we're trending toward. [that was a bit rambly; sorry] -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://blog.capturedonearth.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Call for abstracts for DINR 2016---DNS and Internet Naming Research
Warren Kumari <war...@kumari.net> writes: > Forwarded on behalf of John Heidemann - he asked the chairs if this > posting would be appropriate for the list, I figured it was fine. > Also, they already know that, unfortunately, it conflicts with the > IETF in Seoul. Because it conflicts with the Seoul IETF, which I'll also be at, I've decided to hold a less formal bar BOF on the subject. If you're interested in the topic of internet naming, where research is needed and would like to participate in a conversation about it, please let me know. -- Wes Hardaker USC/ISI ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Authenticating the resolver
Paul Hoffman paul.hoff...@vpnc.org writes: On Aug 27, 2014, at 12:46 PM, Wes Hardaker wjh...@hardakers.net wrote: But what's the solution? How do we authenticate that resolver? PKIX won't help us, as there is no name. Say what? That draft clearly says that the resolver can have a PKIX certificate with its IP address as the name. So we're going to issue a gazillion PKIX certs for 10.0.0.1? The likelihood that you have the coffee shop's DHCP server's credentials are zero. I think I was implying that so we agree :-) You also forgot other options, such as preshared signing key. That would work fine for enterprises or ISPs with a help desk and a few thousand users. Paste this into that dialog on your computer works OK. But PKIX with IP addresses is probably more scalable. Well, I thought about the coffee shop sign (here's our WPA password along with our resolver's magic verification string). -- Wes Hardaker Parsons ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt
Carsten Strotmann c...@strotmann.de writes: Ok then I am an attacker, since you cannot authenticate me, I sign the data myself. This has data integrity. But it is the modified data and not what you expected to receive... How can you sign DNSSEC data without being in the posession of the private signing key(s) all the way to the root? DNSSEC adds data integrity, and with one or more trust-anchors in the resolver the client is able to validate the data, no matter which way the data took. So, there is some confusion here I think so we need to be clear about a few things. We're talking about privacy, and in this context stub-to-resolver entirely. There are two forms of integrity/authentication going on and they need to be clearly separated but I keep seeing them being thrown together. DNSSEC absolutely helps you ensure that the end data you got is good from the notion of the publisher. But it doesn't help you to identify the public key of the resolver you're using to query for those results. So it doesn't help you ensure you're encrypting your packets to the right destination. And DNSSEC may ensure you have the right data, but it doesn't help you determine if you really did get it in a way that no one else but you, the coffee shop owner, and the final destination could see. And this is the important bit: in the context of the discussion, we are only talking about verifying the public key of the resolver in order to implement privacy; Clearly DNSSEC has solved authenticating the data itself and that's not in question. I think most people understand this difference (I hope). But here's the thing that is keeping me awake at nights in this topic: we keep saying that un-authenticated encryption is better than no encryption. And I do generally think this is true. At least you're only transmitting your data to one potentially bad person (the one you've done a key negotiation with) rather than letting anyone with 100 feet view the data. But then, stepping back, you have to ask yourself: what's the likely threat model of everyone in 100 feet trying to attack you? If we really are worried about protecting people at starbucks, what's the likelyhood of 2 people in starbucks trying to sniff your private dns lookups at the same time? Probably super-duper low. So, are we really protecting you at all if the one bad person in the coffee shop is able to convince you it's the local resolver? IE, if we blindly assume that whatever key we get is ok then we're buying ourselves very minimal protection against the few opponents within spitting distance of a wireless box. Likely there will be just one, and it'll likely succeed in defeating your encryption. Now, in larger venues where are there are potentially lots and lots of people that are targeting an environment for sniffing, say at an IETF convention where we're very good at overwhelming infrastructure, then the likelyhood of having multiple malicious eves goes way up and maybe we've achieved a bit of protection by transmitting our dns request data to just one advocacy instead of them all. But what's the solution? How do we authenticate that resolver? PKIX won't help us, as there is no name. DNSSEC won't help us, as half the time you're behind a nat so the reverse tree can't be used [ipv6 actually might help here]. Leap of faith is probably better than nothing if you frequent that coffee shop. I don't think secure dhcp has gotten that far, but I'm admittedly out of touch. We simply keep moving this chicken/egg problem of secure bootstrapping from one protocol to the next. It's like one egg that keeps changing chickens. -- Wes Hardaker Parsons ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
