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

[Michael StJohns <[e-mail]>]

Hi Peter - continues below.


On 8/15/2024 5:41 AM, Peter Thomassen wrote:
> Hi Mike,
>
> On 8/10/24 17:21, Michael StJohns wrote:
>> 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?
>
> The check of the Digest element vs. the publickeyinfo is a consistency 
> check within the XML, because the data structure does not allow ruling 
> out inconsistencies.
>
> Checking the Digest element against a key published elsewhere (e.g. in 
> the root zone) is "out of band", and retrieving that key and relying 
> on the outcome of the check would actually require trusting the 
> retrieval method. That's why I think this is not a plausible way of 
> checking the trust anchor; it's a catch-22 instead.

A digest element by itself could be wrong - mis-transcribed, wrong 
version copied etc.  E.g. Garbage in Garbage out.  Checking the digest 
against either an included public key (which - at least for EC - may be 
checked for internal consistency), or a key already being published via 
DNS gives you an additional measure of validation.  The latter was 
possible with RFC7958, the former has been added for this version of the 
document.

XML may not allow for the ruling out of inconsistencies, but the program 
installing the XML-derived data into the local DNSSEC trust anchor store 
certainly ought to.

Mike

>
> Best,
> Peter
>