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

[Michael StJohns <[e-mail]>]

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.

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

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


Trimming...

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.

>
>> 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.
>
> As an implementer I say it's easier if the format is the same as in 
> DNS, i.e. unsigned decimal number. It allows me to simply reformat 
> elements from the XML into a DNSKEY text representation and _then_ run 
> existing DNS code to parse the (reformatted) DNSKEY text.
>
> Bit field represented as sequence of ASCII 0/1 would require 
> additional code and I don't see any benefit. Common DNS tools display 
> Flags field as an integer value so even for manual cross-checking by 
> hand (say XML text vs. dig output) it is better to use the same 
> representation.
>
As I said a minor nit and not a hill I want to die on.  But your last 
comment: XML parsers either know how to do all of the xsd: stuff or none 
of it.  Converting from an xml parsed 2 byte field into a UINT16 is a 
line of code.

Later, Mike