[DNSOP][IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi all, Following up on this. Please let us know how we should proceed for this. Thank you. Best regards, David Dong IANA Services Sr. Specialist On Thu May 09 09:39:29 2024, pe...@desec.io wrote: > [another (last) attempt of reposting this as it did not get delivered > to dnsop@ietf.org on May 7, as evidenced by the list archive] > > > Hi, > > On 5/2/24 19:59, David Dong via RT wrote: > > Following up on this; does the group agree that "_dnssec" is OK? > > Looking at what's been said in this thread: > - Two people have proposed to change the label, current proposal: > _dnssec > - Two implementers have said they'd make the change but don't seem > convinced > - The authors (hats off, but also implementers and authors of current > drafts using the mechanism) are not convinced > > The authors don't feel comfortable declaring consensus in either > direction (neither do we know whether that's our role), and we're not > sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the > discussion is happening on the WG list although the document is > technically out of the door ... > > > I've been reluctant adding the following argument as to not seem > insisting; OTOH it may have its own technical merit, so here is. > > The "_dnssec" label implies that the mechanism is not suitable for > signaling unrelated to DNSSEC. That's an artificial limitation, and > it's unclear why to impose the restriction. An operator could very > well want to publish other things, like > > - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse > address, > - PTR at _catalog.example.com._signal ... for catalog zone membership, > - ... > > If the signaling method is generic, I believe it should have a short > generic label. Any specificity to determine the kind of signal can go > into the first label. > > I have no specific preference for "_signal" other than I don't know > what a good alternative would be. Narrowing the scope with "_dnssec" > doesn't seem to improve the situation. > > Thanks, > Peter > + Nils (for the "we"/author statements) > > > > Thank you. > > > > Best regards, > > > > David Dong > > IANA Services Sr. Specialist > > > > On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: > >> On 20 Apr 2024, at 19:38, Paul Wouters wrote: > >> > >>> On Sat, 20 Apr 2024, Peter Thomassen wrote: > >>> > The authors certainly don't insist, but we'd need to pick a > suitable > replacement for the "_signal" label. > > John proposed "_dnssec-signal" elsewhere in this thread. > > The authors would like to note that adding "_dnssec-" eats up 8 > more > bytes, increasing chances that bootstrapping will fail due to the > _dsboot.._dnssec-signal. length limitation. > Other than this (unnecessary?) use case narrowing, this choice > seems > fine. > > That said, does this choice address your concerns? > >>> > >>> It would, but I would also be okay if it is just _dnssec. > >>> > >> > >> If the concern is that the label is too generic, “_dnssec” might be > >> too generic as well. If it is to be more precise, go with _ds-boot > >> or > >> something more specific to the use case. I don’t have an > >> implementation in the mix, so it this isn’t a strong opinion. If > >> the > >> group agrees _dnssec is fine, then I am fine with it too. > >> > >> Scott > >> > >> = > >> Scott Rose > >> NIST/CTL/WND > >> scott.r...@nist.gov > >> ph: 301-975-8439 > >> GoogleVoice: 571-249-3671 > >> = > > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi all, Following up on this; does the group agree that "_dnssec" is OK? Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: > On 20 Apr 2024, at 19:38, Paul Wouters wrote: > > > On Sat, 20 Apr 2024, Peter Thomassen wrote: > > > >> The authors certainly don't insist, but we'd need to pick a suitable > >> replacement for the "_signal" label. > >> > >> John proposed "_dnssec-signal" elsewhere in this thread. > >> > >> The authors would like to note that adding "_dnssec-" eats up 8 more > >> bytes, increasing chances that bootstrapping will fail due to the > >> _dsboot.._dnssec-signal. length limitation. > >> Other than this (unnecessary?) use case narrowing, this choice seems > >> fine. > >> > >> That said, does this choice address your concerns? > > > > It would, but I would also be okay if it is just _dnssec. > > > > If the concern is that the label is too generic, “_dnssec” might be > too generic as well. If it is to be more precise, go with _ds-boot or > something more specific to the use case. I don’t have an > implementation in the mix, so it this isn’t a strong opinion. If the > group agrees _dnssec is fine, then I am fine with it too. > > Scott > > = > Scott Rose > NIST/CTL/WND > scott.r...@nist.gov > ph: 301-975-8439 > GoogleVoice: 571-249-3671 > = ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
On 20 Apr 2024, at 19:38, Paul Wouters wrote: > On Sat, 20 Apr 2024, Peter Thomassen wrote: > >> The authors certainly don't insist, but we'd need to pick a suitable >> replacement for the "_signal" label. >> >> John proposed "_dnssec-signal" elsewhere in this thread. >> >> The authors would like to note that adding "_dnssec-" eats up 8 more bytes, >> increasing chances that bootstrapping will fail due to the >> _dsboot.._dnssec-signal. length limitation. Other than >> this (unnecessary?) use case narrowing, this choice seems fine. >> >> That said, does this choice address your concerns? > > It would, but I would also be okay if it is just _dnssec. > If the concern is that the label is too generic, “_dnssec” might be too generic as well. If it is to be more precise, go with _ds-boot or something more specific to the use case. I don’t have an implementation in the mix, so it this isn’t a strong opinion. If the group agrees _dnssec is fine, then I am fine with it too. Scott = Scott Rose NIST/CTL/WND scott.r...@nist.gov ph: 301-975-8439 GoogleVoice: 571-249-3671 = ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hello all, We (Knot DNS) don't see any issue with updating our implementation if necessary. Personally I'm fine with the current format. Daniel On 4/21/24 01:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? It would, but I would also be okay if it is just _dnssec. The main question then is to get implementations updated. I'm thus copying a few implementers so they can comment w.r.t. making this change in their implementation. I suppose that barring their objections, it's fine to go ahead? I feel less sympathy there because I brought this up a long time ago :) But also, implementations are all young and new and I think it is still pretty easy to change. Paul OpenPGP_signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? It would, but I would also be okay if it is just _dnssec. The main question then is to get implementations updated. I'm thus copying a few implementers so they can comment w.r.t. making this change in their implementation. I suppose that barring their objections, it's fine to go ahead? I feel less sympathy there because I brought this up a long time ago :) But also, implementations are all young and new and I think it is still pretty easy to change. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi Am 20.04.2024 um 12:13 schrieb Peter Thomassen: [...] The main question then is to get implementations updated. I'm thus copying a few implementers so they can comment w.r.t. making this change in their implementation. I suppose that barring their objections, it's fine to go ahead? Updating our implementation wouldn't be a problem. It's a draft after all, so we did expect possible changes to happen during the process. I'd prefer the current short and generic '_signal' label, as I was under the assumption future things that want to signal something could use it as well and just replace the '_dsboot' label instead. But I do not have strong objections to changing it. Best regards Oli ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi Paul, The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? The main question then is to get implementations updated. I'm thus copying a few implementers so they can comment w.r.t. making this change in their implementation. I suppose that barring their objections, it's fine to go ahead? Thanks, Nils and Peter On 4/20/24 01:18, Paul Wouters wrote: If the authors insist, then as DE of this registry, this entry is okay. My point below still holds, but I will leave that up to the authors and IESG. Paul Sent using a virtual keyboard on a phone On Apr 19, 2024, at 18:47, David Dong via RT wrote: Hi Paul, Just a ping on this; thank you. Best regards, David Dong IANA Services Sr. Specialist On Sat Apr 13 01:24:13 2024, pe...@desec.io wrote: Hi Paul, On 4/12/24 22:36, Paul Wouters wrote: However, I would urge the authors/WG to pick a less generic and more specific name than "_signal", such as "_dnssec-bootstrap". Especially because there is also the well known "Signal" message client. Also, in case of future different signaling, the current name might become confusing. The signaling record names actually have two underscore labels, and look like (taking nohats.ca as an example) _dsboot.nohats.ca._signal.ns2.foobar.fi. The specific type of signal is already indicated by the first label. Other signaling use cases would use a different first label. (draft- thomassen-dnsop-mske has an example.) The _signal label generically indicates that ns2.foobar.fi likes to signal something about nohats.ca. Its presence is needed to allow separating the object from the source without ambiguity. We could change _signal to something else, but not to _dnssec- bootstrap as that's not generic. Suggestions are welcome. I'd like to add some considerations: - The spec has quite a few production implementations (see Section 8), and changing them would come with significant costs. - I don't think the _signal label is in use for the Signal messenger. Even in case it's used in the future, a collision (in terms of prefix labels + rdtype) seems unlikely. As there would be significant costs, but no tangible benefit, perhaps we should not do this. Further context: The structure of the signaling name is the result of the DNSOP Interim [1]. Details on rejected alternatives can be found in [2]. [1]: "Open Issue 3" in https://datatracker.ietf.org/meeting/interim- 2022-dnsop-01/materials/slides-interim-2022-dnsop-01-sessa- authenticated-dnssec-bootstrapping-00.pdf [2]: https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/ Thanks, Peter ___ DNSOP mailin -- Like our community service? Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
If the authors insist, then as DE of this registry, this entry is okay. My point below still holds, but I will leave that up to the authors and IESG. Paul Sent using a virtual keyboard on a phone > On Apr 19, 2024, at 18:47, David Dong via RT > wrote: > > Hi Paul, > > Just a ping on this; thank you. > > Best regards, > > David Dong > IANA Services Sr. Specialist > >> On Sat Apr 13 01:24:13 2024, pe...@desec.io wrote: >> Hi Paul, >> >>> On 4/12/24 22:36, Paul Wouters wrote: >>> However, I would urge the authors/WG to pick a less generic and more >>> specific name than "_signal", such as "_dnssec-bootstrap". Especially >>> because there is also the well known "Signal" message client. Also, >>> in case of future different signaling, the current name might become >>> confusing. >> >> The signaling record names actually have two underscore labels, and >> look like (taking nohats.ca as an example) >> >> _dsboot.nohats.ca._signal.ns2.foobar.fi. >> >> The specific type of signal is already indicated by the first label. >> Other signaling use cases would use a different first label. (draft- >> thomassen-dnsop-mske has an example.) >> >> The _signal label generically indicates that ns2.foobar.fi likes to >> signal something about nohats.ca. Its presence is needed to allow >> separating the object from the source without ambiguity. >> >> We could change _signal to something else, but not to _dnssec- >> bootstrap as that's not generic. Suggestions are welcome. >> >> >> I'd like to add some considerations: >> >> - The spec has quite a few production implementations (see Section 8), >> and changing them would come with significant costs. >> >> - I don't think the _signal label is in use for the Signal messenger. >> Even in case it's used in the future, a collision (in terms of prefix >> labels + rdtype) seems unlikely. >> >> As there would be significant costs, but no tangible benefit, perhaps >> we should not do this. >> >> >> Further context: The structure of the signaling name is the result of >> the DNSOP Interim [1]. Details on rejected alternatives can be found >> in [2]. >> >> [1]: "Open Issue 3" in https://datatracker.ietf.org/meeting/interim- >> 2022-dnsop-01/materials/slides-interim-2022-dnsop-01-sessa- >> authenticated-dnssec-bootstrapping-00.pdf >> [2]: >> https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/ >> >> Thanks, >> Peter > > ___ > DNSOP mailin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi Paul, Just a ping on this; thank you. Best regards, David Dong IANA Services Sr. Specialist On Sat Apr 13 01:24:13 2024, pe...@desec.io wrote: > Hi Paul, > > On 4/12/24 22:36, Paul Wouters wrote: > > However, I would urge the authors/WG to pick a less generic and more > > specific name than "_signal", such as "_dnssec-bootstrap". Especially > > because there is also the well known "Signal" message client. Also, > > in case of future different signaling, the current name might become > > confusing. > > The signaling record names actually have two underscore labels, and > look like (taking nohats.ca as an example) > > _dsboot.nohats.ca._signal.ns2.foobar.fi. > > The specific type of signal is already indicated by the first label. > Other signaling use cases would use a different first label. (draft- > thomassen-dnsop-mske has an example.) > > The _signal label generically indicates that ns2.foobar.fi likes to > signal something about nohats.ca. Its presence is needed to allow > separating the object from the source without ambiguity. > > We could change _signal to something else, but not to _dnssec- > bootstrap as that's not generic. Suggestions are welcome. > > > I'd like to add some considerations: > > - The spec has quite a few production implementations (see Section 8), > and changing them would come with significant costs. > > - I don't think the _signal label is in use for the Signal messenger. > Even in case it's used in the future, a collision (in terms of prefix > labels + rdtype) seems unlikely. > > As there would be significant costs, but no tangible benefit, perhaps > we should not do this. > > > Further context: The structure of the signaling name is the result of > the DNSOP Interim [1]. Details on rejected alternatives can be found > in [2]. > > [1]: "Open Issue 3" in https://datatracker.ietf.org/meeting/interim- > 2022-dnsop-01/materials/slides-interim-2022-dnsop-01-sessa- > authenticated-dnssec-bootstrapping-00.pdf > [2]: > https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/ > > Thanks, > Peter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
It appears that Peter Thomassen said: >The _signal label generically indicates that ns2.foobar.fi likes to signal >something about nohats.ca. Its presence is needed to allow separating the >object from the source without ambiguity. > >We could change _signal to something else, but not to _dnssec-bootstrap as >that's not generic. Suggestions are welcome. They're all DNSSEC related so how about _dnssec-signal ? >I'd like to add some considerations: > >- The spec has quite a few production implementations (see Section 8), and >changing them would come with significant costs. > >- I don't think the _signal label is in use for the Signal messenger. Even in >case it's used in the future, a collision (in terms of prefix labels + rdtype) >seems unlikely. It's not but _signal is an awfully generic term, and I do not want to count on people inventing sufficiently distinct second level _label names to keep unrelated uses separate. When we were collecting names for the _label registry there were a few places with overlapping names like the URI RRTYPE, and it's a mess. Let's not do it again. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi Paul, On 4/12/24 22:36, Paul Wouters wrote: However, I would urge the authors/WG to pick a less generic and more specific name than "_signal", such as "_dnssec-bootstrap". Especially because there is also the well known "Signal" message client. Also, in case of future different signaling, the current name might become confusing. The signaling record names actually have two underscore labels, and look like (taking nohats.ca as an example) _dsboot.nohats.ca._signal.ns2.foobar.fi. The specific type of signal is already indicated by the first label. Other signaling use cases would use a different first label. (draft-thomassen-dnsop-mske has an example.) The _signal label generically indicates that ns2.foobar.fi likes to signal something about nohats.ca. Its presence is needed to allow separating the object from the source without ambiguity. We could change _signal to something else, but not to _dnssec-bootstrap as that's not generic. Suggestions are welcome. I'd like to add some considerations: - The spec has quite a few production implementations (see Section 8), and changing them would come with significant costs. - I don't think the _signal label is in use for the Signal messenger. Even in case it's used in the future, a collision (in terms of prefix labels + rdtype) seems unlikely. As there would be significant costs, but no tangible benefit, perhaps we should not do this. Further context: The structure of the signaling name is the result of the DNSOP Interim [1]. Details on rejected alternatives can be found in [2]. [1]: "Open Issue 3" in https://datatracker.ietf.org/meeting/interim-2022-dnsop-01/materials/slides-interim-2022-dnsop-01-sessa-authenticated-dnssec-bootstrapping-00.pdf [2]: https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/ Thanks, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
On Fri, 12 Apr 2024, David Dong via RT wrote: Dear Frederico A C Neves and Paul Wouters (cc: dnsop WG), As the designated experts for the Underscored and Globally Scoped DNS Node Names registry, can you review the proposed registration in draft-ietf-dnsop-dnssec-bootstrapping-08 for us? Please see https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ As the registry is FCFS, and the proper fields are supplied, and the RRtype properly limited, this registry entry is okay. However, I would urge the authors/WG to pick a less generic and more specific name than "_signal", such as "_dnssec-bootstrap". Especially because there is also the well known "Signal" message client. Also, in case of future different signaling, the current name might become confusing. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Dear Frederico A C Neves and Paul Wouters (cc: dnsop WG), As the designated experts for the Underscored and Globally Scoped DNS Node Names registry, can you review the proposed registration in draft-ietf-dnsop-dnssec-bootstrapping-08 for us? Please see https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ The due date is April 26. If this is OK, when the IESG approves the document for publication, we'll make the registration at: https://www.iana.org/assignments/dns-parameters/ Unless you ask us to wait for the other reviewer, we’ll act on the first response we receive. With thanks, David Dong IANA Services Sr. Specialist ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
