On 09. 08. 24 20:22, Paul Hoffman wrote:
To everyone who reviewed draft-ietf-dnsop-rfc7958bis in WG Last Call: please
carefully review the diff. Based on a very good IETF Last Call review from Petr
Špaček, we had to make a significant technical change to the XML format, and we
want to be sure that it works for everyone. We also updated the example (of
course), and in doing so found a way to simplify the material around the
example.
All comments welcome (until my birthday, August 18).
--Paul Hoffman
On Aug 9, 2024, at 11:05, Warren Kumari <war...@kumari.net> wrote:
Dear DNSOP,
During the DNSDIR review of draft-ietf-dnsop-rfc7958bis-03, Petr Špaček
identified an issue: if you include the DNSKEY material you also need to
include the flags.
The authors have published a new version addressing these changes, as well as
addressing more minor comments received during IETF LC.
As this required a change to the XML syntax, I'd like to get the DNSOP WGs
review / feedback on these changes.
The IANA is eagerly awaiting this becoming a standard so that they can update
their trust anchor with the DNSKEY material - so, if you have any strong
objections to these changes, please let me know by end of day (anywhere!) on
Aug 18th
Latest version: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/
Diff from -03:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-rfc7958bis-03&url2=draft-ietf-dnsop-rfc7958bis-04&difftype=--html
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.
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)
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)
... and say that the relying party needs to deal with this discrepancy
between DS and DNSKEY sets.
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.
Ad
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.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
