Message-ID: <473d8daf-ca85-4a6c-8e36-2d300c574807@isc.org>
Date: Fri, 2 Aug 2024 11:14:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Paul Hoffman <paul.hoffman@icann.org>
References: 
 <172242543510.2137530.14005988379230936314@dt-datatracker-659f84ff76-9wqgv>
 <C5054E75-79B2-4BDF-BA77-60CEB6479AC2@icann.org>
 <a8c98c83-9af9-4c0b-baef-199e57abf96b@isc.org>
 <4B662AEC-B546-4376-9945-F045F4A0B5D4@icann.org>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <pspacek@isc.org>
Content-Language: en-US
Autocrypt: addr=pspacek@isc.org; keydata=
 xsFNBF/OJ/4BEAC0jP/EShRZtcI9KmzVK4IoD/GEDtcaNEEQzPt05G8xtC0P4uteXUwW8jaB
 CdcKIKR4eUJw3wdXXScLNlyh0i+gm5mIvKPrBYNAMOGGnkbAmMQOt9Q+TyGeTSSGiAjfvd/N
 nYg7L/KjVbG0sp6pAWVORMpR0oChHflzKSjvJITCGdpwagxSffU2HeWrLN7ePES6gPbtZ8HY
 KHUqjWZQsXLkMFw4yj8ZXuGarLwdBMB7V/9YHVkatJPjTsP8ZE723rV18iLiMvBqh4XtReEP
 0vGQgiHnLnKs+reDiFy0cSOG0lpUWVGI50znu/gBuZRtTAE0LfMa0oAYaq997Y4k+na6JvHK
 hhaZMy82cD4YUa/xNnUPMXJjkJOBV4ghz/58GiT32lj4rdccjQO4zlvtjltjp9MTOFbRNI+I
 FCf9bykANotR+2BzttYKuCcred+Q7+wSDp9FQDdpUOiGnzT8oQukOuqiEh3J8hinHPGhtovH
 V22D0cU6T/u9mzvYoULhExPvXZglCLEuM0dACtjVsoyDkFVnTTupaPVuORgoW7nyNl0wDrII
 ILBqUBwzCdhQpYnyARSjx0gWSG1AQBKkk5SHQBqi1RAYC38M59SkpH0IKj+SaZbUJnuqshXh
 UIbY1GMHbW/GDhz7pNQFFYm2S4OPUBcmh/0O0Osma151/HjF7wARAQABzR9QZXRyIMWgcGHE
 jWVrIDxwc3BhY2VrQGlzYy5vcmc+wsGXBBMBCABBAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4B
 AheAAhkBFiEEEVO2++xeDVoSYmDzq9WHzfBlga4FAmWT+REFCQelsxMACgkQq9WHzfBlga7y
 2Q//Ug58UI9mlnD/guf9mHqpJIMrBs/vX8HlzylsDcZUBTp2TJpzNh/CygPWrHY+IvA9I9+t
 Ygp0sB+Z9OtVZgW3bpWJ0iWe6N89Q0kwOuhJ75LsfR1V73L5C826M6bLQjYTj6HiwS9Nf+N0
 jADhEV/p1KtCuZfwBkYJ4ZM+Na0zWerGPkGw9T9O0gfs0ePehzJ5V0OK0nCqMuC1h8o/rhCb
 vRCmxdAbNjrOrgKa7HN5DadP/tKstJMM09aXlT5q96fRIyCQyqXQoCrijCWvgAxgjABdh1TB
 /XsYvBC8+4wy5ZBtTcnxXGrMhrSxU2/vIK6RjDju7OIRClMNepEzvt0gNzxwwxIXVOzl5ioC
 i/Okovk1rZneFFxbVvaMyIJgY/hShJV7Ei+5S9UZUv6UUmRQ6zukeiSVZrtXs6fWLVlUnBDl
 Cv/fXi25hrymqNfPSBSB0tyc6YepR1Rq9omTni6DYmEHQuhPMHJ2fuiNNyBaH+9EI7go5e0J
 LvXVLJGXkMdTcmYHja1pDjmQ1K71gewfPWGFmn0JTa92GuZJaR/4MVePvoV0NTpCP0HiKIg5
 0+AOdpvkJReFKTQOX08SwkUkgvy9h9WjBMpD5ymMs4gjJwXtcT1+aVtj9Xcw6tQde9Yyjxde
 a6UZ3TUfys8qZ8ZKmMKTaCUFukKzWDJMZ91V1b/OwU0EX84n/gEQANARNXihDNc1fLNFZK5s
 O14Yg2TouK9eo9gGh4yLSrmZ3pjtnuJSpTWmGD4g0EYzhwWA/T+CqjUnrhsvzLQ1ECYVqLpM
 VqK2OJ9PhLRbx1ITd4SKO/0xvXFkUqDTIF6a5mUCXH5DzTQGSmJwcjoRv3ye+Z1lDzOKJ+Qr
 gDHM2WLGlSZAVGcUeD1S2Mp/FroNOjGzrFXsUhOBNMo8PSC4ap0ZgYeVBq5aiMaQex0r+uM4
 45S1z5N2nkNRYlUARkfKirqQxJ4mtj5XPC/jtdaUiMzvnwcMmLAwPlDNYiU0kO5IqJFBdzmJ
 yjzomVk1zK9AYS/woeIxETs+s6o7qXtMGGIoMWr6pirpHk4Wgp4TS02BSTSmNzParrFxLpEU
 dFKq3M0IsBCVGvfNgWL2pKKQVq34fwuBhJFQAigR9B3O9mfaeejrqt73Crp0ng0+Q74+Llzj
 EIJLOHYTMISTJyxYzhMCQlgPkKoj+TSVkRzBZoYFkUt4OXvlFj73wkeqeF8Z1YWoOCIjwXH9
 0u2lPEq0cRHHyK+KSeH1zQJ4xgj0QDGPmkvi81D13sRaaNu3uSfXEDrdYYc+TSZd2bVh2VCr
 xrcfzQ1uz9fsdC9NPdNd7/mHvcAaNc5e9IhNh67L54aMBkzlJi18d0sWXOOHkyLSvbHnC/OP
 wv7qCf69PUJmtoeHABEBAAHCwXwEGAEIACYCGwwWIQQRU7b77F4NWhJiYPOr1YfN8GWBrgUC
 ZZP5UgUJB6WzVAAKCRCr1YfN8GWBrgxpD/949Tz7EtrE9e2yJ4np+y7uW8EDusVM3QsBdkYk
 yaQTupITew8WWQtNF/QK/MKRi+e/382t78nBq+T7G9PrRi7E4WS9dXdgJiFz25h3mC4TABJZ
 b6MLcEreLWTaqnR/D6F3AnNXh7GJFY4E6PAwC60W0R9G6R0E+2XeZX011NEGiBMvgZnqzzjU
 L9h8Gz7a/EsQync4cvLbruPt/UaOV0khKTefsOFj3q3wLY6qN2qw7HfgFRBCh6ME2XRvnwAd
 iv0pF4HRbXoFalkAsNEYkWQ6mkJjdYCHOWm3TWqXhalgGKqIOrQyMpH2mJpZllKBQiBiQMUz
 qz0cO9OqBk3xvNLplI3VNcC0WeQ8LEqyYKth2T78hVaIw8K0IcVmZQwXVxL03gojaJ5bK2O+
 2FfqKMcIiU+bqaTXntx+FYRQKblsUBYD77uU9sPVyKWIiHvukLTx7GY1ttn6gZDSIek/tTR7
 oaei+xLh5JUgZpMZ4JHnirDWHbrJzYN95e8HWA/+qAOTsa+igZGsc6yA1oJIAnCwkclcLAgc
 x3GVVeEL+/b9CugZ+1OfbxlRK7gAeu0kyKiEXrUvCQPnPByIIfj4I4IvZO4552cmmnbn31f9
 X/9nw+M4qAqOK7bRg65ucv71TayUehNJrfJSYx6P1tXIwzu19tIgtdWTcsszNWALfaUFtg==
In-Reply-To: <4B662AEC-B546-4376-9945-F045F4A0B5D4@icann.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: VJMHU3OIJ6ZCNLZORYL44PQNQHN4VPPV
CC: "dnsdir@ietf.org" <dnsdir@ietf.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>,
 "draft-ietf-dnsop-rfc7958bis.all@ietf.org"
 <draft-ietf-dnsop-rfc7958bis.all@ietf.org>,
 "last-call@ietf.org" <last-call@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_=5BExt=5D_Dnsdir_last_call_review_of_draft-ietf-?=
	=?utf-8?q?dnsop-rfc7958bis-03?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dnsop/KU7khi1ZSoZn5cEfS5gqgYRh5Yk>

On 02. 08. 24 2:41, Paul Hoffman wrote:
> On Aug 1, 2024, at 06:37, Petr =C5=A0pa=C4=8Dek <pspacek@isc.org> wrote=
:
>>>>> 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 proto=
col 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 as=
sume that
>>>> client can reliably fill in missing pieces with constants. I would s=
ay 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 case=
s.)
>>> I don't understand how the quoted text suggests that users of the zon=
e 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 instructio=
n about the _other_ flags, and in a hypothetical future, TA can conceivab=
ly have one or more of these extra flags set. E.g. a new flag for DELEG d=
owngrade 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).
>=20
> I'm still not understanding the need here. The flags are included in th=
e calculation for the DS record, which is mandatory in the file format.

Here are two examples where missing Flags cause trouble:

Example 1. Imagine that one of the historical TAs will get revoked.=20
Revocation sets REVOKE bit=3D1, along with a validUntil date set to the=20
past. Now the current format would contain DS hash which does not match=20
the reconstructed DNSKEY RR.

Standardizing a format which by definition leads to internally=20
inconsistent data fields sounds like a had idea to me.


Example 2. Non-REVOKEd flag - based on=20
draft-ietf-dnsop-delegation-only-02.txt:
Say that a future TA has DNSKEY flags ZONE + SEP + DELEGATION_ONLY set=20
to 1. Such TA cannot be represented correctly as DNSKEY using the=20
proposed format because the proposal assumes only ZONE + SEP bits are=20
ever set to 1. Again, DS hash and the reconstructed DNSKEY would not matc=
h.

In other words, the current proposed format ossifies DNSKEY flags for TAs=
.

>> 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 whe=
n it might
>>>> or might not be present.
>>> It is optional because some signing mechanisms don't automatically ge=
nerate 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 t=
he 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 n=
ot necessary.
>>
>> A trust anchor with nonexistent DNSKEY representation is not usable in=
 DNSSEC because nobody can validate signatures made with it, is that corr=
ect? 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?
>=20
> Some software vendors complained that they needed the full DNSKEY for t=
he trust anchors. They could not use the file: they had to wait for the D=
NSKEY records to appear in the root zone. At least one of those vendors s=
craped the ceremony materials to find the DNSKEY to use as their trust an=
chor before the record appeared in the root zone.

Fair enough, I can imagine that. But then the question is:

Why is the field _optional_ (besides problem with missing Flags)? That=20
renders the proposed format potentially unusable (or at least=20
unreliable) for the software which cannot work with DS only.


>> I find
>>> It can be useful when IANA has a trust anchor that has not yet been p=
ublished in the DNS root.
>> too vague to justify that we need the _optional_ PublicKey element whi=
ch might or might not be present, with and all the trouble it adds.
>=20
> That might be true for your own implementation, but it was requested an=
d accepted by the WG.

Or maybe it was just an oversight? dnsop archives here:
https://mailarchive.ietf.org/arch/browse/dnsop/?q=3Drfc7958bis%20publicke=
y
do not show any discussion of publicKey element _semantics_, or it's=20
purpose, or when and why it should be present.

Perhaps my dnsop filter is incomplete and there was a discussion I could=20
not find?

>>>> Also there are no rules for what to do when reconstructed DS and DNS=
KEY don't
>>>> match - which can totally happen given the half-representation we ha=
ve 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 fe=
atures 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 conditi=
ons it is needed?
>>
>> aka "RFC 1925 Truth (12)".

--=20
Petr =C5=A0pa=C4=8Dek
Internet Systems Consortium