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

[Warren Kumari <[e-mail]>]

On Mon, Aug 26, 2024 at 11:51 AM, Petr Špaček <[e-mail]> wrote:

> Hi everyone,
>
>
>
Hi everyone!

Thank you very much for your comments. We've had some discussions, and the
authors will be publishing a new version in the next few days addressing
these.

In addition, I will be deferring the IESG Evaluation / Balloting from this
telechat/cycle to the following one. I would really like to get this
published soon (so that the IANA can use it), but the document will benefit
from some more clarity / polish.

Thank you all very much again,
Warren.


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 <http://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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>