[DNSOP]Re: Intdir telechat review of draft-ietf-dnsop-dnssec-bootstrapping-08

[Benson Muite <[e-mail]>]

Hi Peter,

Thanks for addressing the concerns and educating me.

On 15/05/2024 15.23, Peter Thomassen wrote:
> Hi Benson,
> 
> Thank you for your review.
> 
> On 5/12/24 20:43, Benson Muite via Datatracker wrote:
>> Reviewer: Benson Muite
>> Review result: Ready with Nits
>>
>> I am an assigned INT directorate reviewer for
>> <draft-ietf-dnsop-dnssec-bootstrapping-08.txt>. These comments were
>> written
>> primarily for the benefit of the Internet Area Directors. Document
>> editors and
>> shepherd(s) should treat these comments just like they would treat
>> comments
>> from any other IETF contributors and resolve them along with any other
>> Last
>> Call comments that have been received. For more details on the INT
>> Directorate,
>> see https://datatracker.ietf.org/group/intdir/about/ .
>>
>> Based on my review, if I was on the IESG I would ballot this document
>> as YES.
>>
>> SUMMARY:
>> The draft proposes a mechanism to enable automated initial validation
>> of child
>> subdomain CDS/CDNSKEY records when an out of balliwick name server is
>> available
>> and when the child zone name is not too long.
>>
>> SUGGESTIONS FOR IMPROVEMENT:
> 
> Incorporated changes will show up in the -09 revision (will be published
> later today) and are part of this PR:
> https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/15
> 
>> 1. May want to minimize number of acronyms in the abstract, for
>> example DS
>> (Delegation Signer), CDS (Child DS) and CDNSKEY (Child Domain Name System
>> public key)
> 
> Those terms are identifiers for DNS record types, rather than acronyms.
> As a salient example, the TLSA record type "does not stand for anything"
> (RFC 6698 Section 1.2).
> 
> As such, they are typically not expanded in DNS-related RFCs (see for,
> for example, RFC 8078 whose abstract uses DS and DNSKEY as well without
> expansion).

Ok.

> 
>> 2. Too long is not specified though is mentioned in section 4.4 -
>> could more details be given
> 
> We've added a reference to RFC 1035 Section 3.1 which defines these
> length requirements.

Thanks.

> 
>> and do deprecated out of band methods need to be
>> used in such cases?
> 
> The document deprecates automatic DNSSEC bootstrapping without
> authentication. If it can't be done automatically with authentication,
> one can set up DS records manually (by interacting with the parent
> operator).
> 
> To do it securely, an out of band channel may be needed (e.g., via the
> registrar's web interface). One does not have to use a deprecated
> (insecure) automated method.

Ok.

> 
>> Any estimates on how often too long names might occur?
> I'm not aware of any numbers. It essentially happens when the _dsboot
> and _signal labels together with the domain name and longest nameserver
> hostname exceed 255 octets.
> 
> As both nameserver names and delegated domain names are usually shorter
> than ~120 octets, this is expected to happen very rarely in practice. We
> don't have numbers, unfortunately, but I wouldn't be surprised if the
> only real examples are experiments set up to prove the point.
> 

Ok.

>> 3.
>> Will there be a follow on informational best practice document based on
>> operational experiences?
> Saying this is not in scope for the spec document, but yes, various
> people (including some ICANN staff) have expressed interest in writing
> up best practices / operational experience on DNSSEC automation,
> including (but not limited to) the topic of bootstrapping.
>

Great.

> Thanks,
> Peter
>