Re: [DNSOP] QNAME minimization can be better, or New Version Notification for draft-levine-qmin-performance-00.txt
On 14/11/2023 00:56, John R Levine wrote: Once again, I really wish people would stop blaming the victim. That's not useful language. DNSBLs fulfill a purpose but are not victims. People whose privacy is exposed via network traffic are not correctly described as victims but are nonetheless liable to suffer via, e.g. more spam or even attack following a data leak, as a result. Casting this as an us v. them discussion isn't a good plan, for any us or them really. S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-structured-dns-error: suberr registration policy
Hiya, Ben's mail prompted me to have a quick read of the draft and I fully agree when he says: On 18/04/2023 12:11, Benjamin Schwartz wrote: I think this registry opens a terrible can of worms that the IETF can and should avoid. Cheers, S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld
Hiya, This is good enough, so should proceed. In terms of substantive comments, I can only think of arguments that have already been thrashed out so won't raise any of 'em. A suggestion/nit which I'm fine to see ignored: the text in section 4 (Privacy Considerations) isn't that clear and might be helped via one or a couple of examples e.g. by adding: "For example, a value such as 'mumblemumble.alt' would be a clear privacy leak." And for bonus points, one might further add: "In addition if a name ending in .alt is sufficiently unique, long-lasting and frequently leaks into the global DNS, then regardless of how the value is constructed, that value can act like a web cookie, with all the associated downsides of (re-)identification." Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Hiya, On 21/10/2022 22:25, Paul Vixie wrote: Joe Abley wrote on 2022-10-21 13:51: On Oct 21, 2022, at 12:52, Paul Vixie wrote: it's a registry of carve-outs for use inside DNS, which happens to facilitate client development by giving agents such as browser plugins a clear activation signal that's unambiguous with respect to the DNS. ... In that context, what we are talking about is defining a carve-out from the namespace that is not for use by the DNS, but instead intended for other naming systems. +1. Also +1 FWIW I don't understand why people seem so down on the idea of enabling other people to experiment with other ways of playing with names. (I do understand the arguments being made so don't need them explained yet another time; what I don't get is the attitude behind those.) S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)
Hiya, On 23/08/2022 23:52, Martin Thomson wrote: On Wed, Aug 24, 2022, at 08:30, Stephen Farrell wrote: Currently chromium and firefox disagree on whether ECH is setup correctly for one of my test pages I'm fairly confident that that is a bug on the Firefox end. The person looking into it has been on leave, but as far as I can tell the DNS and server side is OK. Sure, that may be the entirety of things. And to be clear: I wasn't al all trying to imply there's any delay here, (e.g. I know it took me months before I asked the right person and then learned that what I was publishing as HTTPS RRs was wrong;-) but the fact that both I and someone in browser development misinterpreted stuff around ports != 443 may indicate that a bit more clarity on that topic could be useful, if there's a window open for a bit of text polishing. Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)
Hiya, On 23/08/2022 22:51, Brian Dickson wrote: The differences in interpretation, and the client behavior under one of those interpretations, are the problem. I've seen a different client-behaviour issue related to ports other than 443 and ECH, but I'm unsure if that's a problem with this spec or simply an implementation issue that'll be fixed in short order. Currently chromium and firefox disagree on whether ECH is setup correctly for one of my test pages [1]. Initially, I had misinterpreted what to publish in an HTTPS RR for [1] and neither browser liked that, but even after I fixed that, (thanks to one of the browser folk educating me), only one seems to work, and the other still thinks that ECH isn't properly setup for [1]. Surprisingly though, both work for another page [2], but I wonder if that may be because ECH is also enabled for the same name on the default port. [3] If people are going to take another look at this spec, it may be useful to also see if the text relating to ports other than 443 is sufficiently clear - I know I got what to publish wrong, and the fact that browsers haven't yet landed on the same interpretation of what's needed for ECH away from port 443, may indicate a bit more clarity would be beneficial. To be clear: I'd be fine with the RFC being issued and us figuring out any useful clarifications as experiments with ECH continue over the next while - my guess is there'll be more than just this aspect of ECH to document better. Cheers, S. PS: In case you're clicking the links below - both browsers require a recent(ish) build, use of DoH and turning on a flag before they attempt ECH so you'll only see the difference if you've all that setup on your client. PPS: Some of the relevant folk were vacating recently (me included) so it could be this just gets fixed in the very near future, but I figured if there's going to be a window when some editorial/clarity text improvements might be made it was worth raising, just in case. [1] https://draft-13.esni.defo.ie:8413/stats [2] https://my-own.net:8443/ech-check.php [3] https://my-own.net/ech-check.php OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review
Hiya, On 20/08/2022 01:55, Warren Kumari wrote: On Fri, Aug 19, 2022 at 5:46 PM, Stephen Farrell wrote: Hiya, On 19/08/2022 20:43, Warren Kumari wrote: So, it is perfectly acceptable (in my view) for it to have: Reference Name - a-cool-document foo.alt another-document foo.alt yet-another-doc bar.alt I agree that such duplicate names are acceptable in this registry. I scanned the draft quickly and think it's good. (I'll try do a closer read in a few days.) Only thing with which I'd argue for now is that I think RFC required is a much simpler rule for the registry. My concern with this is that we may end up with lots of Internet Drafts which either need to be put in some WG or be AD sponsored, and have to go through IETF LC, and IESG Eval, and use RFC Editor resources and similar. For an informational only thing that seems like a lot of overhead. I'm also not very sure that IETF participants would really want to review yet another block-chain based name resolution system every N weeks… I agree wrt IETF review. My possibly wrong assumption was that most drafts looking for names in this registry might arrive via the ISE or IRTF, with few desiring all the fun of IETF processes. I guess I'd generally be ok with there being non-trivial hoops that need to be jumped-through for this registry, but yes, I know that increases the chances of squatting-like behaviour. I also recognise that reasonable people might make different predictions about this small bit of the future. Any other option will require some designated experts with some guidance for those DEs, and I'd expect it to be hard for us to agree what guidance to include in the draft or not, and I'd expect it to be hard to find DEs for this registry. Yup, that's a valid concern - IANA's site speaketh thusly: "If you choose Expert Review or Specification Required as the registration procedure for your new registry, it can be helpful to provide guidance to the “expert.” The idea is to provide the expert with guidance on naming, allocation and other issues related to the protocol registry. Sometimes Internet-Draft authors include the guidance directly in the draft. Other times, a Working Group will decide to collect guidance for a group of protocols together (for instance, see the PWE3 working group in RFC 4446)." — https://www.iana.org/help/protocol-registration I'd think that the guidance to the experts would be: 1: Is there a specification somewhere? RFC8126 (Spec Required) says that a specification should be a "document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value." Right. It's the "long after" and stability (for some random project) and sufficient detail (for academic pubs) I wonder about for the specification-required path. (I've no worries about the IESG approval path.) I figure we might be better off seeing how an RFC-required setup pans out for a bit, then, if it seems right, loosening that to the point where some DEs can ok adding entries after we've figured out what guidance to provide to those DEs. 2: Does it list a name that they'd be using? Great, done! [ insert the Oprah Winfrey "You get a registration and you get a registration" meme here — https://knowyourmeme.com/memes/oprahs-you-get-a-car ]. It is intended to be an informational registry to help people avoid conflicts, and potentially also figure out what to read to know more about foo.alt - IMO they can be handed out like candy. It's better to have it easy for people to get added than just squat… The current IANA Considerations bit says "Expert Review" or "IESG Approval" — the second bit is specifically incase there are issues with getting DEs… That said, I'd still be ok with progressing the draft if the registration rules stayed as they are now. Thank you - the registry is something I've gone back and forth on, because there are pros and cons… Sure - if it's only me arguing for RFC-required, then I'm fine with being in the rough on that aspect. Cheers, S. W Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review
Hiya, On 19/08/2022 20:43, Warren Kumari wrote: So, it is perfectly acceptable (in my view) for it to have: ReferenceName - a-cool-document foo.alt another-documentfoo.alt yet-another-doc bar.alt I agree that such duplicate names are acceptable in this registry. I scanned the draft quickly and think it's good. (I'll try do a closer read in a few days.) Only thing with which I'd argue for now is that I think RFC required is a much simpler rule for the registry. Any other option will require some designated experts with some guidance for those DEs, and I'd expect it to be hard for us to agree what guidance to include in the draft or not, and I'd expect it to be hard to find DEs for this registry. That said, I'd still be ok with progressing the draft if the registration rules stayed as they are now. Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...
Hiya, On 19/08/2022 14:35, Paul Wouters wrote: Okay, so I understood that you want to run a yellow pages for non-DNS domains at IANA. FWIW, that doesn't describe where I've so far landed on this. It omits the requirement that there be an RFC for each entry. That IMO does mean such a registry is within the purview of the IETF. S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...
On 18/08/2022 21:11, Eliot Lear wrote: I could see the value in reserving dns.alt, and the potential mischief that could ensue by not doing so. Ugh. Were that done I'd be worried abut the effect on the web PKI of creating sorta-synonyms like that. S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...
Hiya, On 18/08/2022 20:26, Paul Vixie wrote: i don't think the .ALT draft is going to move forward without such change, so the distinction will be between .ALT as proposed and .ALT as evolved, not between .ALT and some other SUDN. I think I agree. But to check: are we saying that the .alt I-D ought be changed (possibly outside dnsop) so that there's an IANA registry for one level of name beneath .alt with "RFC required" as the requirement for adding an entry? (So those RFCs could come from the IETF, IRTF, ISE etc. at present.) Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...
Hiya, On 16/08/2022 03:01, John Levine wrote: Right. If it's FCFS, I am sure I am not the only person who will be waiting at the gate with thousands of preemptive registrations. Why? I honestly don't know so that's not a rhetorical question. Ta, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On ALT-TLD, GNS, and namespaces...
Hiya, On 16/08/2022 00:22, Paul Wouters wrote: it’s a whole new gold rush. I don't get that. The thought experiment(*) is a putative .alt setup with FCFS registration for 2LD equivalents and where recursives and all DNS servers are expected to barf on queries for such names one way or another. I don't see what'd attract many people to register names there myself but maybe I'm naive. What'd be the attraction? Ta, S. (*) To be clear, I'd have no objection to somewhat more onerous registration rules, like RFC required or whatever so the above is just trying to understand what makes you think there'd be enough registrations to be a problem in that particular setup. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On ALT-TLD, GNS, and namespaces...
On 15/08/2022 06:09, Christian Huitema wrote: .onion is barely visible, with 0.01% of root traffic. So that should be significant for the disposition of the GNU stuff, shouldn't it? My impression is that there'd be maybe an order of magnitude fewer clients. S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On ALT-TLD, GNS, and namespaces...
Hiya, On 15/08/2022 02:07, Mark Andrews wrote: Most users of Kerberos use the DNS namespace as that authority. I wonder about that. My experience is that most admins (not quite typical users:-) setup some kerberos realms that are named after DNS domains, but also have legacy and non-legacy realm names that don't map to DNS domains at all well. Again though, that's anecdotal, and I don't know of a study that's measured that. Be great to see one if someone's done the work. Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On ALT-TLD, GNS, and namespaces...
On 15/08/2022 00:58, David Conrad wrote: On Aug 14, 2022, at 3:54 PM, Stephen Farrell wrote: On 14/08/2022 23:37, David Conrad wrote: It seems to me that “the correct handling” of how an operating system or an application distinguishes what protocol to use for domain name lookup (other than DNS) is outside of the bailiwick of DNSOP or the IETF. Disagree in part. I think it is entirely within the balliwick of the IETF to document that e.g. gnu.alt. or gnu. is a SUDN. Ah. Well, perhaps this time, after 20+ years, it’ll be possible to come up with something that works. Works for whom? I think it's entirely possible for the GNU people to come up with something they think works that does not break anything. Personally, I'm not convinced they're right about the first part, but I'm happy enough about the second. IMO that "happy enough" ought be the limit of our concern - we're doing wrong IMO if we try prevent the GNU folks trying their thing just in case it works better than expected. And that's how I at least perceive a lot of the discussion on this topic. S. Regards, -drc OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On ALT-TLD, GNS, and namespaces...
On 14/08/2022 23:37, David Conrad wrote: It seems to me that “the correct handling” of how an operating system or an application distinguishes what protocol to use for domain name lookup (other than DNS) is outside of the bailiwick of DNSOP or the IETF. Disagree in part. I think it is entirely within the balliwick of the IETF to document that e.g. gnu.alt. or gnu. is a SUDN. And also to specify how such names are used in GNU protocols so that someone who cares could also implement and achieve interop, be they an OS vendor or not. And given how niche the protocols we're discussing are - I don't think DNS ops folk would notice. Or are you suggesting the DNS protocol be modified to deal with such "a niche thing” to facilitate transition? No. (Honest question: e.g., one could imagine the root servers “knowing” about SUDN and doing special things when they see queries for (mostly, except for the root query obviously) non-DNS resolution protocols and DNSOP may be a good place for that discussion). I think at this stage dnsop is the wrong place for these discussions. So Warren's idea of another venue seems worth a shot. Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On ALT-TLD, GNS, and namespaces...
On 14/08/2022 19:32, David Conrad wrote: Stephen, On Aug 13, 2022, at 7:14 PM, Stephen Farrell wrote: But, there are also what ought be almost purely technical parts, Sorry to be dense, but what exactly are those technical parts, specifically those that are relevant to DNSOP and/or the IETF? It was the text right after the bit you quoted. In full: > But, there are also what ought be almost purely technical > parts, and IMO the correct handling of such a niche thing > as a namespace the GNU people would like to use (without > DNS) is one of those technical discussions. Cheers, S. Thanks, -drc OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On ALT-TLD, GNS, and namespaces...
On 14/08/2022 15:57, Paul Wouters wrote: On Aug 14, 2022, at 09:16, Stephen Farrell wrote: but otherwise stuff works fine even if it can sometimes be confusing as to how kerberos realms and DNS domains do or don't map to one another. But that’s because foo.example in DNS maps to FOO.EXAMPLE in Kerberos in most deployments. I don't believe "because" is correct. I've seen many kerberos realm names that don't map well to DNS domains. Stuff still works. That said, I've not seen any measurement study on the topic. let’s say I get COCA-COLA.COM, that’s quite a different situation. We can have all the clever mappings for DNS to support alternative backend systems, but in the end the real issue is that “issued names” in the DNS world won’t map to alternative owners. The only way to guarantee that is to carve out some strings. But it will be unpopular strings because the popular ones are taken or reserved. My point here is that the Internet can survive two widely- deployed standards with potentially conflicting uses of the same names with no need for a guarantee that there's any particular relationship between some DNS domain and kerberos realm. (And again, I'm not saying that that "solves the problem" - all I'm saying is that invalidates some of the more "absolutist" arguments I've seen used.) I'm fine that we carve out a .alt or similar and that ICANN carve out a .internal or similar, as both make sense. Cheers, S. Paul OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On ALT-TLD, GNS, and namespaces...
Hiya, On 14/08/2022 03:59, rubensk=40nic...@dmarc.ietf.org wrote: On Kerberos, we need to note that one use case of Kerberos is Microsoft Active Directory; MS AD is behind a number of name collisions that happened in the 2012 root zone expansion, including one string that will likely never show the light of day in the root (.corp). So, this might be the telltale sign, not the good fortune ahead one. I'd interpret that as a positive still - despite the fact that kerberos naming is so widely deployed, and has been for decades, the impact on the DNS isn't serious - one or so of the labels from the huge namespace of potential new tlds wasn't usable when ICANN ran their gTLDs-via-money process, but otherwise stuff works fine even if it can sometimes be confusing as to how kerberos realms and DNS domains do or don't map to one another. Cheers, S. We also could think into this in terms of what we can do; .alt, .arpa and .internal all look feasible and could alleviate potential collisions(.arpa already succeeded in .home.arpa). Will blockchain start-ups adopt them ? Likely not, because they just want the end run around ICANN and couldn't care less about interoperability. But by providing those that do care with options, we get more friends and less foes. Rubens On 13 Aug 2022, at 23:27, Stephen Farrell wrote: Signed PGP part So I think this discussion might benefit from also remembering that we have a decades-long and widely deployed history of IETF standard name forms that use the same name syntax as domain names that may or may not be related to names used in the DNS. Kerberos [1] does exactly that. And the sky never fell, nor has anyone had to pay large numbers of currency units to pick a kerberos realm name afaik. I'm not saying this solves the conundrum, but I do assert that this fact invalidates some arguments to the effect that the IETF cannot standardise another "global" name form using the same syntax because of problems that may or may not be caused by overlaps in the name spaces - we've not had critical problems with doing just that for nearly 30 years. (Since RFC1510.) Cheers, S. [1] https://www.rfc-editor.org/rfc/rfc4120#page-55 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On ALT-TLD, GNS, and namespaces...
So I think this discussion might benefit from also remembering that we have a decades-long and widely deployed history of IETF standard name forms that use the same name syntax as domain names that may or may not be related to names used in the DNS. Kerberos [1] does exactly that. And the sky never fell, nor has anyone had to pay large numbers of currency units to pick a kerberos realm name afaik. I'm not saying this solves the conundrum, but I do assert that this fact invalidates some arguments to the effect that the IETF cannot standardise another "global" name form using the same syntax because of problems that may or may not be caused by overlaps in the name spaces - we've not had critical problems with doing just that for nearly 30 years. (Since RFC1510.) Cheers, S. [1] https://www.rfc-editor.org/rfc/rfc4120#page-55 OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On ALT-TLD, GNS, and namespaces...
On 14/08/2022 02:55, David Conrad wrote: As John Levine points out, this isn’t a technology issue: it is social/politica/economic/bureaucratic I believe the above statement is incorrect in referring to "this" issue in the singular. There is more than one thing in play here and ignoring all but one aspect seems to me fairly guaranteed to lead to discussion based on premises that are false, or not agreed among the participants. There are certainly non-technical parts of these discussions. But, there are also what ought be almost purely technical parts, and IMO the correct handling of such a niche thing as a namespace the GNU people would like to use (without DNS) is one of those technical discussions. Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On ALT-TLD, GNS, and namespaces...
Hiya, On 13/08/2022 23:32, Paul Vixie wrote: warren's .ALT proposal can begin to undo that harm. internet standards should describe roads not walls. i am no fan of blockchain naming, but i'd like those systems to reach the market rather than be prevented from doing so. A strong +1 to the above and the rest of the message before that quote. I've no particular fondness for .alt, nor do I know if the GNU people could live with gnu.alt but I think the IETF (and not ICANN) really ought be able to, and should, carve out something like .alt for folk who want to not use the DNS for domain names. Cheers, S. PS: I also support Warren's idea for a venue for these discussions. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld
Hiya, I've scanned the draft and read the thread. AFAICS the draft does not ask for a new 6761 (*) special use name, so ISTM speculation as to what the authors or their pals would be better off doing is moot. (I.e. there's no point telling 'em to go away and come back asking to use gnu.alt or whatever - they know enough already to ask for that if that's what they want.) I think the draft as-is should be published by the ISE with a disclaimer that deployment of what's described isn't consistent with the DNS, but I see no reason to ask for more than such a disclaimer, to publish an independent stream RFC describing a technology that's been around a number of years and has what I guess is a relatively modest scale deployment. Cheers, S. (*) For those who think nobody likes 6761 - I do! And in addition, the idea that adding a new tld label should "cost" the same as 10^5 or so litres of milk is appalling. IMO ICANN should and will in future be ashamed that that's how they played the gtld game. On 01/08/2022 13:31, Independent Submissions Editor (Eliot Lear) wrote: Hello from your friendly neighborhood independent submissions editor. It is indeed the case that draft-schanzen-gns is in conflict review. It is also the case that Warren and I have been discussing that review. Obviously there are some concerns. On the one hand, we need to find a way for people to explore alternative namespaces that look a bit like domain names. On the other hand, we don't want to create problems with user expectations. draft-ietf-dns-alt-tld seems like a reasonable means to bridge these concerns. The ISE is willing to wait a reasonable period of time for this work to conclude. It seems that you are close to done. I know that this draft doesn't solve *all* namespace research problems by any stretch, but it will make life easier for at least SOME researchers, not to mention me. Whether that means using TLD labels that begin with _ or whether that means suffixing them with ".ALT", I leave to you experts to sort. I do agree with Martin that it would be helpful to have some registration of names so that conflicts between name spaces can be avoided. This would also encourage formal documentation of those projects. Thanks! Eliot (ISE) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] post-dispatch dispatching a draft...
Hi all, At IETF 113 a draft of mine [1] was presented (slides [2]) at the dispatch session. Part of the upshot there was to check with dnsop if people felt asking for adoption here would be the right plan for this draft. The draft is concerned with (re-)publishing ECHConfigList values in SVCB/HTTPS RRs as the keys for ECH are rotated, but in the context where the ECH private key holder and the DNS publishing entities differ. As an FYI, ECH interop servers operated by Cloudflare and by me rotate such keys hourly so some new automation is needed for cases where one does not have some kind of dynamic DNS API available. To be clear: my own opinion is that adopting this in dnsop would not be a good plan, but that asking the TLS WG would be the right plan instead. That said though, even if this were adopted by TLS, I think it'd benefit from input from dnsop (and httpbis), once the adopted form of the draft had taken would could be a near-final overall shape. And who knows, maybe I'm wrong and this'd be better handled here. So - do people here consider it'd be useful to try for a call for adoption for this in dnsop, or do you agree with me that doing that in the tls wg would be better? Thanks, S. PS: If it's useful and there's time I'd be fine with asking the above again at the upcoming interim. [1] https://datatracker.ietf.org/doc/draft-farrell-tls-wkesni/ [2] https://datatracker.ietf.org/meeting/113/materials/slides-113-dispatch-a-well-known-url-for-publishing-echconfiglists-00 OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Is DNSSEC a Best Current Practice?
On 10/03/2022 19:04, Paul Wouters wrote: Sounds good to me. Something analogous to bcp195 could be a good plan, esp as signature algorithms, rsa key sizes and maybe ksk/zsk handling change over time. Not sure if it'd be better part of such a document but also be no harm to try document good/best practices in preventing hijacking (2fa etc), so one could consider a bcp on the topic of "managing data/origin authentication for DNS data" rather then just DNSSEC maybe. Either could be useful. Cheers, S. Even better if we would clarify DNSSEC is not an optional part of DNS, but I don’t think you are volunteering for that discussion Sent using a virtual keyboard on a phone On Mar 10, 2022, at 13:54, Paul Hoffman wrote: Greetings again. My motivation here is kinda trivial, but I've heard it is a common complaint. When writing a about DNSSEC, I need to reference the RFC. But it's three RFCs (4033, 4034, and 4035), and possibly another (6840). It would be awfully nice to refer to "DNSSEC" with a single reference like "BCP 250". To get there, we need to update the RFCs and say that we want an BCP. This is mostly a paperwork exercise, but this WG isn't terribly good at getting those done. Maybe we could create a short-lived WG for moving DNSSEC to BCP that just the DNSSEC-y people need to pay attention to. If we do it, that WG would not take up any new DNSSEC-related work, just spruce up the base RFCs. In the big picture, I think it would be good for the DNS to be able to refer to DNSSEC more easily. Thoughts? --Paul Hoffman___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Testing SVCB/HTTPS records
Hi Stephane, On 19/01/2022 08:36, Stephane Bortzmeyer wrote: Does anyone know a service/software to check the consistency between SVCB/HTTPS DNS records and the Web site? Such as testing the various alpn, the various IP addresses hints, the aliases, etc. (It seems ssllabs.com don't do it yet.) I suspect that many people will put wrong SVCB/HTTPS records... I made a test setup for my TLS/ECH work. [1] Happy to take PRs or tweak if it's useful to others. Cheers, S. [1] https://github.com/sftcd/echdnsfuzz ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Hiya, Without commenting on the rest of the discussion (though I do agree with those who made the point that optimising for those writing zone files here is better than for those parsing zone files)... On 10/05/2021 17:56, Ben Schwartz wrote: It would also require a dramatic rewrite of a specification that is now widely deployed. I'm not aware this is widely deployed. To be fair I mostly care about deployments that support ECH and so far I know of 2 of those. There may be more doing HTTPS or SVCB but not ECH I guess. If so, I'd find it valuable to see a list of those so I can get a sense of the variability to be seen in HTTPS/SVCB deployments. So - can you provide some backup for that claim of being widely deployed that might help me see how folks are choosing to deploy? Thanks, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] using type65 for https with a non-default port
Hiya, On 06/04/2021 21:00, Ben Schwartz wrote: Here's a proposal to add an example as you suggest: https://github.com/MikeBishop/dns-alt-svc/pull/311/files LGTM, thanks, S. On Sat, Apr 3, 2021 at 2:44 PM Stephen Farrell wrote: On 03/04/2021 18:07, Ben Schwartz wrote: It's supposed to be _8410._https.foo.example.com, qtype=65 Thanks. That'd work for me. Probably no harm to add an example or explicit statement to that effect. Cheers, S. On Sat, Apr 3, 2021 at 12:55 PM Stephen Farrell < stephen.farr...@cs.tcd.ie> wrote: Hiya, I had a quick look at the draft I'm not sure if I know for sure what qname/qtype is supposed to be used for e.g. https://foo.eample.com:8410/ - can anyone say off the top of their head? The options I can imagine are: qname: foo.example.com, qytpe: type65 qname: _8410._https.foo.example.com, qytpe: type64 I guess some other combos might also exist but I'm not quite sure which to query nor which to publish. Thanks, S. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] using type65 for https with a non-default port
On 03/04/2021 18:07, Ben Schwartz wrote: It's supposed to be _8410._https.foo.example.com, qtype=65 Thanks. That'd work for me. Probably no harm to add an example or explicit statement to that effect. Cheers, S. On Sat, Apr 3, 2021 at 12:55 PM Stephen Farrell wrote: Hiya, I had a quick look at the draft I'm not sure if I know for sure what qname/qtype is supposed to be used for e.g. https://foo.eample.com:8410/ - can anyone say off the top of their head? The options I can imagine are: qname: foo.example.com, qytpe: type65 qname: _8410._https.foo.example.com, qytpe: type64 I guess some other combos might also exist but I'm not quite sure which to query nor which to publish. Thanks, S. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] using type65 for https with a non-default port
Hiya, I had a quick look at the draft I'm not sure if I know for sure what qname/qtype is supposed to be used for e.g. https://foo.eample.com:8410/ - can anyone say off the top of their head? The options I can imagine are: qname: foo.example.com, qytpe: type65 qname: _8410._https.foo.example.com, qytpe: type64 I guess some other combos might also exist but I'm not quite sure which to query nor which to publish. Thanks, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
Hiya, On 04/01/2021 16:05, Paul Wouters wrote: While asking is fair, you would also have to define what you do based on the outcome of that ask. You left that out, I don't think I did omit that. My stated reason to ask was to help me figure out what I think about the draft named in the subject line. And yes, I do think that if a codepoint is being requested for a new version of an existing one then asking about how the existing one was used is a good thing to do. The case with gost and rsa+sha1/sha256 isn't the same because gost is a series of national standards. > As to answer your question, I believe GOST did not see > more than about 5 domains use it in what was clearly a > "Testing" deployment. Thanks. In that case, it sounds like it'd have been better to use a private or experimental code point for that kind of thing. OTOH, my understanding (based only on hallway chats over the years) was that the codepoint was allocated for political reasons. Either way, does that mean that a lot of effort to implement and test was wasted since that codepoint was allocated? If so, avoiding that in future would be good, if there's a way to do that. Cheers, S. PS: note that I'm neither supporting, nor objecting to, Paul's draft in the above. OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
Hiya, On 04/01/2021 14:23, Paul Wouters wrote: On Mon, 4 Jan 2021, Stephen Farrell wrote: WRT GOST, we're not really talking about an algorithm but rather a national crypto standards scheme that selects sets of algorithms. For such things, whether from Russia or the US or anywhere, I think it's quite fair to ask "how has version N deployment gone?" Why is that fair? Eh? Seems to me that asking about the facts is fair. I have a hard time envisaging a way it could be unfair tbh, so your question surprises me. I'd say the community was quite busy and possibly made some mistakes in the past. I don't think that is a valid barrier for the future. For example, would we bar NIST or the US from ever standarizing a new RNG? :P You seem to be assuming that the goal of asking is to justify saying "no." That wasn't my intent - I just think we make better decisions if we know the deployment facts, rather than our decisions being based on whomever is good at rhetoric or automatically giving nation-states or mega-companies whatever they ask. WRT a new RNG - yes if one was suggested from a US or any source, then we absolutely should be very careful with that. Mind you, I can't think of an iana registry that has RNG algs as entries so maybe it's not a super-good example. And "how to handle" isn't always "adoption" but could as I said result in deprecating version N if nobody really cares about it - in such a case that'd help implementers and better reflect reality. If a national government wants something, we could ask for at least one implementation to be planned. That was not what I suggested asking. I'd just like to know if or how much the current gost stuff gets used with dnssec. But using this meassure as a way to stop these seems wrong. It would move the possible standarization from IETF to say openssl or bind. I do think one issue is how often GOST (or FIPS) updates their algorithms and obsoletes older ones. That might cause a faster depletion of the registry then we'd like. But on the other side, if would be nice if we could become faster with obsoleting algorithms too. Why is there still RSASHA1 deployed Yep. Allocating codepoints for things that don't get used (if that is the case with gost algs and dnssec which I *still* don't know any more about), doesn't help us move on from things that did get used. Cheers, S. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
Hiya, On 04/01/2021 11:31, Vittorio Bertola wrote: We could ask the proponents of new algorithms for information on current or expected usage. WRT GOST, we're not really talking about an algorithm but rather a national crypto standards scheme that selects sets of algorithms. For such things, whether from Russia or the US or anywhere, I think it's quite fair to ask "how has version N deployment gone?" as part of considering how to handle version N+1. Indeed, it'd seem wrong not to ask and get an answer. And "how to handle" isn't always "adoption" but could as I said result in deprecating version N if nobody really cares about it - in such a case that'd help implementers and better reflect reality. Cheers, S. However, if adoption is relevant to any kind of decision on what to do with an algorithm proposal, this should better be formalized somewhere and applied evenly to all algorithms that may appear in the future. Personally, I think that some expectation of adoption would be useful not to clutter the list of algorithms, but the threshold should be quite low. OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
Hiya, On 01/01/2021 17:58, Paul Hoffman wrote: The WG has already adopted the revised GOST document as a WG item; what you are proposing (if the current use is negligible) would be in the opposite direction. I wasn't "proposing" that, just posing it as a possible option that might or might not be sensible to consider depending on the facts relating to usage if/when we can get 'em. Absent usage information, I'm not at all sure whether or not any change from the status quo is warranted. Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
Hiya, I note that you didn't answer my question about actual use of gost and guess that's because you don't have that data to hand. I'm still interested in that if someone has info because grounding this in reality seems likely better. On 01/01/2021 16:38, Paul Hoffman wrote: The status quo (standard required) will likely absorb a lot of time for the IETF if the WG decides to move the revised GOST forward. It will also probably land in the CFRG. Reducing the requirement to RFC required allows their document to be informational. The WG already has RFC 8624 that talks about what implementers should do with various algorithms. Clearly, it will need to be updated for the revised GOST regardless of whether the WG changes the IANA considerations. Also, as a reminder, this isn't only about GOST. In the coming years, there will be a raft of post-quantum signing algorithms with different signature and key size ratios that people will want adopted. Putting every one of them on standards track seems onerous to some of us. Sure, I get all that, but the trade-off is between our time vs. some properties of the deployed DNS so it may or may not be that us spending time is the better/cheaper option overall even if that's a PITA for us. Personally I could more easily figure out my position on this if I knew how much gost was really in use. (If it's negligible, then one could argue that moving the current gost alg to historic or something might be the better option.) Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
Hiya, On 31/12/2020 21:48, Eric Rescorla wrote: 1. Don't allocate a code point at all 2. Allocate the code point but in some manner that makes clear we don't endorse it (effectively what TLS does for algorithms like this) 3. Allocate the code point without comment FWIW, I kind of agree with ekr, both as to the options and on my current preference to not too easily loosen up for DNSSEC. That said, I wonder as to the actual deployment of algs that we'd not recommend, especially given the relative scarcity of DNSSEC signing. Does anyone have a pointer to survey-like material that has a focus on rarer algorithms in DNSSEC? One reason to ask is that from a first glance it looks to me like .ru isn't using gost, which would be telling, if correct. To be clear: I don't think spending much time debating how to handle algs for an infinitesimal number of zones is that worthwhile, so that'd be another reason to prefer the status quo, if that is the case. Thanks, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04
Hiya, (I wouldn't put that much store on my specific response, but since you asked...) On 08/12/2020 01:23, Benjamin Kaduk wrote: Hi Ondřej, Thanks for this detailed writeup; it really helps bring clarity to the current situation. In light of the follow-ups from others, it seems that there are actually two distinct but somewhat entangled issues: (1) whether SipHash is a strong cryptographic hash function that delivers its stated properties. Right. And whether there are any oddities, e.g. ways in which one ought not use the algorithm. Asking about that is IMO a good plan because once this gets used somewhere it'll be used again elsewhere so I'd prefer we know if/when that's ok or not. (Additionally, I'll admit a slight personal bias against adding new algorithms where we have existing ones that are fine - I figure that just costs more and damages interop for little or no benefit. That could be outweighed though if the new alg is already implemented and deployed for the purpose in question and/or if it's widely available in libraries.) (2) whether the stated properties of SipHash are appropriate for the scenario we are using it for in this document. For DNS cookies, I'd say it'd be very unlikely that this is not ok. Cheers, S. I had initially assumed that Stephen's review was asking about (2), but for the most part we tend to ask CFRG about things like (1). So, while I agree that it's valuable to get input from the CFRG on (1) and am willing to start the conversation there if needed, I would also like to get Stephen's (or anyone else's really) input about question (2). I suspect that we are okay in that regard, not least because of the other similar usage that you describe, but request that the analysis of what properties we need from a hash function for this use case (and that SipHash meets them) be included in a future version of the draft. Thanks again, Ben On Fri, Dec 04, 2020 at 10:14:29PM +0100, Ondřej Surý wrote: Hi Benjamin, I did not used appeal to authority as an argument, but I’ve just provided examples that SipHash has been implemented in the similar scenarios and there hasn’t been reported issue with the choice for years now. Using fast PRF (pseudorandom function) for the DNS Cookies is a good choice because it matches the required properties - it needs to be fast and secure in a sense that attacker can’t compute neither the key nor the output of the function. DNS Cookies are not MACs. Sorry for the misnomer of the brute force - what I meant was a protection against a replay attack. I’m just currently very tired with day to day job. Please note that DNS Cookies doesn’t protect the actual DNS message payload, it merely provide means to establish trust between the client and the server as to distinguish between a legitimate and spoofed traffic, so different policies can be used - Response Rate Limiting (RRL) could be turned off for DNS messages with cookies or when under attack it could require fallback to TCP for DNS queries without the DNS Cookie. The DNS cookies doesn’t protect the actual content in any way, neither it does protect the communication from the on path adversary. In that regard, the client cookie is just nonce (and it’s just convenient to use same algorithm to generate it, but it could be output from CSPRNG as well) and the server cookie is a cryptographic primitive that uses the client nonce, key and timestamp to construct the server cookie. Such server cookie is used by the DNS client to authenticate to the server (it’s shared secret, but it requires no per-client state on the server). Just to repeat, the actual payload (DNS message) is not protected by the DNS cookie. If the DNS server could keep a state for every DNS client, a CS random number would be as good as the output of the SipHash. I might not be a cryptographer as my daily job, but I am reasonably confident that SipHash has matching properties, it hasn’t been broken as of today. Also all DNS vendors have agreed to make this choice and the RFC here is merely a way how to ensure interoperability between various implementations. (Typing this on phone, so excuse any irregularities in the text.) Ondrej -- Ondřej Surý — ISC (He/Him) On 4. 12. 2020, at 21:37, Benjamin Kaduk wrote: Hi Ondřej, Just because someone else does something, even a "big name", doesn't necessarily make it a good idea for us to also do it. We should be able to justify our algorithm choices on cryptographic principles, not just appeal to authority. In a similar vein, you said something about the 32-bit timestamp being wide enough to prevent brute-force attacks. Could you say a bit more about what attacks those are that are being prevented? I'm not really seeing how the width of the timestamp comes into play for that concern, just from a quick skim of the document. (Timestamps tend to not provide much protection against brute force by themselves, since time is relatively guessable,
Re: [DNSOP] [Last-Call] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04
Hiya, On 05/12/2020 14:58, Salz, Rich wrote: There is a fair amount of academic study around SipHash, and while everyone can make mistakes, its creators have a pretty good reputation. I don't think we can say SipHash is unknown in the industry. The TLSWG made it a practice to ask CFRG to "approve" all crypto it used (except perhapd HKDF, but that's a side note). The DNSOP has no such practice. FWIW, I think asking CFRG for comment (not approval) whenever a new algorithm is introduced onto the standards-track is a good idea, regardless of the WG from which the draft came. Such checks don't mean anyone thinks badly of any algorithm, the argument is it's better to ask a question in the place where the expertise lies, just in case. Cheers, S. If SECDIR or the Ads thinks SipHash isn't good, it would be great to hear reasons. I haven't heard any yet. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Last-Call] Secdir last call review of draft-ietf-dnsop-server-cookies-04
Hiya, On 02/12/2020 22:07, Willem Toorop wrote: Op 02-12-2020 om 22:49 schreef Stephen Farrell: Hiya, On 02/12/2020 21:38, Willem Toorop wrote: Op 02-12-2020 om 21:37 schreef Stephen Farrell: ad 2) we need a value that’s synchronized well enough and monotonic. I honestly don’t see any value in using 64-bit value here. Using unixtime has a value in itself, it’s a well-known and there’s a little room for any implementer to make a mistake in an implementation. The interoperability is more important than the actual value of the counter. It’s write only counter, nobody is going to interpret it after it has been generated, and it’s wide enough to prevent brute forcing. So what happens after 2038? That's really not v. far in the future any more. The draft states that `All comparisons involving these fields MUST use "Serial number arithmetic", as defined in [RFC1982]'. So it can not be used to compare differences larger than 68 years, but comparisons of cookie timestamps are more in the "hours" order of magnitude. Sorry for being dim, but is clear what value to put in those 4 octets in say 2039 such that different implementations will do the right thing Well the text does specify an "32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC", so because of the "unsigned" the wrap to 0 is only in 2106, not 2038. Ah. I missed that "unsigned." (Does that mean implementers might also?) But even then, in 2106, it should not be a problem to check the age of a cookie because of the rfc1982 comparison (which takes care of the wrap) and the fact that Server Cookies will not be older than hours (and not years). So the buggy case would be where a server re-constructs the input to the hash after some kind of round-trip of the octets (to e.g. struct tm or something and then back to time_t and to network byte order) at which point you could I think get failures depending on who implemented what incorrectly. That kind of thing has been seen before (even if it seems a bit mad;-) FWIW, I'd say it's worth a few more words to try reduce the probability of such failures happening, e.g. maybe just highlighting the "unsigned/2106" point you made above would be enough. But, if the WG don't want to do that, that's also fine by me. Cheers, S. Cheers, -- Willem I did glance at rfc1982, so there may be very far-sighted text in there that I missed:-) And it may even be fine for this purpose if different servers differ by a second or so at that point, but even if so, it may be a bad plan to leave that unspecified in case other timestamps use the same code. Cheers, S. Cheers, -- Willem Cheers, S. Cheers, Ondřej -- Ondřej Surý — ISC (He/Him) On 2. 12. 2020, at 18:47, Stephen Farrell via Datatracker wrote: Reviewer: Stephen Farrell Review result: Has Issues I see two issues here worth checking: 1. I don't recall SipHash being used as a MAC in any IETF standard before. We normally use HMAC, even if truncated. Why make this change and was that checked with e.g. CFRG? (And the URL given in the reference gets me a 404.) 2. Is it really a good idea to use a 32 bit seconds since 1970-01-01 in 2020? I'd have thought that e.g. a timestamp in hours since then or seconds since some date in 2020 would be better. Here's a couple of nits too: - section 1: what's a "strong cookie"? - "gallimaufry" - cute! but not sure it'll help readers to learn that word. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-server-cookies-04
Hiya, On 02/12/2020 21:38, Willem Toorop wrote: Op 02-12-2020 om 21:37 schreef Stephen Farrell: ad 2) we need a value that’s synchronized well enough and monotonic. I honestly don’t see any value in using 64-bit value here. Using unixtime has a value in itself, it’s a well-known and there’s a little room for any implementer to make a mistake in an implementation. The interoperability is more important than the actual value of the counter. It’s write only counter, nobody is going to interpret it after it has been generated, and it’s wide enough to prevent brute forcing. So what happens after 2038? That's really not v. far in the future any more. The draft states that `All comparisons involving these fields MUST use "Serial number arithmetic", as defined in [RFC1982]'. So it can not be used to compare differences larger than 68 years, but comparisons of cookie timestamps are more in the "hours" order of magnitude. Sorry for being dim, but is clear what value to put in those 4 octets in say 2039 such that different implementations will do the right thing? I did glance at rfc1982, so there may be very far-sighted text in there that I missed:-) And it may even be fine for this purpose if different servers differ by a second or so at that point, but even if so, it may be a bad plan to leave that unspecified in case other timestamps use the same code. Cheers, S. Cheers, -- Willem Cheers, S. Cheers, Ondřej -- Ondřej Surý — ISC (He/Him) On 2. 12. 2020, at 18:47, Stephen Farrell via Datatracker wrote: Reviewer: Stephen Farrell Review result: Has Issues I see two issues here worth checking: 1. I don't recall SipHash being used as a MAC in any IETF standard before. We normally use HMAC, even if truncated. Why make this change and was that checked with e.g. CFRG? (And the URL given in the reference gets me a 404.) 2. Is it really a good idea to use a 32 bit seconds since 1970-01-01 in 2020? I'd have thought that e.g. a timestamp in hours since then or seconds since some date in 2020 would be better. Here's a couple of nits too: - section 1: what's a "strong cookie"? - "gallimaufry" - cute! but not sure it'll help readers to learn that word. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-server-cookies-04
Hiya, On 02/12/2020 18:25, Ondřej Surý wrote: Stephen, ad 1) the performance is crucial for DNS over UDP and PRF such as SipHash is more efficient than HMACs. No, it wasn’t consulted with CFRG, and I can’t speak for Willem, but I am confident enough to make the decision. SipHash is widely used for hash tables virtually anywhere now. The text says that you need a MAC though. Personally, I think it'd be wiser to (double-)check before using novel crypto even if the only novelty is use in a standards track RFC. ad 2) we need a value that’s synchronized well enough and monotonic. I honestly don’t see any value in using 64-bit value here. Using unixtime has a value in itself, it’s a well-known and there’s a little room for any implementor to make a mistake in an implementation. The interoperability is more important than the actual value of the counter. It’s write only counter, nobody is going to interpret it after it has been generated, and it’s wide enough to prevent brute forcing. So what happens after 2038? That's really not v. far in the future any more. Cheers, S. Cheers, Ondřej -- Ondřej Surý — ISC (He/Him) On 2. 12. 2020, at 18:47, Stephen Farrell via Datatracker wrote: Reviewer: Stephen Farrell Review result: Has Issues I see two issues here worth checking: 1. I don't recall SipHash being used as a MAC in any IETF standard before. We normally use HMAC, even if truncated. Why make this change and was that checked with e.g. CFRG? (And the URL given in the reference gets me a 404.) 2. Is it really a good idea to use a 32 bit seconds since 1970-01-01 in 2020? I'd have thought that e.g. a timestamp in hours since then or seconds since some date in 2020 would be better. Here's a couple of nits too: - section 1: what's a "strong cookie"? - "gallimaufry" - cute! but not sure it'll help readers to learn that word. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Secdir last call review of draft-ietf-dnsop-server-cookies-04
Reviewer: Stephen Farrell Review result: Has Issues I see two issues here worth checking: 1. I don't recall SipHash being used as a MAC in any IETF standard before. We normally use HMAC, even if truncated. Why make this change and was that checked with e.g. CFRG? (And the URL given in the reference gets me a 404.) 2. Is it really a good idea to use a 32 bit seconds since 1970-01-01 in 2020? I'd have thought that e.g. a timestamp in hours since then or seconds since some date in 2020 would be better. Here's a couple of nits too: - section 1: what's a "strong cookie"? - "gallimaufry" - cute! but not sure it'll help readers to learn that word. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-httpssvc-02.txt
Hiya, On 10/03/2020 19:11, Paul Vixie wrote: > On Tuesday, 10 March 2020 19:05:39 UTC Stephen Farrell wrote: >> Paul, >> >> ... >> >> What's the difference between having a port number >> as part of HTTPSSVC (or whatever we call it;-) in >> the DNS and having a web page on 443 that includes >> hrefs with https:// schemed URLs that are not using >> port 443? > > technically, very little. practically, one of them doesn't solve the problem > addressed by ANAME, and the other does. Sorry, let me try again. HTTPSSVC might include a port option or not. If it does, then traffic will use that as the destination port. If it does not, and someone prefers not to use 443 for their server, they'll just do one more HTTP roundtrip. (They'll likely need to support that HTTP 30x anyway for non-HTTPSSVC aware clients). ISTM the end result is the same traffic heading to the non-443 destination port, but, in the 2nd case, with one gratuitous interaction on port 443. I don't get why that distinction is meaningful for the operator of the network containing the browser, which is where I understood your concern lies. > so we can expect ubiquitous deployment > for HTTPSSVC, Browser support for https on other ports is already there so not sure why that matters. > with a non-modal knowledge spectrum among deployers. I also don't understand what you mean by that last. (I do have a guess, but not a confident one:-) Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-httpssvc-02.txt
Paul, On 10/03/2020 18:54, Paul Vixie wrote: > the httpssvc "port" parameter leading > a service operator to put something on an "alternative origin" whose port > number will be broadly unrecognized by far end managed private networks, > which > would prevent flow-state creation, thus creating black holes Sorry, I'm missing something here. What's the difference between having a port number as part of HTTPSSVC (or whatever we call it;-) in the DNS and having a web page on 443 that includes hrefs with https:// schemed URLs that are not using port 443? Thanks, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXTERNAL] Re: RDBD (Related Domains By DNS)
Hiya, Thanks for taking a read of the draft. On 04/03/2020 04:55, Ben Schwartz wrote: > I'm still not entirely clear on how this is supposed to work, which is why > I would appreciate the worked example. It seems like, in addition to RDBD, > your filter also needs some kind of "appears-related" heuristic, and a list > of "high-trust" domains, on the theory that one should block messages > containing repudiated domains that look similar to a high-trust domain. > However, I don't think this is likely to be a reasonable use of the > existing rdbd-tags, neither of which amounts to an accusation of phishing > per se. (Consider, for example, the entire ".sucks" TLD.) Tend to agree that new tags are likely needed any time one wants better-defined semantics. (That's maybe the core of the design attempt here.) > Regardless of the use case, I think a more detailed example would be > helpful for understanding what heuristics are needed, and to what extent > RDBD would make the use case easier. Ack. Will try add something. Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RDBD draft updated
Hiya, On 10/10/2019 03:52, Martin Thomson wrote: > There's an interesting (web-only) effort looking at a similar > problem: https://github.com/krgovind/first-party-sets There, the > goal is to establish commonality for the purposes of sharing state > (and fate). Yes, I saw that recently. I agree there's a partial overlap in goals. > A great counter-example in that case is the relationship between > github.com and github.io, which are administratively the same, but > purposefully distinct from the perspective of web state. Sure. > > All this makes me wonder what your intent is with respect to > semantics. My goal is to define a mechanism with minimal semantics but that is extensible. (To be open about why - I think efforts in this space have partly foundered because they've started out too ambitious, so I figure a more modest starting point may work out better.) > o 0: states that no relationship exists between the domains > > o 1: states that some relationship exists between the domains > > That's incredibly vague. Nope, it's minimal:-) Again, that is intentional. To take the web example you started with, if someone wanted to use RDBD as a part of that, then I guess it'd mean defining a new rdbd-tag value (call it "W") and its related semantics, e.g. if an RDBD RR with a tag W is published at example.com saying that example.net is related, that might mean that a TLS server cert ought exist that covers both at once before a client would be willing to consider shared state for those names (or whatever else is required to implement the web semantics for W). The definition of W is envisaged to be in some other spec, with whatever IANA registry rules would be adopted for rdbd-tag code points. (Parts of that 16 bit space could be FCFS too of course but I'd guess spec required might be most useful.) > If you consider the possibility of there being richer expressions of > semantics, this starts to look a bit like link relations at the DNS > layer: https://tools.ietf.org/html/rfc8288 I think the better approach, if expressing relationships in DNS, is likely to be to encode those down to rdbd-tags or similar. At least, that's the approach we're espousing here. Cheers, S. > > On Tue, Oct 1, 2019, at 07:17, Stephen Farrell wrote: >> >> Hi all, >> >> As per discussion at IETF 105, Alex and I did some more work on the >> RDBD draft (lots of text edits and a bit of prototyping) and have >> posted a new version. [1] >> >> We'd be very interested in folks' opinions. >> >> Thanks, Stephen & Alex. >> >> [1] https://tools.ietf.org/html/draft-brotman-rdbd-03 >> >> ___ DNSOP mailing list >> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop >> >> Attachments: * 0x5AB2FAF17B172BEA.asc * signature.asc > > ___ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-nygren-dnsop-svcb-httpssvc
Hiya, On 07/10/2019 15:37, Tim Wicinski wrote: > All > > We want to thank the authors for working on this. The chairs > feel that part of the discussion around this document would be to > resolve: > - ANAME/HTTPSSVC possible overlaps > - The RR Type Name (no one seems to be in love with current names) > > This starts a Call for Adoption for draft-nygren-dnsop-svcb-httpssvc > > The draft is available here: > https://datatracker.ietf.org/doc/draft-nygren-dnsop-svcb-httpssvc/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. I support adoption. If it looks like it'll be accepted by browsers for ESNI purposes, then I'll be implementing too. If the WG do adopt this, then we really have to sort out (with the TLS WG) whether or not this will be the one and only way of publishing ESNIKeys. I hope the answer will be: "yes, this is *the* way to do that" but that'd mean we'd also need to get it right for other uses of TLS with ESNI and not just HTTPS. (Should be doable though.) The main caveat for me is I don't know if it'd be worth publishing an RFC if this doesn't end up getting deployed in browsers. So getting clarity there as early as poss would be good if we can. Cheers, S. > > This call for adoption ends: 21 October 2019 > > Thanks, > tim wicinski > DNSOP co-chair > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RDBD draft updated
Hi all, As per discussion at IETF 105, Alex and I did some more work on the RDBD draft (lots of text edits and a bit of prototyping) and have posted a new version. [1] We'd be very interested in folks' opinions. Thanks, Stephen & Alex. [1] https://tools.ietf.org/html/draft-brotman-rdbd-03 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Hiya, On 25/03/2019 09:13, Eliot Lear wrote: > Putting aside legal language, but Brian’s basic notion is that the > user can make an informed decision and the network can express its > policies, with which the user can agree or not agree (and go > elsewhere). Having the protocol elements to permit this sort of > agreement is its own tussle. I see a problem with the above argument. DNS means nothing to most people, so I can't see how they can ever make the informed decision you mention. Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
Hiya, On 22/03/2019 22:08, Puneet Sood wrote: > As a core principle, Google Public DNS aims to provide a DNS resolver > that respects our users’ privacy. Towards that goal, we aim to provide > high quality implementations of various DNS transport mechanisms that > our users can use to reach the service. This includes the traditional > UDP and TCP transports as well as DNS-over-TLS and DNS-over-HTTPS that > provide privacy for the user’s communication with a DNS resolver. That's good to hear. As I'm sure you know well, in addition to transport security, things like logging etc. also affect folks' privacy. Not sure if you're aware of it, but there's an effort to craft BCP-like text on that broader topic in a draft [1] in the dprive WG. It'd be great to get your and other public recursive operators' take on that draft, as some of those issues have also been a cause of some of the much discussion here;-) Cheers, S. [1] https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-02 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
On 20/03/2019 05:46, Brian Dickson wrote: > On Tue, Mar 19, 2019 at 8:36 PM Stephen Farrell > wrote: > >> >> >> On 20/03/2019 03:17, Brian Dickson wrote: >> >>> - If a network operator has any policy that is enforceable, ONLY the >>> technical policy enforcement model scales. >> >> My mail was about my policy for my home network and explicitly said >> that I do not claim that policy ought be followed by all home networks, >> never mind other kinds of network. Your argument about scale is not >> therefore relevant. (At least, not unless you want to give up all >> argument along the lines of "consider the children.") >> > > I am saying, that the work product envisioned by participants of the side > meeting, > needs to be some framework that scales, regardless of where it gets used. I'm not at all sure about a "framework" being the output. I do agree that solutions for networks at all scales are required. > > It does not matter whether any policy does or does not require scalable > mechanisms. > What does matter is that there exist networks where the mechanisms need to > scale. More than one thing matters. That needs to be kept in mind. > > What is being envisioned and proposed, is a flexible-enough framework, that > scales. > > If something scales, it scales. If it scales, it won't make it impossible > to do what you want, tautologically. > > Let's try this using classical logic: > > Suppose there is a rule: "A implies B". > > The negation of that rule is: "Not B implies Not A". > The negation of that rule is NOT: "Not A implies Not B". > > I believe your argument(s) falls into the "Not A implies Not B" category. > (I hope I'm mistaken there.) > > However, I am also having a little trouble following your actual meaning. > More below on my challenge with following what you are saying... > > >> >> My policy, for my network, is as defensible as many others. And that >> isn't peculiar to home networks. >> >>> - In such an environment, there are only, ever, "willing users", because, >>> in order to use the network, they are required to agree to the policies. >> >> Wrong. In my home network, my children and their friends have >> no real choice to not use the network until they are relatively >> economically independent. (And in earlier days, they could not >> have given informed consent in any case, being too young.) >> > > So, I am trying to understand. > Does their lack of real choice make them unwilling users? One could describe it that way. I'm sure many kids might do so;-) But it's not great terminology. > Are you arguing that they should be able to bypass whatever rules you have > for your children? Most of the "rules" are not enforced by computers, and hence don't need to be written down precisely. For example, I'd encourage them to not create accounts on web sites. But I don't try enforce that in any technical way and accept that sometimes they do end up creating web accounts. Talking to them about what they're doing and scaring 'em that I could snoop if I was bothered are often sufficient. > Do you want your children to be able to undetectably use a third party DNS > resolver, such as DoH, I don't care about that. > and access naughty networks No, I'd prefer they not. But I have no technical barriers in place to do such blocking. To the extent that there's a policy at all, it's defined and (not enforced) purely in the human realm. > or malware? Bad question IMO. But in any case, encouraging human behaviour that doesn't result in malware being executed is IMO more effective. (E.g. avoiding certain OSes etc.) > Or do you want to block that particular use case? > I think their category as "unwilling" is mooted by their being minors and > not being able to give informed consent. As I said neither willing nor unwilling are good descriptive terms for home network users. They are however quite different from employees in a corporate network (esp in a case like mine with a technically permissive policy) and that needs to be recognised. > > In any case, if you do want to give them (all of them or some of them) > access to such third party resolvers, should that not be something > explicitly under your control? I don't care about that. > And should it not be easy to do (where I roughly equate "easy to do" with > "scalable", for argument purposes). Ease of use is generally good. I think the challenge for e.g. browsers, will not reside in networks like mine. I do have some minor split-horizon issues but nothing that'd break badly for anyone but me and I know h
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
On 20/03/2019 03:17, Brian Dickson wrote:
> On Tue, Mar 19, 2019 at 6:42 PM Stephen Farrell
> wrote:
>
>>
>> Hiya,
>>
>> One individualistic data point on this sub-topic, and a real point:
>>
>> On 20/03/2019 01:13, Jared Mauch wrote:
>>> My impression is there are people who will not be satisfied until all
>> traffic looks
>>> identical and you have zero way to protect your home,
>>
>> I do not claim that everyone ought do the same, but I absolutely
>> do claim that encouraging voluntary policy adherence by dealing
>> with the people using the n/w is preferable to many egregiously
>> invasive attempts to force technical policy enforcement on
>> unwilling serf-like users.
>>
>
> So, this is the problem:
There's only one problem? Great! :-)
> - If a network operator has any policy that is enforceable, ONLY the
> technical policy enforcement model scales.
My mail was about my policy for my home network and explicitly said
that I do not claim that policy ought be followed by all home networks,
never mind other kinds of network. Your argument about scale is not
therefore relevant. (At least, not unless you want to give up all
argument along the lines of "consider the children.")
My policy, for my network, is as defensible as many others. And that
isn't peculiar to home networks.
> - In such an environment, there are only, ever, "willing users", because,
> in order to use the network, they are required to agree to the policies.
Wrong. In my home network, my children and their friends have
no real choice to not use the network until they are relatively
economically independent. (And in earlier days, they could not
have given informed consent in any case, being too young.)
In work environments what you say is also not completely correct,
at least in some EU locales, where employees retain rights of
various kinds whilst at work using an employer-provided n/w. We
don't need to argue the rights and wrongs of that, it just is.
> This makes the argument you have above, a vacuously defined one.
Surprising as it may be I disagree that my argument is vacuous:-)
> You want to encourage voluntary policy adherence for a non-existent set of
> otherwise unwilling users.
>
> I understand your position: you would prefer that {some,all} networks were
> not employing policies that {you,some people} disagree with.
Ah. You apparently don't understand my non-vacuous argument. I
guess that's better than the opposite:-)
Once more: my policy for my network is defensible but is not
one I claim ought be followed by everyone. And the same applies
for all of the more intrusive policies being espoused here by
those with concerns about DoH. That doesn't mean those concerns
are vacuous or otherwise to be ignored, but does mean that
claims as to such-and-such a policy being a necessity are not
valid. Only one counter-example is needed to demonstrate that,
and I've provided one (that is real, not invented).
S.
> I sympathize, but I disagree. What we need are mechanisms that scale.
> My position (personally) is that we find ways to have scalable, technical
> mechanisms.
> They should allow users (or machine administrators) to be as compliant as
> they are willing, and no more.
> They should allow networks to enforce their policies, while treading as
> lightly as possible.
> It should be possible to use technical means to handle this negotiation
> with little to no user input required.
> The analogy is roughly that of escalation-of-force in law enforcement,
> starting at a level of "polite requests".
>
> You can disagree, but I implore you: please don't stand in the way of those
> wanting to find consensus on scalable, flexible, technical solutions that
> encompass a wide range of network policies and enforcement needs.
>
> The main point is, I believe the end result will be mechanisms that allow
> you to deploy networks that meet your needs, and software that you can
> configure to bypass such controls, but that neither of those should ever be
> the default configurations.
>
> If the results allow you to do what you want/need, and also allow others to
> do what they want/need, everyone should be happy enough with the result.
>
> Can we at least agree on this as a desired goal for this work?
>
> Brian
>
>
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
Hiya, One individualistic data point on this sub-topic, and a real point: On 20/03/2019 01:13, Jared Mauch wrote: > My impression is there are people who will not be satisfied until all traffic > looks > identical and you have zero way to protect your home, I would be happier if my home emitted no cleartext and have no intention of MITMing any TLS in my home. And that leaves me with plenty of ways to protect my home network (and as an aside that is absolutely not the same as protecting my home at all - such overstatement still doesn't help the discussion). For example, I discourage use of certain OSes, products and services, and try help the people using the network to understand enough about what they're doing to be less than randomly unsafe. Of course I have some f/w rules and do some monitoring but I would never use a net-nanny type thing. I do not claim that everyone ought do the same, but I absolutely do claim that encouraging voluntary policy adherence by dealing with the people using the n/w is preferable to many egregiously invasive attempts to force technical policy enforcement on unwilling serf-like users. And to be clear (but repetitive, sorry;-) my general point is that my policy is not the only defensible one, just as yours is not, (even if you claim it is). And nor is Paul V's - "My network, my rules" can also mean a much more permissive technical enforcement regime than is often assumed when hearing such a forceful-sounding catchphrase. Not all policies need to be enforced technically. Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague
Hiya, On 14/03/2019 14:41, Ralf Weber wrote: > the DoH protocol caused some application providers to experiment with > switching resolution per default away from OS and the local network provider I wasn't aware that some application provider was doing this as their default (assuming that's what "per default" means). Can you provide details? I am aware of what FF/CF have done but I don't believe that was on by default. Thanks, S. PS: Apologies if there's a reference in one of the I-Ds, but I don't recall there being one for that assertion. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients
Hi, On 14/03/2019 00:07, Michael Sinatra wrote: > On 3/13/19 1:43 PM, Stephen Farrell wrote: >> >> (dropping dprive list at WG chair request) >> >> Hiya, >> >> On 13/03/2019 20:29, Brian Dickson wrote: >>> The starting place for the conversation needs to acknowledge this, and >>> accommodate it. It is entirely possible that a DoH client that doesn't do a >>> minimum level of getting user acknowledgement before violating policies, >>> laws, or contracts, might itself be illegal in some jurisdictions >>> (jurisdictions that could include some US states, some western countries, >>> some larger entities like EU, etc.). >> >> I almost agreed with you that people need to ack others' >> priorities. But the above means I can't agree with your >> mail as "might be illegal" is vastly overstated, there >> being no relevant difference between DoT and DoH clients >> in this respect. > > I believe that the issue of protocol obfuscation that I mentioned > earlier in the draft-reid-doh-operator thread[1] is a relevant difference. I do not believe that is relevant to the claim I was disputing which was essentially that somehow DoH "might be illegal." If you think your point above is relevant, please consider Tor, whose major funder is (or historically was) a government and which is not illegal as far as I know (in many places). And VPNs too (but only the good ones:-). > There is another technical issue, and that surrounds the question of who > is the user and what capabilities does the user have to manage their > devices. This has been touched upon with the discussion on opt-in vs. > default and with Paul's discussion of data exfiltration. > > In my home, I have an "Internet-capable" washing machine. Of course my > "smart" TV wants to be on the Internet. My Foobot *must* be on the > Internet just so I can monitor the air quality in my own home. I don't > want the washer on the Internet at all, and for some of the other > devices, I want to control what they do on my home network. With > embedded and "IoT" devices, there may be limitations on how I--as the > user--can control them. There may be hard-coded defaults that are > difficult to change (and yet have a way of easily resetting themselves > to "factory default"). Leaving aside for now the issue of licensing > Ts, I--as the user--may want to have more *technical* control over > the devices than their vendor is willing to give me. One way I can > assert that control is via the network. On my home network, I am one of > the users and I am also the network admin. I want to assert control > over the devices for which *I* am the user, but the people who designed > them didn't give them sufficient knobs for me to do this on the device. > > Another word for software which does things on the network outside of > the user's control is "malware," whether it is legitimate or not, and I > realize it predates DoH. But DoH legitimizes protocol obfuscation at > the network layer and makes it potentially harder for me to control the > devices for which I am the user. So if the goal is to give users more > control, I'd assert that DoH, at best, works both ways. Those seem like unrelated (and repetitive) points, except for your attempt to try equate (I assume) a browser using DoH with malware. That's the kind of overblown statement that detracts from any other reasonable points you may make (for me at least). I do agree that knowledgeable network owners, especially home network owners, ought be able to exercise control over the networks they own. I'm perfectly fine to do that in my home network and have no fear of DoH at all - I'm well used to turning off, working around or living with what I consider crappy features of browsers (e.g. cookies, JS) and other tech artefacts. DoH at least has some upsides if it gets implemented properly. I don't personally know how to properly and fairly handle such issues for network owners who quite reasonably don't know anything about the tech. ISTM that (to date) we've all contributed to failing such network owners. DoH is nothing special in that respect, nor is RPZ and nor are many other technologies we've developed. From my POV, the only thing I hear about DoH that's new(-ish) is a fear that browsers will turn it on by default in a silly manner, with some negative but not world-shattering consequences for folks who have a quite reasonable interest in existing DNS-based technologies and services. (Well, that and I've a continuing concern that somehow DoH might end up enabling web-severs succeed at drive-by attacks on client DNS caches if someone does some really stupid implementation stuff. But everyone keeps telling me that'll be ok;-)
Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients
On 13/03/2019 21:06, Brian Dickson wrote: > Things like DMCA and its ilk might raise the software to the > level of "illegal" rather than just a contract violation by a user. Whacking someone in the head with a fish could well be illegal... but fish are not illegal:-) [1] Similarly typing "dig .example" may be argued to cause some theoretical illegality in some locations but neither the DNS protocol nor service is illegal as a result. And IANAL. But it's ok that we disagree that this is overblown, except for the way in which it makes the conversation needlessly harder. Cheers, S. [1] https://en.wikipedia.org/wiki/The_Fish-Slapping_Dance 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients
(dropping dprive list at WG chair request) Hiya, On 13/03/2019 20:29, Brian Dickson wrote: > The starting place for the conversation needs to acknowledge this, and > accommodate it. It is entirely possible that a DoH client that doesn't do a > minimum level of getting user acknowledgement before violating policies, > laws, or contracts, might itself be illegal in some jurisdictions > (jurisdictions that could include some US states, some western countries, > some larger entities like EU, etc.). I almost agreed with you that people need to ack others' priorities. But the above means I can't agree with your mail as "might be illegal" is vastly overstated, there being no relevant difference between DoT and DoH clients in this respect. Such overstatement doesn't help and merely makes it more likely that some of the reasonable points you make will just get lost in the noise (IMO anyway). The same goes for talk of "wars" btw. Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients
Hiya, On 13/03/2019 01:04, Paul Wouters wrote: > RPZ allows filtering answers which would turn into BOGUS for > DNSSEC validating clients. Could well be my terminology was imprecise. What I recalled from some discussion a year or more ago was that RPZ MUST NOT change a DNSSEC-signed answer that verifies. If that's wrong or no longer the case then my point there is off base. (I'll go back and find another tomorrow:-) If I'm correct, then I remain puzzled as to why Paul V. finds it acceptable to be unable to "interfere" with DNS answers in one case (RPZ-with-good-DNSSEC) but not the other (DoH). Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients
Hiya, On 12/03/2019 22:51, Paul Vixie wrote: > On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote: >> On 12/03/2019 21:11, Paul Vixie wrote: >>> ... >> >> There are reasons to want confidentiality for DNS queries >> and answers, and access patterns, for which the IETF has >> achieved consensus. (See RFC7626) (*) > > i have no qualms about confidentiality, for traffic allowed by a network > operator. To me, the above reads as self-contradictory. If the traffic is confidential the operator doesn't know if its "allowed" except possibly in some extremely coarse-grained sense. Perhaps when you said "traffic allowed" maybe you meant "protocol allowed"? But even that is confusing, given the likes of websockets, alpn, and other webby ways in which stuff gets layered on 443 all the time. > it's the inability to interefere (as called for in RFC 8484) and not > the inability to observe (as called for in RFC 7626) that's at issue here. Hmm. Not sure what to make of that. DNSSEC presumably makes it possible to detect interference, and yet RPZ (IIRC) calls for not changing DNSSEC-signed answers. I don't get why an inability to change is ok for the RPZ/DNSSEC context but not for DoH. Another possibility is that we're discovering that when this confidentiality stuff gets used for real, we find that we'd really prefer to not have to change what we've been doing before. I don't mean that as an accusation but it has been easy to ignore e.g. the lack of deployment of DNSSEC or more recently, DoT. > >> DoT is one way to tackle those problems. DoH is another. > > DoT does not intend to place itself beyond interference by on-path entities, > and as such, my choice as a network operator is either to allow it through > even though i can't see the contents, or disallow it. and that's all fine. > > DoH intends "to prevent on-path interference with DNS operations", and that's > well beyond the remit of RFC 7626, and is therefore not spoken to one way or > another by IETF consensus. i do not believe that a non-interference objective > would reach broader IETF consensus. perhaps we can test that one day. Over the years, we've had quite a few people propose schemes to provide integrity (and presumably hence prevent "interference") but no confidentiality. (There's an ongoing discussion of the very latest iteration of that on the TLS list in the last month or so.) That leads me to guess that a position that "interference is ok but confidentiality is not a problem" is not one that'd tend to garner consensus. But as you say, maybe some day we'll test that proposition. Cheers, S. > > vixie > > > ___ > Doh mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/doh > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients
On 12/03/2019 21:11, Paul Vixie wrote: > he's trying to achieve a political aim using technology. Ok, now I think I understand and am pretty sure I disagree with you there. There are reasons to want confidentiality for DNS queries and answers, and access patterns, for which the IETF has achieved consensus. (See RFC7626) (*) DoT is one way to tackle those problems. DoH is another. I think an argument that DoH is "just politics" and is not aiming to try provided a security/privacy mechanism to tackle a problem on which the IETF has consensus falls on that basis myself. I fully agree that there are potential DoH deployments that could have side-effects (more that DoT) that warrant more discussion, but I figure your arguments along the above lines are misdirected. Cheers, S. (*) Ironically, one of the arguments against DoH raised in this discussion is that it would expose that kind of information from split-horizon deployments, so it seems that even those concerned about DoH accept the problem statement, which is helpful. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients
Paul, On 12/03/2019 20:51, Paul Vixie wrote: > just as i've cautioned the RFC 8484 authors against imposing their anti- > censorship views on my parental controls or corporate network policies, let > me > here caution you against imposing your (clearly) western liberal-democratic > views on the development of protocols whose ideal state is "interoperability" > and never more or less. I'm sorry but I don't understand this argument. DoH interoperates pretty well. You and Christian have expressed different concerns not related to interop. I don't see why, based on your argument, your concerns trump his. Can you explain? Thanks, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients
On 12/03/2019 01:54, nalini elkins wrote: > Stephen, > >> TLS1.3 will, I expect, noticeably improve security for an awful lot of >> enterprises in time. > > I am sure you are right. Great. > There is also likely to be quite a bit of pain > ahead for many. I don't agree at all about that, despite claims to the contrary from you and some others. But that topic was debated at length already. (Seriously, do you expect some other outcome if you re-start that debate?) > Also, > this is exactly why I propose a neutral observer who might tease out the > nuances. I think that's an outstandingly bad idea. The IETF has no voting and hence no electorate nor constituency and hence no identifiable non-voting population from whom ostensibly neutral observers could be chosen via some (currently non-existent) IETF process. In addition to be just being a bad idea, what you appear to be suggesting seems to me like it'd require fundamental change to the core of the IETF and to also be entirely off topic for the subject line of this mail. S. > Or > say something along the lines of "if you do x, you will need to do y". It > may also be > needed to have subtopics. And, the pro and con sides could also provide a > writeup. > The write up could also propose transition strategies. > > I am trying to make it so that people, including enterprises, can better > decide the merits of the > situation for themselves. > > Many people do not have the time, expertise or energy to follow these > discussions which > have gone on for a number of years. I have also seen assessments of > protocol changes from people > who have "a dog in the hunt" so to speak. That is, vendors who provide an > assessment which > (shockingly enough) results in their own products (which again shockingly, > cost money) being the best > solution. There is much hyperbole on all sides of not just the TLS1.3 > issue but DoH also. > > I compliment the authors of the current drafts on DoH deployment drafts for > good efforts to bring > light to this subject. > > Having said that, I would like to see IETF work with a neutral third party, > maybe an academic institution, > or CERT, or someone else help people, including enterprise operators, who > have to make decisions to > implement these protocols and possibly change their architecture > strategies. Even if we manage to > come to consensus on an IETF draft and create an RFC on DoH deployment, > many enterprises do not > keep up with all RFCs nor do they always have the time to evaluate > everything properly because they > are so busy with the fires of the current day. I worked for large > enterprises for many years doing network > design and troubleshooting. I was always extremely busy fighting the > issues of the day. > > Enterprises, and many others, do pay attention to what NIST or CERT says. > Just my 2 cents to try > to find a long term solution to what has been a contentious and exhausting > multi-year set of discussions > for all involved and which seems set to rekindle with DoH. > > Nalini > > On Tue, Mar 12, 2019 at 5:30 AM Stephen Farrell > wrote: > >> >> (This distribution list is too scattered and diverse. Be >> great if some AD or someone just picked one list for this. >> In the meantime...) >> >> On 11/03/2019 20:43, nalini elkins wrote: >>> impact assessment that certain changes such as >>> DoH and TLS1.3 will have on enterprises, >> >> TLS1.3 will, I expect, noticeably improve security for an awful >> lot of enterprises in time. >> >> As for DoH, I wonder has anyone done studies on how split-horizon >> names and access patterns leak today? >> >> I don't recall having read that kind of study. I can imagine >> many ways in which that kind of stuff would leak. I'd be very >> surprised if it never happens. I don't know how often it does. >> >> For names, leaking once is kinda fatal. For access patterns, >> I guess one leak exposes an IP address that's interested in a >> name (e.g. secret-project.example.com) but more would be >> needed for broader access patterns to be exposed to "foreign" >> recursives and/or in-band networks. >> >> ISTM that it is quite possible that enterprises that deploy their >> own DoH services could potentially reduce such leakage and gain >> overall. (I'm assuming here that sensible browser-makers will >> end up providing something that works for browsers running in >> networks with split-horizon setups before those browsers turn >> on DoH as a default at scale.) >> >> Cheers, >> S. >> > > > > ___ > dns-privacy mailing list > dns-priv...@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients
(This distribution list is too scattered and diverse. Be great if some AD or someone just picked one list for this. In the meantime...) On 11/03/2019 20:43, nalini elkins wrote: > impact assessment that certain changes such as > DoH and TLS1.3 will have on enterprises, TLS1.3 will, I expect, noticeably improve security for an awful lot of enterprises in time. As for DoH, I wonder has anyone done studies on how split-horizon names and access patterns leak today? I don't recall having read that kind of study. I can imagine many ways in which that kind of stuff would leak. I'd be very surprised if it never happens. I don't know how often it does. For names, leaking once is kinda fatal. For access patterns, I guess one leak exposes an IP address that's interested in a name (e.g. secret-project.example.com) but more would be needed for broader access patterns to be exposed to "foreign" recursives and/or in-band networks. ISTM that it is quite possible that enterprises that deploy their own DoH services could potentially reduce such leakage and gain overall. (I'm assuming here that sensible browser-makers will end up providing something that works for browsers running in networks with split-horizon setups before those browsers turn on DoH as a default at scale.) Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dbound] [art] Related Domains By DNS (RDBD) Draft
Hiya, On 28/02/2019 02:03, John Levine wrote: > Well, OK, if that's an issue you spread the names out like we did with > VBR. If the primary is foo.com and the secondary is bar.org: > > bar.org._same.foo.com. SAME . ; yes, we're a primary for whatever name that > was > > _same.bar.org. SAME foo.com. ; yes, we're secondary for foo.com. > > This makes it somewhat more difficult to scrape all the secondaries > for a primary which may be a feature. Yep, that could work. I still prefer the design in our -00 though (sorry:-) as in your scheme here foo.com's zone will have to change with every change in a linkage whereas in the -00 design, changes are only needed in each of the bar.org zones that actually do change. (I think the counter to that might relate to difficulty in synchronising changes to keys/selectors in our -00 design which can have unexpected effects as we saw in the case of DKIM and a particular mail corpus leak in 2016;-). To be clear: for my purposes I'd be ok with various of the designs we've been discussing - even if I think some are better than others, they're nearly equally ok. I think the main thing is to try keep it simple (as you've been doing) and to try find out if people might publish such values (absent which, there's no much point in publishing an RFC). Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] [dbound] Related Domains By DNS (RDBD) Draft
Answering two for the price of one... On 27/02/2019 17:26, John R. Levine wrote:>> new signatures), I myself only copped on that this could >> be of some use where the primary has DNSSEC but where the >> secondary doesn't, which is maybe interesting. > > In that case, the primary can just publish pointers to the secondaries, > and we're done. > > The DKIM-like signatures have an odd model where the primary has enough > control over its DNS to publish the validation key, and enough to give > the secondaries signed records for their names they can publish that > point back to that key, but not enough just to publish the secondaries' > names directly. I don't get it. That could work, but'd mean the primary having to store all the records and an extra lookup if even if you had the public key cached. I believe the former could be an issue if there are many secondaries, at least according to one chat I had with someone involved with many domains (which I'm not). I think the design in our -00 is a bit better than that, but not hugely better and it's ok we can disagree about it - if this goes somewhere there'll be plenty of time to thrash it out as we go. On 27/02/2019 18:38, Ted Lemon wrote: > On Feb 27, 2019, at 10:57 AM, Stephen Farrell > wrote: >> Yep. After both domains have DNSSEC, then this could all be >> simpler. Before they do, there may be value in the sigs though see >> John's simplification suggestion at [1]. > > If they don’t have DNSSEC, what’s the point of saying the domains > are related anyway? What are the security properties of such an > assertion when the content of the zones can’t be validated? The point of making the assertion would be in the eye of the beholder. The level of confidence one might have in such an assertion (without DNSSEC) should of course be lower. But we do work without DNSSEC for almost everything today so I'm not convinced "no DNSSEC" => can't be done here. (And again, the use-cases we've discussed are not high-security ones.) FWIW, I am a fan of DNSSEC, deploy it for domains I control, and do consider that despite it's gnarliness it provides real benefits. But I don't believe we can seriously require it as a pre-requisite for almost anything today, and nor do I believe that our proposal, if it goes ahead would by itself cause people to deploy DNSSEC. So ISTM that making DNSSEC a MUST-use isn't the right approach in this case. Cheers, S. > > > > ___ art mailing list > a...@ietf.org https://www.ietf.org/mailman/listinfo/art > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dbound] Related Domains By DNS (RDBD) Draft
Hiya, On 27/02/2019 15:54, Paul Wouters wrote: > How is this data being consumed by the enduser ? Very good question. Sorry for what's likely a longer answer than you want:-) Alex and I chatted about that and I think ended up figuring: a) there are many potential semantics that could be associated with such a linkage, b) we don't yet know what'd be useful, but c) no, we are defo not trying for an EV-like thing and lastly d) we really want to keep this as simple as possible - given there's a lot of feature-creep potential here, and that'd likely be fatal. My own use-case for this relates more to surveys, where I'd like to get a hint that two names are related so I could take that into account. Alex's is more business like (as you'd expect:-) he'd like to be able to feed this kind of linkage information into mail processing, e.g. perhaps to treat some mails as less-likely spam if he sees a link, compared to if he doesn't (with all the other mail processing foo that'd clearly be required to not do that kind of thing stupidly of course). We guess that there'd be other uses too but finding out if this is seen as useful enough that people would publish RR's is part of why we shot out the draft now. We also considered whether or not to e.g. try to add some kind of flag to indicate semantics but reckoned we don't know enough to do that for now. Cheers, S. > It sort of begins > to look like an EV thing. Also, wouldn't attackers just link their > fake domain to another fake domain to get a green looking OKAY? 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dbound] Related Domains By DNS (RDBD) Draft
Hi Paul, On 27/02/2019 15:48, Paul Wouters wrote: > On Wed, 27 Feb 2019, Paul Wouters wrote: > >>> https://datatracker.ietf.org/doc/draft-brotman-rdbd/ >> >> I've read the draft, and I have my usual complaints. Thanks for taking a read! > I scanned this document a bit too fast, with an eye on parent-child > relationships and didn't fully realise this is about relating domains > at different parts in the DNS hierarchy alltogether. And even more thanks for reading it twice! It is short, luckily:-) Great that you think it's uncrazy. > > So now I do understand the format and use better. I'm not sure if the > DNS is the best place for this information, but it is not the worst > place either. So in that sense this proposal seems fine. Yep. Actually in exchanges with John Levine on the dbound list, (he was v. reasonably questioning the value of these new signatures), I myself only copped on that this could be of some use where the primary has DNSSEC but where the secondary doesn't, which is maybe interesting. Those mails are here [1] if someone's interested. > I do still have a concern that this is using its own signature schemes > embedded in the records instead of relying on DNSSEC. But I guess > that's just the world we live in now. Yep. After both domains have DNSSEC, then this could all be simpler. Before they do, there may be value in the sigs though see John's simplification suggestion at [1]. Cheers, S. [1] https://mailarchive.ietf.org/arch/msg/dbound/PON1ipCbK_ea67fbyvhUzSfj5og > > Paul > > ___ > dbound mailing list > dbo...@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-edns-key-tag-04: (with COMMENT)
Hiya, On 16/02/17 21:43, Wessels, Duane wrote: > > Hi Stephen, > > >> >> -- >> >> COMMENT: >> -- >> >> >> >> - abstract: referring to section 1.1 from here seems wrong, >> the abstract ought be readable by itself > > Agreed. I propose to remove that sentence and let the abstract stand > on its own. > > >> >> - section 5: Is the key tag query only and solely intended to allow >> the authoritative to track how clients are paying attention (or >> not) to key rollovers? If there's another purpose I'm not clear >> about it. > > Yes, that is the sole purpose. Do you think this needs to be made > more explicit? Up to you. It wasn't clear to me at first, but was clear when I finished reading. > > >> >> - 5.3: "I believe that to be..." seems like the wrong language to >> use with >1 author. > > Yes. This sentence was already removed from the authors' shared > source file shortly after -04 was sent out. > >> >> - section 7/8: Is there a missing security/privacy consideration >> here, in that an authoritative server here could arrange to hand >> out key tags that are specific to (in the limit) each query, so >> that when the resolver queries a sub-domain, and thereafter, the >> client will be identifiable to the authoritative server? One could >> do this by generating new keys per querier so that if I ask about >> example.com I get given a tag that's unique to me, and then some >> web content pushes me to ask about www.example.com and every time I >> do that I emit that user-specific key tag. While that'd be unlikely >> for a large zone, it might be feasible as a tracker if some "bad" >> domain sets up a specific subdomain for such purposes. That said, >> I'm not clear how much better this is for the attacker compared to >> simply using a tracking name in the authority component of the URL >> for e.g. some 1x1 gif. > > One important aspect to clarify here is that resolver shouldn't be > transmitting the key tags for every query. They are only to be sent > with or at the same time as DNSKEY queries. > > 4.2 says that the edns-key-tag option MUST NOT be sent for non-DNSKEY > queries. > > 5.2 says the need to issue a DNSKEY query is also the trigger to > issue a key tag query. > > Additionally, the document says that resolvers SHOULD transmit the > key tags for zones with configured trust anchors and MAY do so for > non-trust anchor zones. For most resolvers only the root zone would > be configured as a trust anchor. > > Lastly, there is a practical limitation here in that each unique key > given out would require a corresponding unique DS record in the > parent zone. A malicious zone operator might be able to get away > with tens of unique keys, but probably not hundreds. The one > exception to this would be if the malicious actor operated both a > parent zone and a child zone. > > Given all that, do you think it warrants a paragraph in the privacy > section? Again, up to you. The issue is fairly borderline so I won't argue if you don't wanna. S. > > > DW > signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-edns-key-tag-04: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-edns-key-tag-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ -- COMMENT: -- - abstract: referring to section 1.1 from here seems wrong, the abstract ought be readable by itself - section 5: Is the key tag query only and solely intended to allow the authoritative to track how clients are paying attention (or not) to key rollovers? If there's another purpose I'm not clear about it. - 5.3: "I believe that to be..." seems like the wrong language to use with >1 author. - section 7/8: Is there a missing security/privacy consideration here, in that an authoritative server here could arrange to hand out key tags that are specific to (in the limit) each query, so that when the resolver queries a sub-domain, and thereafter, the client will be identifiable to the authoritative server? One could do this by generating new keys per querier so that if I ask about example.com I get given a tag that's unique to me, and then some web content pushes me to ask about www.example.com and every time I do that I emit that user-specific key tag. While that'd be unlikely for a large zone, it might be feasible as a tracker if some "bad" domain sets up a specific subdomain for such purposes. That said, I'm not clear how much better this is for the attacker compared to simply using a tracking name in the authority component of the URL for e.g. some 1x1 gif. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-dnssec-roadblock-avoidance-05: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-dnssec-roadblock-avoidance-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/ -- COMMENT: -- Thanks for adding alg 8 in response to my discuss. I think you might want to do another editing pass just to check that the end result is fully consistent, e.g. I'm not sure if alg 8 should also be mentioned in section 1.3. The diff from -04 to -05 might also contain a few other such things, but I'm in an airport now so better I clear the discuss and leave such tidying to you. --- OLD COMMENTs below, I didn't check 'em vs. the latest version general, mostly 3.x.y: it'd have been nice to include a dig command line for each of these tests - that'd save the non-expert reader some time and allow easy scripting of most of this BCP. general: Why not say to include a test with a known, but not well-known, public key (or DS) to check if anyone on the path is fibbing? E.g. a tester could remember a few public keys and check that they've not changed in a new location. While that may only catch out a cheating real parent, did you consider including such a test? - 3.1.4: How is a "recently defined type" a reasonable thing to check for in a BCP? Seems odd anyway. - 6.1: what if there is no user? Why not recommend telling some network observatory? Aren't there some for DNSSEC? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)
Hi Wes, On 05/08/16 22:18, Wes Hardaker wrote: > "Stephen Farrell" <stephen.farr...@cs.tcd.ie> writes: > >> Why omit sha256 (in particular Alg = 8) from this? That >> seems like a quite bad plan and *not* a BCP given our >> current knowledge of hash functions. > > I've changed the text to test for both. I think that's a good suggestion. Great thanks. Happy to clear when you post an update with that handled. The points below were non-blocking comments, so no need for us to bat 'em back and forth. (Your responses are reasonable, even if I might quibble a bit with 'em, but overall it's probably better to get your doc out.) Cheers, S. > >> general, mostly 3.x.y: it'd have been nice to include a >> dig command line for each of these tests - that'd save the >> non-expert reader some time and allow easy scripting of >> most of this BCP. > > I thought about that, but it would require significant explanation and > not all of the tests (I think) have behavior which is observable by > dig. Plus, dig is but one of many software tools and would seem to bias > the document toward ISC's version. > >> general: Why not say to include a test with a known, but >> not well-known, public key (or DS) to check if anyone on >> the path is fibbing? E.g. a tester could remember a few >> public keys and check that they've not changed in a new >> location. While that may only catch out a cheating real >> parent, did you consider including such a test? > > No, because that game is cat and mouse just like most other security > detection problems. There is no way to define a conclusive test that > can't be fooled by someone on the wire [for once the attacker learns > once, he'll know the second time to behave differently]. > >> - 3.1.4: How is a "recently defined type" a reasonable >> thing to check for in a BCP? Seems odd anyway. > > I'd think software implementations, as they rolled out, would update > their test to use the latest assigned type code. I had an equally hard > time with that question, but it does provide valuable input though it's > not easy to adequately describe. > >> - 6.1: what if there is no user? Why not recommend telling >> some network observatory? Aren't there some for DNSSEC? > > There aren't any. We do mention logging the results in section 6 though. > smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-dnssec-roadblock-avoidance-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/ -- DISCUSS: -- Why omit sha256 (in particular Alg = 8) from this? That seems like a quite bad plan and *not* a BCP given our current knowledge of hash functions. -- COMMENT: -- general, mostly 3.x.y: it'd have been nice to include a dig command line for each of these tests - that'd save the non-expert reader some time and allow easy scripting of most of this BCP. general: Why not say to include a test with a known, but not well-known, public key (or DS) to check if anyone on the path is fibbing? E.g. a tester could remember a few public keys and check that they've not changed in a new location. While that may only catch out a cheating real parent, did you consider including such a test? - 3.1.4: How is a "recently defined type" a reasonable thing to check for in a BCP? Seems odd anyway. - 6.1: what if there is no user? Why not recommend telling some network observatory? Aren't there some for DNSSEC? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's No Objection on draft-ietf-dnsop-edns-client-subnet-07: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-edns-client-subnet-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/ -- COMMENT: -- Thanks for handling my discuss point and the comments below (which I didn't check in detail, but am happy to chat about it you want). Cheers, S. - abstract: I think it'd be good if the abstract noted that this was documenting a deployed option and not necessarily recommending this as the best thing ever. There's text in the write-up and intro that does that nicely that could work if reduced to one sentence, e.g. maybe something like: "This documents an EDNS0 option that is in active use on the Internet today that is intended to be revised in the near future to improve it's security and privacy features." - Thanks for section 2. - 7.2.2 says "Because a client that did not use an ECS option might not be able to understand it, the server MUST NOT provide one in its response." That seems like a bit of a pity - one comment I was going to make was that it might be good to include this (or something) in a response so that a client that didn't ask for ECS could be informed that some DNS server is doing ECS. Would that actually break things? - section 10 has RFC1918 as a SHOULD but doesn't refer to e.g. RFC6598 at all. RFC6890 has a MAY associated with it, but does refer to 6598. And what about stuff like RFC7534, which isn't mentioned? Is that all correct and up to date? - 11.1, 4th para: "Users" isn't really right. People don't know about any of this stuff really. "Clients" would be more accurate ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-edns-client-subnet-06: (with DISCUSS and COMMENT)
Hi David, All of those changes look good to me. Happy to clear the discuss when you post -07. Cheers, S. On 25/02/16 01:12, Dave Lawrence wrote: > Stephen Farrell writes: >> Section 11.3, I like that we're recommending that ECS be >> disabled by default, but want to check one thing. This says: >> "Due to the high cache pressure introduced by ECS, the feature >> SHOULD be disabled in all default configurations." Does that >> mean that all servers SHOULD disable this by default or does >> this only apply to some servers? If the former, it should >> probably be (re-)stated somewhere early on and more prominently >> and not only stated far down in the document like this. If the >> latter, then I think you need to be more precise and I'd like to >> know why we're not preferring the more privacy friendly option >> as our default. So I hope your answer is "yeah, all servers and >> sure we can state that earlier as well" :-) > > In the draft that is pending its (presumably) final edits to make > version -07 to head to the RFC Editor, the last paragraph of the > Privacy Note (which is section 2), now says: > >We recommend that the feature be turned off by default in all >nameserver software, and that operators only enable it explicitly >in those circumstances where it provides a clear benefit for their >clients. We also encourage the deployment of means to allow users >to make use of the opt-out provided. Finally, we recommend that >others avoid techniques that may introduce additional metadata in >future work, as it may damage user trust. > > Does that adequately address your concern? > >> - abstract: I think it'd be good if the abstract noted that this >> was documenting a deployed option and not necessarily >> recommending this as the best thing ever. There's text in the >> write-up and intro that does that nicely that could work if >> reduced to one sentence, e.g. maybe something like: "This >> documents an EDNS0 option that is in active use on the Internet >> today that is intended to be revised in the near future to >> improve it's security and privacy features." > > How is this for the new abstract? > > This document describes an EDNS0 extension that is in active use > to carry information about the network that originated a DNS > query, and the network for which the subsequent response can be > cached. Since it has some known operational and privacy > shortcomings, a revision will be worked through the IETF for > improvement. > >> - 7.2.2 says "Because a client that did not use an ECS option >> might not be able to understand it, the server MUST NOT provide >> one in its response." That seems like a bit of a pity - one >> comment I was going to make was that it might be good to include >> this (or something) in a response so that a client that didn't >> ask for ECS could be informed that some DNS server is doing ECS. >> Would that actually break things? > > I don't think anyone has real experimental evidence on this. We do > see a lot of variation in the way that various DNS servers handle EDNS > in general, but I believe pretty much all of it has been with regard > to how servers handle EDNS anomalies in requests, and not with its > unexpected presence in responses. > > Given the lack of experience in this area I'd be reluctant to include > anything about it in this document, but will certainly consider > looking into it more for the revision. > >> - section 10 has RFC1918 as a SHOULD but doesn't refer to e.g. >> RFC6598 at all. RFC6890 has a MAY associated with it, but does >> refer to 6598. And what about stuff like RFC7534, which isn't >> mentioned? Is that all correct and up to date? > > I believe it is good as-is; we actually have known operational use > cases of allowing things like CGNAT through because a co-operating > resolver and authority have shared information about what the network > looks like. This is covered a little in the section on NAT > Considerations. If there's still something problematic I'd be happy > to address it. > >> - 11.1, 4th para: "Users" isn't really right. People don't know >> about any of this stuff really. "Clients" would be more accurate > > Rephrased from: > >Users who wish their full IP address to be hidden can include an >ECS option specifying the wildcard address (i.e. SOURCE >PREFIX-LENGTH of 0). > > to: > >Users who wish their full IP address to be hidden need to configure >their client software, if possible, to include an ECS option >specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of 0). > > Good? > smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-edns-chain-query-06: (with COMMENT)
On 18/02/16 14:43, Paul Wouters wrote: > > I believe that resolves the "promises" in Section 3. Thanks, those additions are good, Cheers, S. smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-edns-chain-query-06: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-edns-chain-query-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ -- COMMENT: -- - In section 3 you promised me privacy considerations in section 8 but I didn't find any there. That was almost a DISCUSS, but since fixing it is easy and I assume won't be controversial I can stick with a YES ballot:-) - I would suggest that you do note in section 8, that the fqdn in the CHAIN option could allow an attacker to (re-)identify a client. E.g. if the attacker sees that you have validated tetbed.ie before that could single you out, even if you have changed your n/w, cilent IP address etc. Presumably that would be a relatively long lasting concern as well, as RRSIG expiry tends to be weeks ahead. I think just noting that and maybe saying that DPRIVE is a likely mitigation would be a good thing to do. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Stephen Farrell's No Objection on draft-ietf-dnsop-cookies-09: (with COMMENT)
Hi Don, On 20/01/16 15:20, Donald Eastlake wrote: > Hi Stephen, > > On Wed, Jan 20, 2016 at 7:10 AM, Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-dnsop-cookies-09: No Objection >> >> ... >> >> -- >> COMMENT: >> -- >> >> - section 3: I think it'd have been good to mention the work >> being done in dprive as another future protection that should be >> compatible with DNS cookies. > > Section 3 is intended to talk about existing standardized DNS security > facilities. So I think it might be better in Section 9. How about: > > "Work is underway in the IETF DPRIVE working grop to provide > confidentiality for DNS requests and responses which would be > compatible with DNS cookies." Lovely. > >> - I agree with Alissa's comment (2) > > See response there. > >> - section 9: I think you should note that (particularly >> cleartext) client cookies allow correlation of client requests >> for the duration of the client cookie lifetime, which may affect >> other things the client does to try to avoid correlation and >> that the set of lifetimes of all of those kinds of thing are >> really interdependent. So e.g. if a client changes it's source >> IP for privacy reasons, that may be defeated if the same client >> cookie is still being used for DNS requests. > > See below. > >> - Thanks for handling the secdir review. That seems to have >> ended up [1] with client cookie values that are quite similar >> when only one bit of the server IP varies. Yet, [FNV] says that >> it has "high dispersion." I don't know FNV well enough to know >> if what Yoav called the "disturbingly similar" values in [1] >> might allow for guessing cookie values if one has ever seen a >> cookie value or not, but I'd be interested in chatting about >> that. (In a non-blocking sense:-) In general, I'd prefer if you >> recommended HMAC-SHA256 rather than FNV myself - why isn't that >> really a better thing to put in the appendices? (Yeah, >> performance, I know, but is the delta between FNV and >> HMAC-SHA256 really so significant these days, compared to the >> time it takes to lookup the DNS data itself?) >> >>[1] >> https://www.ietf.org/mail-archive/web/secdir/current/msg06268.html > > The draft has been changed in version -09 to reverse the order of the > inputs to FNV and include a statement that the older order is weaker. > Indeed, in the earlier draft an attacker with a similar IP address > (differs in only a few low order bits) to their target could send some > requests to the server and, based on the Server Cookie the attacker > got back for themselves and the bits that differ between the > attacker's and target's IP addresses could probably guess the target's > Server Cookie with relatively few tries. However, with the reversed > order of inputs, the changes will cascade and I believe this problem > is eliminated. Ah, good thanks. > > The Client Cookie calculation occurs in the client, which might be > feeble. The lookup of the DNS data itself occurs in the server, which > is likely to be more powerful. Sure, but nonetheless the overall hash cpu consumption is not, I would think, the most interesting place to optimise. I do get that FNV has folks who argue for it too though. > >> - Can't an access point/router that was once on path but is no >> longer abuse the client cookie (that it once saw go by) when >> that client is still using the same value later to talk to the >> same server via another n/w path? Is that worth a mention in >> the security considerations? What'd be the effect? I wondered >> why you didn't include e.g. the client IP in the input in >> Appendix A.1 to avoid this issue? > > We really didn't think about the client changing its IP address. Seems > like some clients will very rarely change their IP address while > others might change fairly often for privacy or mobile roaming > reasons. I have no problem adding the client IP to the inputs to the > Client Cookie. Since the client is the only thing that needs to > recognize its own cookies, any existing implementations will continue > to work and will not be affected by a changed recommendation for > calculating Client Cookies. Grand. > > The possibility of using the Client Cookie for tracking is also a good > point that should be mentioned in the Security Considerations. Great. The issue that con
[DNSOP] Stephen Farrell's No Objection on draft-ietf-dnsop-cookies-09: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-cookies-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/ -- COMMENT: -- - section 3: I think it'd have been good to mention the work being done in dprive as another future protection that should be compatible with DNS cookies. - I agree with Alissa's comment (2) - section 9: I think you should note that (particularly cleartext) client cookies allow correlation of client requests for the duration of the client cookie lifetime, which may affect other things the client does to try to avoid correlation and that the set of lifetimes of all of those kinds of thing are really interdependent. So e.g. if a client changes it's source IP for privacy reasons, that may be defeated if the same client cookie is still being used for DNS requests. - Thanks for handling the secdir review. That seems to have ended up [1] with client cookie values that are quite similar when only one bit of the server IP varies. Yet, [FNV] says that it has "high dispersion." I don't know FNV well enough to know if what Yoav called the "disturbingly similar" values in [1] might allow for guessing cookie values if one has ever seen a cookie value or not, but I'd be interested in chatting about that. (In a non-blocking sense:-) In general, I'd prefer if you recommended HMAC-SHA256 rather than FNV myself - why isn't that really a better thing to put in the appendices? (Yeah, performance, I know, but is the delta between FNV and HMAC-SHA256 really so significant these days, compared to the time it takes to lookup the DNS data itself?) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06268.html - Can't an access point/router that was once on path but is no longer abuse the client cookie (that it once saw go by) when that client is still using the same value later to talk to the same server via another n/w path? Is that worth a mention in the security considerations? What'd be the effect? I wondered why you didn't include e.g. the client IP in the input in Appendix A.1 to avoid this issue? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-edns-client-subnet-06: (with DISCUSS and COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-edns-client-subnet-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/ -- DISCUSS: -- Section 11.3, I like that we're recommending that ECS be disabled by default, but want to check one thing. This says: "Due to the high cache pressure introduced by ECS, the feature SHOULD be disabled in all default configurations." Does that mean that all servers SHOULD disable this by default or does this only apply to some servers? If the former, it should probably be (re-)stated somewhere early on and more prominently and not only stated far down in the document like this. If the latter, then I think you need to be more precise and I'd like to know why we're not preferring the more privacy friendly option as our default. So I hope your answer is "yeah, all servers and sure we can state that earlier as well" :-) -- COMMENT: -- - abstract: I think it'd be good if the abstract noted that this was documenting a deployed option and not necessarily recommending this as the best thing ever. There's text in the write-up and intro that does that nicely that could work if reduced to one sentence, e.g. maybe something like: "This documents an EDNS0 option that is in active use on the Internet today that is intended to be revised in the near future to improve it's security and privacy features." - Thanks for section 2. - 7.2.2 says "Because a client that did not use an ECS option might not be able to understand it, the server MUST NOT provide one in its response." That seems like a bit of a pity - one comment I was going to make was that it might be good to include this (or something) in a response so that a client that didn't ask for ECS could be informed that some DNS server is doing ECS. Would that actually break things? - section 10 has RFC1918 as a SHOULD but doesn't refer to e.g. RFC6598 at all. RFC6890 has a MAY associated with it, but does refer to 6598. And what about stuff like RFC7534, which isn't mentioned? Is that all correct and up to date? - 11.1, 4th para: "Users" isn't really right. People don't know about any of this stuff really. "Clients" would be more accurate ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-edns-tcp-keepalive-05: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-edns-tcp-keepalive-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ -- COMMENT: -- This used be a discuss but since the answer is probably that no change is needed, Joel said he'd figure it out with the WG. Before I ballot yes on this I have a question to ask. Most likely the answer will be the obvious one and we'll be done, but I want to check and if the answer is not the obvious one then holding the discuss as we fix stuff would be correct I think. The question: how does this option play with DNS over DTLS? [1] The reason I ask is that there may be a need in that case for some similar option (or a TLS extension maybe) though for the DTLS session lifetime and not a TCP session lifetime. At present you are saying that this option is not it. And that's a fine answer but you could also have said that this could also be used for DTLS session lifetime handling. And that last might make sense for operational reasons (not sure really, but could be). [1] https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03 old comments - intro: "However, TCP transport as currently deployed has expensive setup overhead." That seems a bit wrong as the 3-way h/s is an inherent part of TCP and isn't really specific to DNS with TCP trasnport not is it a deployment issue. I'd suggest just delete the sentence and merge the remaining part of tha para with the next. - 3.3.2: What's the last sentence of this section about? A case where a TCP session is handed over? Might be no harm saying why (via a reference to anything would be fine) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-5966bis-05: (with DISCUSS)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-5966bis-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/ -- DISCUSS: -- Don't we need text warning that TFO is likely problematic with DNS privacy and that attacks that try to prepend information (via TFO) to otherwise secured sessions could occur? While that might sound a bit far-fetched we have seen exactly that kind of issue with HTTPS that had practical impact on Webdav. (The TLS renego and then triple handshake attacks.) So while using TFO may not enable a slam-dunk CVE level 10 attack, I think you do need to consider and talk about it. (Or maybe you did and figured out no attack can work, but then I'd guess you'd be so happy, you'd say that too:-) I'm not sure how this'd best be resolved, but one thing might be to talk to the folks thinking about TCPINC as they have at least hit this as a potential issue for tcpcrypt and for tcp-use-tls. Otherwise, this is a fine document on which I'll ballot yes when the above is sorted. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-edns-tcp-keepalive-05: (with DISCUSS and COMMENT)
Hiya, On 06/01/16 21:49, sara wrote: > >> On 6 Jan 2016, at 20:57, Stephen Farrell >> <stephen.farr...@cs.tcd.ie> wrote: >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-dnsop-edns-tcp-keepalive-05: Discuss >> >> -- >> >> DISCUSS: >> -- >> >> >> >> Before I ballot yes on this I have a question to ask. >> Most likely the answer will be the obvious one and we'll be done, >> but I want to check and if the answer is not the obvious one then >> holding the discuss as we fix stuff would be correct I think. >> >> The question: how does this option play with DNS over DTLS? [1] >> >> The reason I ask is that there may be a need in that case for some >> similar option (or a TLS extension maybe) though for the DTLS >> session lifetime and not a TCP session lifetime. At present you are >> saying that this option is not it. And that's a fine answer but you >> could also have said that this could also be used for DTLS session >> lifetime handling. And that last might make sense for operational >> reasons (not sure really, but could be). >> >> [1] https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03 >> <https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03> > > Speaking for myself I don’t see this as the solution to managing DTLS > sessions, I think that would be better handled with a TLS extension. Yes, that's the obvious answer, and a not bad answer. Did the dnsop WG (or dprive) consider the issue already? If yes, then I'll just clear and we're done. If not, I'm fine with being guided by the chairs and AD since linking these would be a bit odd (even if possibly useful), so will clear when one of 'em tells me. > > >> >> -- >> >> COMMENT: >> -- >> >> >> >> - intro: "However, TCP transport as currently deployed has >> expensive setup overhead." That seems a bit wrong as the 3-way h/s >> is an inherent part of TCP and isn't really specific to DNS with >> TCP trasnport not is it a deployment issue. I'd suggest just delete >> the sentence and merge the remaining part of tha para with the >> next. > > I think the implication here is “expensive setup overhead compared to > using UDP for DNS”, with the following paragraph going into the > details of that comparison. I would like to keep the sentence, but > suggest adding that proviso at the end to make it clearer. That's fine. > >> >> - 3.3.2: Oops:-) Typo there sorry, the one that puzzled me is at the end of 3.2.2 where it says " This holds true even if a previous edns-keepalive-option exchange occurred on the existing TCP connection." Sorry again:-) Cheers, S >> What's the last sentence of this section about? A case >> where a TCP session is handed over? Might be no harm saying why >> (via a reference to anything would be fine) > > Last sentence in 3.3.2 is: “The DNS server SHOULD send a > edns-tcp-keepalive option with a timeout of 0 if it deems its local > resources are too low to service more TCP keepalive sessions, or if > it wants clients to close currently open connections.” > > There is more discussion in section 3.4 including: > > “Based on TCP session resources servers may signal a TIMEOUT value > of 0 to request clients to close connections as soon as possible. > This is useful when server resources become very low or a denial-of- > service attack is detected and further maximises the shifting of > TIME_WAIT state to well-behaved clients.” > > So would it help to add “as discussed in the next section” to the end > of section 3.3.2? > > Regards > > Sara. > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-edns-tcp-keepalive-05: (with DISCUSS and COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-edns-tcp-keepalive-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ -- DISCUSS: -- Before I ballot yes on this I have a question to ask. Most likely the answer will be the obvious one and we'll be done, but I want to check and if the answer is not the obvious one then holding the discuss as we fix stuff would be correct I think. The question: how does this option play with DNS over DTLS? [1] The reason I ask is that there may be a need in that case for some similar option (or a TLS extension maybe) though for the DTLS session lifetime and not a TCP session lifetime. At present you are saying that this option is not it. And that's a fine answer but you could also have said that this could also be used for DTLS session lifetime handling. And that last might make sense for operational reasons (not sure really, but could be). [1] https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03 -- COMMENT: -- - intro: "However, TCP transport as currently deployed has expensive setup overhead." That seems a bit wrong as the 3-way h/s is an inherent part of TCP and isn't really specific to DNS with TCP trasnport not is it a deployment issue. I'd suggest just delete the sentence and merge the remaining part of tha para with the next. - 3.3.2: What's the last sentence of this section about? A case where a TCP session is handed over? Might be no harm saying why (via a reference to anything would be fine) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-qname-minimisation-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/ -- COMMENT: -- Thanks - this looks like it's really really well worked out. I like the basic idea of course, but the execution here is very well done. The secdir review noted some nits you might want to fix at auth-48. [1] [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06230.html ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: Re: [saag] code points for brainpool curves for DNSSEC
FYI. Please continue to follow up on the saag list for now so the discussion (if more is needed) is in one place. (And thanks for doing that so far.) S. Forwarded Message Subject: Re: [saag] [DNSOP] code points for brainpool curves for DNSSEC Date: Thu, 10 Dec 2015 09:39:17 + From: Stephen Farrell <stephen.farr...@cs.tcd.ie> To: s...@ietf.org Thanks all, that's sufficient feedback for me to propose to the IESG that we return a "potentially disrupts, so please do not publish now" 5742 response so I have proposed that to the IESG. Additional discussion of reasons to not do this allocation now may therefore be redundant. Discussion of what to do in future is still welcome, and if that doesn't happen I at least will raise the issue on the list for the in-formation curdle WG. [1] The text I've proposed is at [2], feel free to suggest edits, but that can be done offlist. Cheers, S. [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ [2] https://datatracker.ietf.org/doc/conflict-review-schmidt-brainpool-dnssec/ On 10/12/15 09:15, Patrik Fältström wrote: > I have nothing to add to what Ãlafur wrote below. I agree with his statement. > >Patrik > > On 10 Dec 2015, at 1:33, Ãlafur Guðmundsson wrote: > >> Stephen, >> >> Sorry for being so blunt below. >> >> The document totally content free as to why this makes any sense in an >> operational context. >> DNSSEC algorithms should not be given out lightly as there is a significant >> COST to deploy support for each additional algorithm. >> >> While I strongly support having better ECC algorithm that the currently >> specified curves, adding a new ones SHOULD take place via a performance >> oriented process. >> Thus I strongly advocate that this publication be held up until we can >> compare this curve with other curves being proposed. >> >> Background I'm currently fighting an multifaceted battle to have various >> entities adding support for ECDSAP256, specified over 3 years ago. >> >> Adding and deploying a new DNSKEY algorithm does not just require changes to >> -- DNS servers, libraries and resolvers. >> >> That is just the top of the iceberg, but also to >> - DNS provisioning systems, DNSSEC signing systems, DNS testing tools, - >> user interfaces for registrars, hosting providers, third party DNS >> operators, CDN's, etc. >> - TLD and ccTLD policy documents, EPP implementations, plus in some cases >> security evaluations, >> - not to mention firewalls, network monitoring tools >> and number of other things I had no idea existed and majority of which is >> not maintained anymore. >> >> There are only so many times that one can get everyone's attention to >> upgrade DNS stuff, thus requiring the change process to be run should not be >> taken lightly. >> If on the other hand if the editors are only interested in vanity algorithm >> assignment without any deployment then ... >> >> Olafur >> >> >> On Wed, Dec 9, 2015 at 4:00 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> >> wrote: >> >>> >>> >>> >>> Forwarded Message >>> Subject: code points for brainpool curves for DNSSEC >>> Date: Wed, 9 Dec 2015 18:00:18 + >>> From: Stephen Farrell <stephen.farr...@cs.tcd.ie> >>> To: s...@ietf.org >>> >>> >>> Hiya, >>> >>> The brainpool folks have written an I-D [1] that they are pushing >>> through the rfc editor's independent stream. [2] >>> >>> That I-D wants to register code points for using their curves for >>> DNSSEC. >>> >>> For documents that come through the independent stream, the IESG >>> does an RFC 5742 [3] conflict review. The purpose of that review >>> is to check that the RFC doesn't conflict with ongoing work in >>> the IETF. >>> >>> If you have thoughts on this, please let me know before Dec 17th. >>> I'll forward this to the dnsop, cfrg and curdle mailing lists >>> to check there too. Apologies if you get >1 copy of this. Please >>> try follow up on the saag list if you can. >>> >>> Thanks, >>> Stephen. >>> >>> >>> [1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec >>> [2] https://www.rfc-editor.org/pubprocess/ >>> [3] https://tools.ietf.org/html/rfc5742 >>> >>> >>> >>> ___ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop ___ saag mailing list s...@ietf.org https://www.ietf.org/mailman/listinfo/saag signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: code points for brainpool curves for DNSSEC
Forwarded Message Subject: code points for brainpool curves for DNSSEC Date: Wed, 9 Dec 2015 18:00:18 + From: Stephen Farrell <stephen.farr...@cs.tcd.ie> To: s...@ietf.org Hiya, The brainpool folks have written an I-D [1] that they are pushing through the rfc editor's independent stream. [2] That I-D wants to register code points for using their curves for DNSSEC. For documents that come through the independent stream, the IESG does an RFC 5742 [3] conflict review. The purpose of that review is to check that the RFC doesn't conflict with ongoing work in the IETF. If you have thoughts on this, please let me know before Dec 17th. I'll forward this to the dnsop, cfrg and curdle mailing lists to check there too. Apologies if you get >1 copy of this. Please try follow up on the saag list if you can. Thanks, Stephen. [1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec [2] https://www.rfc-editor.org/pubprocess/ [3] https://tools.ietf.org/html/rfc5742 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-root-loopback-04: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-root-loopback-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/ -- COMMENT: -- Thanks for documenting this. I may try it:-) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-dns-terminology-04: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-dns-terminology-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-terminology/ -- COMMENT: -- Thanks for this. Is a domain a sub-domain of itself? Do we care? The definition of Alias might imply that we do. Not sure. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-onion-tld-00: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-onion-tld-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ -- COMMENT: -- (6 pages, so I read it now:-) We definitely need to approve this. It's been too long in the process already and that's been our (the IETF's) fault. (I won't object to us trying to improve 6761 after we've done this one, so some of the long debate will have lasting utility.) I thought I saw some edits from the last call that were agreed to be applied and that would improve the document. In particular, one that was to the effect that .onion names would in future need to conform to DNS name syntactic constraints (lengths basically) so that if a node did send a DNS query containing a .onion name, that'd be less likely to cause weird issues. Section 2 is a little sloppy in how it talks about .onion addresses (point 1), .onion names (which is the right term I think) and queries for .onion (I think you mean any query for any .onion name and not only for the TLD #4 and #5). A bit more consistency would be no harm, though it's clear enough as is. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-dnsop-onion-tld-00: (with COMMENT)
Hiya, I'm pretty sure I'll be a yes ballot on this (after I re-read the draft which I've not read for quite a while). And I don't expect either of us to change our ballot, but that said, I hope you don't mind explaining your ballot a little more since I'm not getting part of your argument and that part could be relevant if/when other special use name drafts are processed. (Or if/when someone tries to win the race and first improve IETF handling of special-use names.) On 21/08/15 19:37, Barry Leiba wrote: -- COMMENT: -- I believe the IETF shouldn't be involved with registering special-use TLDs for things that have been squatted on, and thus helping to circumvent ICANN's normal process. The above confuses me. Do ICANN have any process for allocating special-use names that will not be used in the DNS? I am not aware of such but it may exist. I am also not at all clear that I'd accept that ICANN ought be in that particular business. Note: I am not saying what I think of, not asking what you think of, ICANNs new gTLD programme, but for the sake of this discussion, let's assume that programme is normal;-) But that process is surely not one that could be used for special-use names that are required by protocols that require not using those names in DNS queries. Secondly, I don't get what you are saying you think about current IETF consensus (i.e. RFC 6761). Are you saying that: a) you don't agree with 6761? or b) that 6761 is fine but only for not-yet-deployed special-use names? If (a) I'm not sure that's our (IESG) role, and (b) seems highly unlikely to be workable (if one assumes an I-D has to wend its way through the process the special-use name will be deployed before IESG evaluation). So maybe you mean something else? I know there are a bunch of other such TLDs that people/organizations would have us snag for them, and I very much want to avoid that nasty iceberg, of which this is the tip. That's why I'm asking my questions above - I do think there's more work to be done here amounting to some combination of improving 6761 and figuring out how to properly handle the other queued-up strings. In passing I have to say that I don't agree there's been nasty snaggy squatting on the tip of any iceberg, (sounds painful that:-) And in a pot-calls-kettle-black moment, I'm not sure that kind of language is guaranteed to help us resolve what is a tricky issue in a very tricky environment. But I guess crossing the streams of an anonymity overlay and DN$ was never going to end up very pretty;-) That said, I well understand the deployed code involved and the importance of keeping things working in this case, and I don't want to stand in the way. So I'm standing aside with an Abstain ballot. Given what I think is your position, abstaining seems like the right action to take. I think you are quite correct that standing in the way here would have bad consequences. S. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-negative-trust-anchors-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/ -- COMMENT: -- In an ideal world, my YES ballot for would really be YES, sadly I suppose we need this kind of thing but wouldn't life be much better if DNSSEC was much easier to deploy, ah well, too late now I guess:-( - section 1.1: Where is the definition? I see you telling me what an NTA isn't, but not what it is. I think what you want to say is that an NTA is a domain name or a pair (a domain name and a sub-domain of that) represented in a resolver implementation-specific manner so that DNSSEC validation is turned off from the higher domain name down (to the subdomain if we have a pair). Is that right? - 1.1: RFC5914 is a little misleading as a reference as that was done for X.509 stuff and is nothing to do with DNSSEC. Maybe it'd be worth pointing that out just in case some reader somewhere goes and gets confused. - section 2: what do you mean happens once per quarter? - section 2: immediately restores - well that depends on the screw-up doesn't it? Or are you saying (where?) that an NTA must only be put in place when the screw-up is specifically and only about and because of DNSSEC and where ignoring DNSSEC will result in things working? For example, DNSSEC could fail because all my nameservers are entirely offline due to a f/w mis-configuration that blocks loads of port 53, but putting in place an NTA won't help then. (As it happens, I'm right now gettting a f/w to re-unblock 53 so I can serve some DNSSEC records so this issue is one that's close to the bone for me:-) - Section 6: 1st 2 sentences repeat repeat dnssec-failed.org too too many times. - random question: why not have an I'm just testing RR that I could put in alongside my ZSK DNSKEY as I start to play with DNSSEC? Or maybe that exists already. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Stephen Farrell's No Objection on draft-ietf-dnsop-dnssec-key-timing-06: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-dnssec-key-timing-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/ -- COMMENT: -- I wish I'd had time to read this properly and ballot yes, but I didn't, sorry;-) This is however good and useful work. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] Qname minimization IPR
On 25/10/14 15:56, Ted Lemon wrote: And also if anyone from Verisign is participating, they are required to disclose, Well, only if they think that the IPR is relevant. Their claims (I've not read 'em) could after all be unrelated to the draft, e.g. if they've only claimed some madly complicated way of getting the same effect as just leaving stuff out (which no doubt the USPTO might still, in their infinite wisdom, consider patentable;-). S. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC
On 04/10/10 15:37, Martin Rex wrote: One thing that needs to be addressed/solved is the key/cert rollover for any TLS-Server, so that it is possible to list more than one server cert as valid for a Server through DNS, at least for the time of the transition/rollover. Maybe a side-issue here, but this came up in the W3C WSC work and I wrote up an idea for that (not based on DNS) which is RFC 5697. [1] No idea if anyone is using or would use it, though I did have a student implement it, so it *could* work. (Note: that's an experimental-track RFC, as it ought be:-) S. [1] http://tools.ietf.org/html/rfc5697 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
