Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

[Peter Thomassen <[e-mail]>]

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.<domain-name>._dnssec-signal.<nsname> 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 <[e-mail]> 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, [e-mail] 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