[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

[Michael StJohns <[e-mail]>]

Hi Paul -

Inline

On 8/9/2024 5:09 PM, Paul Hoffman wrote:
> On Aug 9, 2024, at 12:16, Michael StJohns<[e-mail]>  wrote:
>> Two comments - one major and one very minor.
>>
>> Major:  I'm sorry for the late comment, but I didn't realize you were planning on starting to provide prospective DS's for unpublished keys.  Telling people there's a new trust anchor, and that the live key matches this file is one thing - easy enough for a relying party to match up a few things and accept the TA update.  Telling them there's an unpublished key and "trust me, when you see it it will have this digest and you should go ahead now and install it in your trust anchors" seems to be a bit more risky.
> This is unchanged from RFC 7958, published in 2016. It was done for the key rollover to KSK-2017. If you propose to change this activity now, I propose that you take this to IANA; the current draft and RFC 7958 reflect IANA's long-established policies.

Paul - this is related directly to the newly specified inclusion of the 
public key material in this draft (sect 3.2 last para):

>     A KeyDigest element can contain both a Digest and a publickeyinfo
>     named pattern.  If the Digest element would not be a proper DS record
>     for a DNSKEY record represented by the publickeyinfo named pattern,
>     relying parties MUST NOT use that KeyDigest as a trust anchor.

Prior to this there was no check on the correctness of the offered 
digest, except that a smart relying party could have looked at the 
published keys and tried to find a match.  After this is published as an 
RFC, the relying part mostly only needs to look at the public key data 
in the file if it exists and not worry about whether it was published.  
This is not "unchanged from RFC 7958" IMO.   Finally, reading this,  why 
wouldn't you explicitly specify that the hash needs to be  (e.g. MUST 
be) verified against either a live (published) key or the included 
public key?  Trust anchors require - well - trust.  I would think that 
the more verification I can get to avoid polluting my personal trust 
anchor store, the better.

>> Looking at the Security Considerations - I don't think the updates to this section made this is sufficiently evident.
> That's because this part of RFC 7958 was not updated in this draft.
See above.
>>    I'd suggest two things:  1) Talk about the above in the security considerations, and 2) Place a disclaimer in the TA file with similar language about the prospective key material.
> The latter is a suggestion to IANA.

IANA/ICANN is not writing this document - except as far as  you are 
ICANN.  IANA/ICANN is signing the file.... why wouldn't they provide a 
comment or a CDATA element that describes these limitations?  Given that 
you're updating the syntax, why not do it now? And why are you talking 
about ICANN/IANA in the third person?

>> Minor minor minor nit - feel free to ignore this:
>>
>> The flags field for the DNSKEY is represented in most DNS presentation modes as an unsigned decimal integer - but it's actually a bit field of two bytes.  The representation is used mostly because that's what a DNS Zone File used (e.g. either Base64 or a decimal integer) for most non-text fields.  Unclear decimal should be used for XML.
> Section 2.2 of RFC 4034 says "The Flag field MUST be represented as an unsigned decimal integer."

RFC 4034 2.2  is talking about DNS RR Presentation format, not XML.  In 
any event,  section 2.1 represents the flag field as 2 8-bit bytes so 
equal support for either approach.

>> It may make some sense here to use <xsd:hexBinary { length = 2 }/>  is the field type the appropriate mapping here  - <Flag>0101</Flag> instead of the decimal 257.  Easier to see what bits have been set.
> That would then be different than the KeyType, Algorithm, and DigestType fields that are expressed as xsd:nonNegativeInteger. If the WG wants to make this inconsistent, it can, but I would generally be against that.

KeyType, Algorithm and DigestType are all enums - Flags is a bit field.  
What's more inconsistent is 4034 treating the flags field as an unsigned 
number, but reasonable enough as few if any other RR presentation fields 
are flag fields.  (I can't think of one... but with all the myriad RR 
types, I'm sure someone has built one).

As I said - minor nit.  Sometimes when you're reencoding data from one 
scheme to another you need to have these polite conversations and 
actually consider the circumstances.

Later, Mike

> --Paul Hoffman