[DNSOP] Re: [Ext] Dnsdir last call review of draft-ietf-dnsop-rfc7958bis-03

[Petr Špaček <[e-mail]>]

 >>> snip <<< I removed the parts where we understood each other.

On 01. 08. 24 2:28, Paul Hoffman wrote:
>>> 2.4. Converting from XML to DNSKEY Records
>>> The published trust anchor does not provide values for DNSKEY protocol or
>>> flags. For the purpose of this mechanism, clients can assume valid trust
>>> anchors will be have the ZONE and SEP flag bits set to 1.
>> I think it is extremely bad idea to ignore fields, especially Flags. There are
>> various proposals for new DNSKEY flag usage in the DD WG.
>>
>> Even if we say that DD WG will go down in flames before it produces anything I
>> think it's_extremely_  bad idea to omit pieces of information and assume that
>> client can reliably fill in missing pieces with constants. I would say that the
>> missing DNSKEY fields really really must be represented explicitly. (E.g. I
>> don't want to go down the rabbit hole of all REVOKE flag corner cases.)
> I don't understand how the quoted text suggests that users of the zone file ignore fields or flags. Can you suggest text to fix your concern?

Specifically:
 > clients can assume valid trust anchors will be have the ZONE and SEP 
flag bits set to 1.

This text ignores all non-{ZONE,SEP} flags. Readers have no instruction 
about the _other_ flags, and in a hypothetical future, TA can 
conceivably have one or more of these extra flags set. E.g. a new flag 
for DELEG downgrade resistance which is under discussion in the DD WG. 
Will we need update the format again? (I think that would be wrong.)

I think absence of explicit Flags field is unnecessary shortcut which 
will just bite us down the road (or force document & software update).

My proposal is to do one of:
a) get rid of PublicKey element completely (see below)
b) include explicit XML element with Flags - and when we are at it we 
can add Protocol element as well for completeness.

>> On high level I also find confusing that the new element is optional - that
>> makes it unreliable for consumers because there are no rules for when it might
>> or might not be present.
> It is optional because some signing mechanisms don't automatically generate DNSKEY values. For example, the current trust anchor file only has the DS of KSK-2024 because IANA needs to make a software change to get the DNSKEY (which it will do in a few months). Other HSMs might be similar. A DS has always been sufficient; a DNSKEY would be an upgrade, but is not necessary.

A trust anchor with nonexistent DNSKEY representation is not usable in 
DNSSEC because nobody can validate signatures made with it, is that 
correct? If so, why such keys need to be represented in this format?

An alternative angle:
Why is the new PublicKey element even needed? There's no guarantee it 
will be ever present which makes it unusable - no software can _rely_ on 
it's presence. I.e. it does not seem useful while it introduces new 
nasty corner cases.

Or yet another wording of the same problem:
Under what conditions software reading file in this format _needs_ the 
PublicKey element and cannot do with the mandatory fields?

I find
 > It can be useful when IANA has a trust anchor that has not yet been 
published in the DNS root.
too vague to justify that we need the _optional_ PublicKey element which 
might or might not be present, with and all the trouble it adds.


>> Also there are no rules for what to do when reconstructed DS and DNSKEY don't
>> match - which can totally happen given the half-representation we have in the
>> current version.
> Fully agree; we will add words to say in such a case the specific key should not be trusted.
> 
>> Is there implementation experience with the new format? What was the
>> implementer feedback?
> We have heard informally that some implementers have added the new features with no problems, but they obviously can't test it until there is a new trust anchor file from IANA, and that's waiting on the standard to be published.

Surely it can be tested with mock keys.

Is there some feedback about PublicKey field usage? Under what 
conditions it is needed?

aka "RFC 1925 Truth (12)".

>> TL;DR there are issues which can be addressed with smallish amendments.
> Thanks! Please see above for requests for additional wording in places where I don't understand the concern. The other bits will be added after the IETF Last Call is finished.

I've tried to clarify above. Does that help to understand the trouble 
with PublicKey element as proposed?

-- 
Petr Špaček
Internet Systems Consortium