On Mon, Aug 26, 2024 at 11:51 AM, Petr Špaček <pspa...@isc.org> 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 <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 <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 -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
