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 <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:
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 ksk-rollo...@icann.org 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 <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.
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 <m...@nthpermutation.com> 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<m...@nthpermutation.com> 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.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
