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
