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

[Paul Hoffman <[e-mail]>]

This is an omnibus reply to the messages on this thread. I believe that the -04 draft is complete, but responses to the replies below may change that. The draft is currently in Warren's hands, so he gets to decide whether a new draft is needed for any of those points.

--Paul Hoffman


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:
>> 
>>> Two comments - one major and one very minor.
>>> 
>>> Major: I'm sorry for the late comment, but I didn't realize you were planning on starting to provide prospective DS's for unpublished keys. Telling people there's a new trust anchor, and that the live key matches this file is one thing - easy enough for a relying party to match up a few things and accept the TA update. Telling them there's an unpublished key and "trust me, when you see it it will have this digest and you should go ahead now and install it in your trust anchors" seems to be a bit more risky.
>>> 
>> This is unchanged from RFC 7958, published in 2016. It was done for the key rollover to KSK-2017. If you propose to change this activity now, I propose that you take this to IANA; the current draft and RFC 7958 reflect IANA's long-established policies.
> Paul - this is related directly to the newly specified inclusion of the public key material in this draft (sect 3.2 last para):
> 
>> A KeyDigest element can contain both a Digest and a publickeyinfo
>> named pattern. If the Digest element would not be a proper DS record
>> for a DNSKEY record represented by the publickeyinfo named pattern,
>> relying parties MUST NOT use that KeyDigest as a trust anchor.
>> 
> 
> Prior to this there was no check on the correctness of the offered digest, except that a smart relying party could have looked at the published keys and tried to find a match.  After this is published as an RFC, the relying part mostly only needs to look at the public key data in the file if it exists and not worry about whether it was published.  This is not "unchanged from RFC 7958" IMO.

7958 let the relying party accept the public key data in the file (the DS material) and not worry about whether it was published; with the new addition, a relying party can accept the public key data in the file (the DS material and the optional DNSKEY material). The threat model is unchanged.

> Finally, reading this,  why wouldn't you explicitly specify that the hash needs to be  (e.g. MUST be) verified against either a live (published) key or the included public key?

Because IANA publishes the hash information in the trust anchor file before the many months before the key appears in the root zone. That was true in 2016, and is already true now. If you want to suggest to IANA that they change this policy, they have the [e-mail] mailing list for things like this. There are already plenty of people on the list, including developers of validating software. (I know you (Mike) already know this because you're on the mailing list, but I thought it was good to say it to the whole group here.)

>  Trust anchors require - well - trust.  I would think that the more verification I can get to avoid polluting my personal trust anchor store, the better.

If a relying party wants more verification, that's fine: they don't accept keying material until it also appears in the root zone itself. We don't know of any threat model where that is important, but that is definitely a choice they might want to make. This document does not specify what a relying party's threat model should be.

> 
>>> Looking at the Security Considerations - I don't think the updates to this section made this is sufficiently evident.
>>> 
>> That's because this part of RFC 7958 was not updated in this draft.
> See above.
>> 
>>> I'd suggest two things: 1) Talk about the above in the security considerations, and 2) Place a disclaimer in the TA file with similar language about the prospective key material.
>>> 
>> The latter is a suggestion to IANA.
> IANA/ICANN is not writing this document - except as far as  you are ICANN.  IANA/ICANN is signing the file.... why wouldn't they provide a comment or a CDATA element that describes these limitations?  Given that you're updating the syntax, why not do it now? And why are you talking about ICANN/IANA in the third person?

This is a WG document. The fact that one author works for ICANN is basically irrelevant. If you want to suggest to IANA that they put some additional text into the trust anchor file, you can let them know that. After this document goes through the IESG, IANA will have the ability to add comments to the trust anchor file.

> 
>>> Minor minor minor nit - feel free to ignore this:
>>> 
>>> The flags field for the DNSKEY is represented in most DNS presentation modes as an unsigned decimal integer - but it's actually a bit field of two bytes. The representation is used mostly because that's what a DNS Zone File used (e.g. either Base64 or a decimal integer) for most non-text fields. Unclear decimal should be used for XML.
>>> 
>> Section 2.2 of RFC 4034 says "The Flag field MUST be represented as an unsigned decimal integer."
> RFC 4034 2.2  is talking about DNS RR Presentation format, not XML.  In any event,  section 2.1 represents the flag field as 2 8-bit bytes so equal support for either approach.
>>> It may make some sense here to use <xsd:hexBinary { length = 2 }/> is the field type the appropriate mapping here - <Flag>0101</Flag> instead of the decimal 257. Easier to see what bits have been set.
>>> 
>> That would then be different than the KeyType, Algorithm, and DigestType fields that are expressed as xsd:nonNegativeInteger. If the WG wants to make this inconsistent, it can, but I would generally be against that.
>> 
> KeyType, Algorithm and DigestType are all enums - Flags is a bit field.  What's more inconsistent is 4034 treating the flags field as an unsigned number, but reasonable enough as few if any other RR presentation fields are flag fields.  (I can't think of one... but with all the myriad RR types, I'm sure someone has built one).
> As I said - minor nit.  Sometimes when you're reencoding data from one scheme to another you need to have these polite conversations and actually consider the circumstances.

Got it. Others also supported keeping the XML data in the presentation format.



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.

> 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?

> 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.

> 
> ... 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.

> 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.

> 
>> 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.



On Aug 15, 2024, at 09:21, Michael StJohns <[e-mail]> wrote:
> 
> Sorry - 1-3 new issues and commentary on the previous issue.
> 
> Expanding:
> 
> **** Please Clarify:  The document does not state if this set of TAs is additive to a relying party's existing TA set or replaces them.  

It doesn't specify any policy for the relying party: it lets them choose.

> 
> **** Please Clarify:   What happens if you provide a TA with a "validUntil" in the future (say 2 years) and ICANN does not issue a replacement?    Is that TA marked as revoked at the expiration of the validUntil?  It appears to be - see both of the next quotes.  This feels like a "BAD THING".

This is up to IANA. The document does not tell IANA what to publish, only the format to use when publishing.

> 
>> The validFrom and validUntil attributes in the KeyDigest element
>> specify the range of times that the KeyDigest element can be used as
>> a trust anchor.
> **** Please clarify: 
> 
>> Note that the validUntil attribute of the KeyDigest element is
>> optional. If the relying party is using a trust anchor that has a
>> KeyDigest element that does not have a validUntil attribute, it can
>> change to a trust anchor with a KeyDigest element that does have a
>> validUntil attribute, as long as that trust anchor's validUntil
>> attribute is in the future and the KeyTag, Algorithm, DigestType, and
>> Digest elements of the KeyDigest are the same as the previous trust
>> anchor.
> I don't actually know what to do with this.   Right now if you have multiple TAs, ANY TA that is live may be used to provide the base of a chain of trust.   "change to a trust anchor..." is a no-op.   This section seems to be describing operational behavior past the first read of the TA by a relying party which appears to be a change to how DNSSEC operates.
> 
> Instead I suggest:  "validUntil should be read as the planned last date of signing by ICANN for that specific trust anchor.  A relying party may continue to accept validations that chain to this trust anchor past this date unless the trust anchor is manually removed, or it is revoked."
> 
> If you want to actually revoke the key, use the 5011 scheme and include the signature for the revoked key  (by the revoked key over the revoked DNSKEY formed as a singleton RR) in this file.
> 
> And I think "validFrom" also ought to be read as "validFrom is the planned first date for ICANN to begin signing with this TA.  A relying party should not install this TA until the specified validFrom date, but if it does, the relying party should treat validations that chain to this TA that are otherwise valid, as valid regardless of the validFrom date".   e.g. We're not requiring a DNS implementation to track date/times outside of the DNSSEC protocol.

If others in the WG agree with adding this level of specificity for relying parties, we can reopen the document and add it. So far, no one else has expressed such interest. Warren can stop the current process and send the document back to DNSOP.


On 8/15/2024 4:58 AM, Petr Špaček wrote:
>> On 10. 08. 24 17:21, Michael StJohns wrote:
>>> On 8/9/2024 5:09 PM, Paul Hoffman wrote:
>>>> On Aug 9, 2024, at 12:16, Michael StJohns<[e-mail]>  wrote:
>>> Prior to this there was no check on the correctness of the offered digest, except that a smart relying party could have looked at the published keys and tried to find a match.  After this is published as an RFC, the relying part mostly only needs to look at the public key data in the file if it exists and not worry about whether it was published.  This is not "unchanged from RFC 7958" IMO.   Finally, reading this,  why wouldn't you explicitly specify that the hash needs to be  (e.g. MUST be) verified against either a live (published) key or the included public key?  Trust anchors require - well - trust.  I would think that the more verification I can get to avoid polluting my personal trust anchor store, the better. 
>>> 
>>>>> Looking at the Security Considerations - I don't think the updates to this section made this is sufficiently evident.
>>>> That's because this part of RFC 7958 was not updated in this draft.
>>> See above.
>>>>>    I'd suggest two things:  1) Talk about the above in the security considerations, and 2) Place a disclaimer in the TA file with similar language about the prospective key material.
>> 
>> From my perspective sect 3.2 last paragraph (quoted above) is sufficient to catch errors in data representation within the XML and with that protection we IMHO are in the same state as we were before: The relying party has to trust content of the file (for some reason). 
>> 
>> Maybe I'm missing something. Do you have a particular attack scenario which have not been possible before but becomes possible with the new format?
> Some preliminary stuff: RFC7958 was an independent submission -  a "this is how ICANN does this" document.  This version of the document is running through DNSOPS.   The former version was discussed, but I don't think it went through as rigorous a vetting.
> 1) Trust anchors in DNSSEC are the public keys, not DS or DNSKEY records representing the public keys even though those records may be used to carry the public keys.  Among other things, the flags and tags of a trust anchor may change (cf "revocation bit") during the lifetime of the key and a naive implementation with only DS like trust anchors could miss those changes.  (Yes, we can argue about this and 4035 says that DS's can be trust anchors - but 4035 assumed the flags would never change and 4035 assumed that section 5.2 will also come into play with respect to the DS records).
> 2) (1) basically implies that the hash you get from the XML may not be comparable to an actual live key. 
> 3) It also implies that the <KeyDigest> element needs a <Flags> element as well - or at least for keys that are not included in the <TrustAnchor> element.  (e.g. use the KeyDigest Flags field to calculate the digest over the public key regardless of what the DS or the live key says).
> To answer your question: The attack scenario is more a "someone screwed up and the key we just published didn't match up with the hash in the TrustAnchor file we published last month".  
> But I guess It could also be a malicious denial of service by an insider - especially if none of the keys have been published or included, and it *could* be an attempt to install a fake public key - harder to detect if all you have is the hash and all you're doing is attacking a few targets between the time the TA file is published and the keys are published.  If the party relying on the TA file just accepts it at face value (after verifying the signature), an attacker with the related private keys and ability to cut in between for DNS could do a pretty good job of lying to their target. 
> The security considerations section should actually discuss the various ways a third-party (ICANN) signed version of trust anchors could be used to pollute trust anchor stores if various internal controls aren't maintained.  It should also discuss how a relying party can validate the "consistency" of the data not just the signature over the data.
> And - IMHO - a relying party should not finalize adoption of a given TA until it sees it live.

IANA has already been publishing the trust anchor file with new keys well before the keys are in the published root zone. That seems to be what some DNS software developers want. If you want IANA to stop doing that, you can take it up with them and see what their community thinks.