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

[Petr Špaček <[e-mail]>]

Hi everyone,

I'm responding only to Paul's reaction to my previous comments. I don't 
want discuss IANA operational procedures here so I tried to focus on the 
XML and it's consumers.

On 21. 08. 24 0:20, Paul Hoffman wrote:
> On Aug 10, 2024, at 08:21, Michael StJohns <[e-mail]> wrote:
>> On 8/9/2024 5:09 PM, Paul Hoffman wrote:
>>> On Aug 9, 2024, at 12:16, Michael StJohns <[e-mail]> wrote:
> On Aug 15, 2024, at 02:43, Petr Špaček <[e-mail]> wrote:
> 
>> I've re-reviewed the -04 version. It addresses the major problem of the format - the inability to represent some DNSSEC TAs.
>>
>> -04 changes resulted in some omissions in the new text, see below.
>>
>>
>>> 2.3. XML Example
>>
>> Between versions -03 and -04 we have lost text with explicit instructions how to reconstruct text representation of DS and DNSKEY. I'm fine with doing it in the new section 2.3 but there are two omissions in the -04 text:
>>
>> A.
>> Missing example of DNSKEY RR reconstruction. It was formerly present in the draft -03 section 2.4. Most notably -04 text is missing instruction about DNSKEY "Protocol" field which is not represented in the XML.
>>
>> I think it needs a reference to RFC 4034 section 2.1.2 and an unambiguous instruction that constant "3" needs to be put in place of the Protocol field of the DNSKEY RR under (re)construction.
>>
>> B.
>> Missing instruction about implicit class "IN". RFC 4034 defined all RR types as class-independent. I think it's fine to say "add constant 'IN' and be done with this", but I'm not aware of any RFC which would say that non-IN classes are not to be ever used.
> 
> I'm not understanding the threat model here. Are you saying that there might be validating resolvers who need a properly formatted DNSKEY record, but don't know how to put one together using the publickeyinfo? People wanted the document to be simpler, so we took out what was basically a restatement of RFC 4034.

I did not mean to imply any security threat.

It's simply that reader of the document cannot immediately see why 
certain fields of DNSKEY are not defined in the XML and their values 
have to be pulled out of thin air with no explicit instructions.


Having said that, I agree with you that a reader of the document who 
knows DNSSEC lore can fill in these two fields without any real risk.

I think it's wrong to leave things undefined in a document defining an 
interoperable file format but I don't insist on these two nits.


>> C.
>> Besides these two protocol omissions I think it would be good to expand the example to cover corner case created by optional publickeyinfo elements.
>>
>> I would recommend to base the 2.3 XML example section on the current version of http://data.iana.org/root-anchors/root-anchors.xml _with DNSKEY added_ for the 20326 keytag.
>>
>> I.e. we would show three KeyDigest elements:
>> - 19036 which is expired (validUntil in the past)
>> - 20326 which is currently valid and also contains (PublicKey, Flags)
>> - 38696 which is also valid but does NOT contain (PublicKey, Flags)
> 
> Is this important enough for us to have to do a new draft?

See below. I think it is.


>> Then the text should show how to reconstruct:
>> - DS set with two valid DSes (20326, 38696)
>> - DNSKEY set with just one DNSKEY (20326 only because material for 38696 is missing)
> 
> Again, I'm not seeing the value to restating RFC 4034 here.

Sorry but no, this has nothing to do with RFC 4034. It's limitation of 
the proposed XML format which has an optional field. That optional 
feature makes the format internally inconsistent for different groups of 
readers - depending on whether the reader implementation looks at Digest 
or publickeyinfo elements.


>> ... and say that the relying party needs to deal with this discrepancy between DS and DNSKEY sets.
> 
> We already have that in the Security Considerations.

I can't see any words about DS vs. DNSKEY set mismatch in the current 
Security Considerations section. Are they somewhere else I could not 
find them?


>> Personally I still think it's a mistake to make publickeyinfo optional but with the current safeguards in place (last paragraph of sect 3.2) I'm hesitantly okay with leaving it optional.
> 
> If we make it mandatory, then the current trust anchor file, and all previous trust anchor files, are invalid. We thought it was better to keep them valid.

I don't think it's an useful goal. Allow me to explain:

- Old versions of existing software either:
a) deal with the extended format
b) or will break when the optinal publickeyinfo is actually present.
That's same no matter if publickeyinfo is optional or not.

- IANA is reportedly eager to have the new format published ASAP. It 
implies the time window where a new versions of the software can see an 
old version of the file is probably very small. Consequently, new 
software can rely on the new parser for all new XML files.

- Old files are by definition (semantically) problematic for relying 
parties - nobody should be using an old XML if they are setting up trust 
anchors! It just does not make sense security-wise. I would call it a 
feature that new software will refuse to work with an obsolete TA 
definition!

- The only remaining use-case I can see then are researchers looking at 
historical XMLs. I would say the number of XML files through history is 
so low that it's not worth worrying about.

In other words:
I would recommend making publickeyinfo mandatory which removes nasty 
corner cases discussed above (and below).

Or if making it mandatory is not an option then please add warnings and 
an example to the text to attract attention to the inherent DS vs. 
DNSKEY set inconsistency.


>>> 5. IANA Considerations
>>
>> I wonder if this section needs some words about how to handle REVOKE flag and similar DS-hash-affecting situations. Setting REVOKE flag on a (former) TA will change its DS hash. This means that a relying party which stored just the DS RR cannot match pre-REVOKEd and post-REVOKEd DS.
>>
>> Maybe IANA should have an instruction to NOT include REVOKEd TAs in the file at all? Or maybe IANA should included only the pre-REVOKEd DS hash with validUntil set to the past?
>>
>> This mess is partially a consequence of the former refusal to assign any meaning to KeyDigest.id elements so the relying parties have a new guesswork to do when matching old and new trust anchors, but I gather this was already discussed (and refused to change) on the mailing list... So let's not open that question again and deal only with the consequences.
>>
>> I'm not sure what to do about this.
> 
> IANA is aware of all of these choices, and I think it is reasonable to let them decide. If you want to have them think more about this, they have the public mailing list for input.

Fair enough, let's not prescribe operational mechanics for IANA.

Maybe we can add a paragraph roughly like this into Security Considerations?

---
Relying parties need to implement TA matching very carefully. A single 
TA represented by a KeyDigest element can potentially change its Digest 
and KeyTag values between two versions of the TA XML, e.g. when key is 
revoked or another DNSSEC flag changes. Relying parties which fail to 
take this property into account are at risk of using incorrect TA set.
---


If the format keeps publickeyinfo element as optional then another 
paragraph is in order. E.g.:
---
Relying parties which depend on the optional publickeyinfo element are 
at risk of not seeing TAs published without this optional element. 
Consequently different parties who ingest the same XML at the same time 
can produce different set of trust anchors.
---
If the publickeyinfo element is mandatory this problem goes away and we 
don't need to talk about it here.

I hope it helps.

-- 
Petr Špaček
Internet Systems Consortium