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 <m...@nthpermutation.com> wrote:
On 8/9/2024 5:09 PM, Paul Hoffman wrote:
On Aug 9, 2024, at 12:16, Michael StJohns <m...@nthpermutation.com> wrote:
On Aug 15, 2024, at 02:43, Petr Špaček <pspa...@isc.org> 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

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Reply via email to