Re: [DNSOP] [Int-area] Please review draft-ietf-dnsop-avoid-fragmentation

On Tue, Aug 16, 2022 at 01:07:34PM +0900, Kazunori Fujiwara wrote: > Thanks very much for your review. > > > From: "to...@strayalpha.com" > > Some comments: > > > > The doc starts by grouping ICMP-based path MTU discovery (PMTUD) with > > in-band discovery (PLPMTUD), but asserts (in the > >

Re: [DNSOP] [Int-area] Please review draft-ietf-dnsop-avoid-fragmentation

Thanks very much for your review. > From: "to...@strayalpha.com" > Some comments: > > The doc starts by grouping ICMP-based path MTU discovery (PMTUD) with in-band > discovery (PLPMTUD), but asserts (in the > first paragraph) that the group term “path MTU discovery” isn’t deployed due > to

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

It appears that Paul Vixie said: >+1. noting, there should be a registry of second level domain style >names, maintained by IANA, with an RFC for each one describing what >protocol (whether Internet or otherwise) is used for names in that >"sub-tree", and references to permalinks where the

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

It appears that Paul Wouters said: >>> Meanwhile, IANA will have to host 60M entries in the .alt registry. >> >> that would be a success disaster, and self limiting. to get traction, a new >> non-tcp/53 non-udp/53 would have to publish plugins for a lot of browsers >and get uptake by libcurl

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On Aug 15, 2022, at 16:48, Paul Vixie wrote: > >  > >> Meanwhile, IANA will have to host 60M entries in the .alt registry. > > that would be a success disaster, and self limiting. to get traction, a new > non-tcp/53 non-udp/53 would have to publish plugins for a lot of browsers and > get

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

Paul Wouters writes: > I drop my objection to changing SHA1 status :) I win I win! -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

I have a question which doesn't need answering, but I have it anyway. Nobody intends re-using the code points, right? So the deprecation is about BCP, not about conformance to protocol? It's just the DNS police telling people to move along? Some days, I think that kind of thing might be better

Re: [DNSOP] draft-hardaker-dnsop-must-not-sha1

On Sat, Aug 13, 2022 at 10:48:59PM +1000, Mark Andrews wrote: > So you are ready to replace SHA1 in NSEC3 and do a second algorithm > renumber which is what is required to actually get rid of SHA1 or do > you mean retire RSA-SHA1. No. Please let's NOT deprecate SHA-1 in NSEC3. The use of

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On 8/15/22 17:27, Peter Thomassen wrote: OTOH, if we don't give guidance, people (not GNS specifically) will just continue camping on more ASCII TLDs for non-DNS uses. That's the exact thing we are aiming to avoid. Correction: I meant "letter-only TLDs", not ASCII TLDs. (Of course, an

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Hi Martin, On 8/15/22 14:49, Schanzenbach, Martin wrote: I do not agree that the registration policy should allow multiple entries for the same subdomain or be "free for all" as it is currently in the draft. ...> So, from my authors hat, I would appreciate FCFS That's a good point, and I

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On Aug 15, 2022, at 1:22 PM, Paul Wouters wrote: > I guess we could prevent draft--alt-name-cocacola if we consult the Trademark > Clearing House, https://tmsearch.uspto.gov/bin/showfield?f=doc=4806:y9m1tz.2.21 :) > but maybe

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Paul Wouters wrote on 2022-08-15 13:22: Schanzenbach, Martin wrote on 2022-08-15 11:49:  ...  So, from my authors hat, I would appreciate FCFS; ideally also existing  RFC/Other Specification + Implementation(s) for a registration in the  registry. "existing RFC" means all alternative name

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On 15.08.22 22:22, Paul Wouters wrote: Schanzenbach, Martin wrote on 2022-08-15 11:49:  ...  So, from my authors hat, I would appreciate FCFS; ideally also existing  RFC/Other Specification + Implementation(s) for a registration in the  registry. "existing RFC" means all alternative name

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Schanzenbach, Martin wrote on 2022-08-15 11:49: ... So, from my authors hat, I would appreciate FCFS; ideally also existing RFC/Other Specification + Implementation(s) for a registration in the registry. "existing RFC" means all alternative name resolutions have to flow through either the

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

On Mon, 15 Aug 2022, Viktor Dukhovni wrote: Presently, out of 18,975,098 working signed delegations: * 136,295 zones use RSASHA1-NSEC3-SHA1 (7). * 21,254 zones use RSASHA1 (5). So the number of eTLD+1 zones that rely on SHA-1 RRSIGs is a fairly stable ~0.8%, and a stronger nudge would

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

On Mon, Aug 15, 2022 at 09:29:28AM -0400, Paul Wouters wrote: > I think our decision should be based on the deplyment statistics of SHA1 > based zones and keys. I'd love to see the trending statistics from > Viktor to guide us here. Last time we looked it was still in the order > of 40% or so ? >

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

On Mon, Aug 15, 2022 at 09:29:28AM -0400, Paul Wouters wrote: > I think our decision should be based on the deplyment statistics of SHA1 > based zones and keys. I'd love to see the trending statistics from > Viktor to guide us here. Last time we looked it was still in the order > of 40% or so ?

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Schanzenbach, Martin wrote on 2022-08-15 11:49: ... So, from my authors hat, I would appreciate FCFS; ideally also existing RFC/Other Specification + Implementation(s) for a registration in the registry. +1. -- P Vixie ___ DNSOP mailing list

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

> On 15. Aug 2022, at 20:25, Ray Bellis wrote: > > > > On 15/08/2022 19:17, Paul Vixie wrote: > >> of course i meant that each such namespace would get its own >> "sub-domain" under .alt (e.g., .GNS.ALT). > > Someone also gets to solve the problem of how you get a CA/Browser Forum >

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Ray Bellis wrote on 2022-08-15 11:25: On 15/08/2022 19:17, Paul Vixie wrote: of course i meant that each such namespace would get its own "sub-domain" under .alt (e.g., .GNS.ALT). Someone also gets to solve the problem of how you get a CA/Browser Forum Approved TLS cert for any system

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On 15.08.22 20:25, Ray Bellis wrote: Someone also gets to solve the problem of how you get a CA/Browser Forum Approved TLS cert for any system not accessible via "normal" DNS... Yes, but not us. Eliot ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On 15/08/2022 19:17, Paul Vixie wrote: of course i meant that each such namespace would get its own "sub-domain" under .alt (e.g., .GNS.ALT). Someone also gets to solve the problem of how you get a CA/Browser Forum Approved TLS cert for any system not accessible via "normal" DNS... Ray

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Ray Bellis wrote on 2022-08-15 11:08: On 15/08/2022 18:55, Paul Vixie wrote: ... if IETF decides at this late (2022) date to reserve part of the domain style namespace for non-udp/53 non-tcp/53 uses, nothing will break. that helps me understand the open ended _effective_ intent of STD-13,

Re: [DNSOP] [core] [dns-privacy] WGA call for draft-lenders-dns-over-coap

On 15. Aug 2022, at 19:41, Ted Lemon wrote: > >> On Aug 15, 2022, at 1:34 PM, Carsten Bormann wrote: >> >> On 15. Aug 2022, at 17:11, Ted Lemon wrote: >>> >>> This is a good question. I think we’d want to understand what the actual >>> use case is for DNS-over-CoAP before proceeding with

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On 15/08/2022 18:55, Paul Vixie wrote: if IETF decides at this late (2022) date to reserve part of the domain style namespace for non-udp/53 non-tcp/53 uses, nothing will break. that helps me understand the open ended _effective_ intent of STD-13, which is to build roads not walls -- in the

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On Aug 15, 2022, at 10:14 AM, Ray Bellis wrote: > STD 13 then effectively makes udp/53 and tcp/53 the de-facto wire protocols > for interrogating that system, mostly surplanting the use of host files. > > On that basis, I'm unable to separate the RFC 921 / 952 "Domain Name System" > namespace

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Eliot Lear wrote on 2022-08-15 07:41: ... On 15.08.22 16:11, David Conrad wrote: ... We have no idea whether GNS will take off in popularity or fade away into non-existence. Given the way "configuration is forever”, any partitioning of the namespace will be a feature for the foreseeable

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Ray Bellis wrote on 2022-08-15 10:14: On 13/08/2022 23:56, Paul Vixie wrote: it's very much worth re-reading RFC 921 and RFC 952 to understand ... STD 13 then effectively makes udp/53 and tcp/53 the de-facto wire protocols for interrogating that system, mostly surplanting the use of

Re: [DNSOP] DNSOPAuthorship - was: Re: [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

Michael StJohns writes: > One of the downsides to leaving them on the author list is the need to > involve them in the AUTH48 process.  That can be painful if you're not > actually actively working the document even if you're the source of > much of the text. Of course I'll work it out with

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-rfc8624-bis-00.txt

Paul Wouters writes: > first read of rfcdiff So I actually took the draft from the github archive from both of you, not from the real 8624 xml (because I couldn't find it -- though I know it exists). > > guidance for DNSSEC. This document obsoletes . > > - no targets allowed in the

Re: [DNSOP] [core] [dns-privacy] WGA call for draft-lenders-dns-over-coap

> On Aug 15, 2022, at 1:34 PM, Carsten Bormann wrote: > > On 15. Aug 2022, at 17:11, Ted Lemon wrote: >> >> This is a good question. I think we’d want to understand what the actual use >> case is for DNS-over-CoAP before proceeding with this, > > The main use case is systems that already

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

On Mon, 15 Aug 2022, Tony Finch wrote: o 2019: IETF partially deprecates SHA-1 for use in DNSSEC [RFC8624] "s/partially/for new stuff/" o 2020: Chosen-prefix collision demonstrated in SHA-1 [SHA-mbles] Yes, this is where we disagree about whether this can be abused in DNSSEC. You

Re: [DNSOP] [core] [dns-privacy] WGA call for draft-lenders-dns-over-coap

On 15. Aug 2022, at 17:11, Ted Lemon wrote: > > This is a good question. I think we’d want to understand what the actual use > case is for DNS-over-CoAP before proceeding with this, The main use case is systems that already implement CoAP and do not want to add machinery for some protocols

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

It appears that David Conrad said: >-=-=-=-=-=- > >Eliot, > >On Aug 15, 2022, at 7:41 AM, Eliot Lear wrote: >> What I like about .alt (or whatever we end up calling it) is that it >> requires a single or small number of changes, not one change per name space. > >It creates a new namespace

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-rfc8624-bis-00.txt

first read of rfcdiff guidance for DNSSEC. This document obsoletes . - no targets allowed in the abstract :) - You removed RFC8174 from the 2119 text for no good reason :) - SHA1 changed for validation from MUST to SHOULD NOT. This is the discussion item for the WG :) - GOST to

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On 13/08/2022 23:56, Paul Vixie wrote: it's very much worth re-reading RFC 921 and RFC 952 to understand how it was that domain-style names (an RFC 952 term, which RFC 921 described as "structured names" or "hierarchical names") preceded what we today call the "domain name system." I'm

[DNSOP] Authorship - was: Re: [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

On 8/15/2022 12:17 PM, Wes Hardaker wrote: Paul Wouters writes: This is why I also think 8624bis is better than a stand-alone document, as it takes into account security effects, market deployment, and trying to push the deployments to where we want it to go, instead of just issuing a

[DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-rfc8624-bis-00.txt

Because it's also time... Start of forwarded message From: internet-dra...@ietf.org To: "Ondrej Sury" , "Paul Wouters" , "Wes Hardaker" Subject: New Version Notification for draft-hardaker-dnsop-rfc8624-bis-00.txt Date: Mon, 15 Aug 2022 09:17:53 -0700

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

Paul Wouters writes: > This is why I also think 8624bis is better than a stand-alone document, > as it takes into account security effects, market deployment, and > trying to push the deployments to where we want it to go, instead of just > issuing a document the current deployments have no

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Eliot, On Aug 15, 2022, at 7:41 AM, Eliot Lear wrote: > What I like about .alt (or whatever we end up calling it) is that it requires > a single or small number of changes, not one change per name space. It creates a new namespace (*.alt), presumably one that is less contentious than the

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

Wes Hardaker wrote: > > Because it's time... Better late than never :-) My draft from a couple of years ago describes some fun attacks you can perform on DNSSEC if you can generate a hash collision. So I think SHA-1 ought to be MUST NOT for signing, and there should be a concerted effort to get

Re: [DNSOP] [core] [dns-privacy] WGA call for draft-lenders-dns-over-coap

This is a good question. I think we’d want to understand what the actual use case is for DNS-over-CoAP before proceeding with this, since DNS-over-DTLS would obviously be less costly to implement. The stated use case of this document is to encrypt DNS packets, which is already addressed by

Re: [DNSOP] [dns-privacy] [core] WGA call for draft-lenders-dns-over-coap

DPRIVE is also a fine location. Has anyone implemented DNS over DTLS for your use case? tim On Mon, Aug 15, 2022 at 6:04 AM Jaime Jiménez wrote: > CCing the right DNSOP mailing list now. > > On 15.8.2022 11.26, Jaime Jiménez wrote: > > Dear CoRE WG, > > We would like to start the call for

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On Mon, Aug 15, 2022 at 9:22 AM Ted Lemon wrote: > Do we have any sense of why so many .local queries are escaping? > > Ted Do you mean escaping to the root nameservers? That I do not know. As for .local from https://ithi.research.icann.org/graph-m3.html I would like to see not just the last 3

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Hi, On 15.08.22 16:11, David Conrad wrote: My impression is that there'd be maybe an order of magnitude fewer clients. This is irrelevant. We have no idea whether GNS will take off in popularity or fade away into non-existence. Given the way "configuration is forever”, any partitioning of

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Stephen, On Aug 15, 2022, at 6:46 AM, Stephen Farrell wrote: > 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? No. > My impression is that there'd be

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On Sat, 2022-08-13 at 21:49 +0900, Daisuke HIGASHI wrote: > I wrote an experimental "avoid-fragmentation" patch for NSD (as per > section 3.1 and Appexdix C). Due to dependency on getsockopt(IP_MTU), > currently it should work on Linux only. > >

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

On Fri, 2022-08-12 at 08:48 -0700, Wes Hardaker wrote: >    This document retires the use of SHA-1 within DNSSEC (Half-echoing what Mark Andrews said elsewhere in the thread.) This document fails to retire the use of SHA-1 in NSEC3, and is thus, given its current title, incomplete. We can do

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.

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

On Sun, 14 Aug 2022, Tim Wicinski wrote: Speaking as a chair, and a fan of 8624, I would welcome a 8624-bis document to appear.  (I think I expressed this to others than myself, but).  The table in 3.1 is so clear in what to use and not use.  Right, but there is a reason the original

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Do we have any sense of why so many .local queries are escaping? On Mon, Aug 15, 2022 at 01:09 Christian Huitema wrote: > > On 8/14/2022 8:28 PM, Tim Wicinski wrote: > > On Sun, Aug 14, 2022 at 11:16 PM John Levine > wrote: > > > It appears that Tim Wicinskisaid: > > -=-=-=-=-=- > > as

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

> From: Peter van Dijk > Avoiding fragmentation is good. Putting that in a document is also good. > But this document is not ready for publication. It also most definitely > does not describe Best Current Practice; it also does not prescribe a > Best Current Practice I can agree with or even

Re: [DNSOP] [core] WGA call for draft-lenders-dns-over-coap

CCing the right DNSOP mailing list now. On 15.8.2022 11.26, Jaime Jiménez wrote: Dear CoRE WG, We would like to start the call for adoption on draft-lenders-dns-over-coap. The draft defines a protocol for sending DNS messages over secure CoAP (DTLS and/or OSCORE). The draft was discussed