[dnsext] Re: [Technical Errata Reported] RFC4035 (8037)

[Elias Heftrig <[e-mail]>]

Hi Scott,

as I take it from the IETF120 hallway discussions on the errata an 
update to the RFCs is a viable way to deal with these flaws as well. 
Since updates seem to take quite a while until published, the errata, as 
reported, offer some benefit of warning new implementers about the flaws 
in the meantime (albeit their visibility being somewhat limited). 
Serving that purpose, from my own perspective, an errata status of "Held 
for Document Update" might be the way to go, or else a "Rejected", but 
with a very clear comment that the reported flaws (errata 8037 and 8038) 
are in fact an issue and need to be dealt with by an update to the 
according RFCs. "Held for Document Update" might be a bit clearer in 
that regard.

If I missed out on any discussions behind the scenes and things have 
become clearer in the meantime, please don't hesitate to send me an update.

Thanks much,

Elias




On 19.07.24 15:31, Rose, Scott W. (Fed) wrote:
> Elias,
> My question was more IETF process than technical and how best to do the update so it won’t cause confusion to resolver and validator implementors.  Since this is a validation logic flaw and not just a query issue.
>
> Additionally, if the WG (or community at this point, since the DNSEXT WG is basically concluded) thinks there should be a draft to clarify things that might be better in the long run but not for the change needed to address the KeyTrap vulnerability right now.  Or can the errata process be used to fix a discovered flaw in the protocol RFC if the RFC reflects the original consensus?
>
> Unfortunately, I won’t be at the IETF in person due to budget constraints. I will be following virtually.
>
> Scott
>
> On 18 Jul 2024, at 16:49, Elias Heftrig wrote:
>
>> Hey Scott, the issue is in fact pretty fundamental:
>>
>> Aside from the load implied by NSEC3 iteration counts and a general warning about DoS-by-crypto attacks in the security considerations of RFC4033, the CPU resource requirements of validation have not been addressed much by the DNSSEC specification. Other than that there is a general instruction for DNS resolvers in RFC1035 (Section 7.1.) to "limit the amount of work", which a resolver will do in response to a client request (contextualized with retransmissions, timeouts and circular CNAMEs). However, a) the question is how much that would apply to other DNSSEC validators (a DANE client, possibly?); and b) the number of validations is technically already "limited" (in a "non-infinite" sense) by transport constraints - though obviously not limited to a sufficient degree.
>>
>> In any case it appears reasonable to extend the basic approach of the RFC1035 requirement to DNSSEC validation as well, and a fair share of the patches to CVE-2023-50387 do so, but that entails a whole bunch of follow-up questions: What are the implications of introducing such limits (currently chosen locally at deployments!) on the resolver/domain sides and for scalability of DNS as well as future protocol development...? How much should specification regulate resource consumption at implementations in the first place? If we introduce per-query limits to the specification, how should they be quantified? There would certainly be enough material to fill an RFC on the regulation of DNSSEC validation CPU requirements, though at the risk of adding a (prohibitive) lot of complexity to an already complex protocol.
>>
>> Before I go down the rabbit hole here: We will be attending IETF120 next week and are having a talk on this topic at the co-located ANRW ("Protocol Fixes for KeyTrap Vulnerabilities"). If anyone of you is attending IETF120 as well, we would love to hear your opinion and discuss matters with you there.
>>
>>
>> Regarding the proposed errata:
>>
>> The requirement to try all possible DNSKEYs and the requirement to validate all RRsets in an ANY-type answer (see the additional erratum 8038 for RFC6840) are both MUST requirements. Since they are "absolute specification requirements" (RFC2119) and imply an (un-)certain amount of work, it appears imperative demoting them to SHOULD.
>>
>> Furthermore, supported by the abundance of implementations, which were vulnerable to CVE-2023-50387, a rigorous specification-side guidance on limiting CPU resource consumption - or at least a clear word of warning located at the relevant requirements in the specification - would certainly be beneficial. (Honorable mention here: RFC6840 Section 5.4 "a resolver SHOULD [...] only determine that an RRset is Bogus if all RRSIGs fail validation.")
>>
>> Arguably, MUST requirements (and SHOULD, to a degree) should be "no-brainers", at least to the extent of not being harmful if they are followed literally.
>>
>> Best, Elias
>>
>> On 18.07.24 19:03, Rose, Scott W. (Fed) wrote:
>>> So would the process here be to have an update to RFC 4045?  It sounds like it.  Plus that gives space to provide more guidance to implementors that just “SHOULD”.  For instance - is there an upper bound on the number of keys tried?
>>>
>>> I know that sounds like a lot of overhead for changing what is one keyword at first, but I think this might deserve more than just changing a MUST to a SHOULD.
>>>
>>> Scott
>>>
>>> On 18 Jul 2024, at 12:39, Rob Austein wrote:
>>>
>>>> This is interesting, but I don't think it's an erratum. The text says what the WG intended: if one is attempting to validate the signature, one MUST try them all until one succeeds or one runs out of keys to try.  I believe the reporter is requesting a technical change based on recent analysis, which is a worthy topic for discussion but is not an erratum. Take it to the WG.
>>>> -- 
>>>> Sent from a phone, please excuse typos and brevity
>>> =====================================
>>> Scott Rose
>>> NIST/CTL/WND
>>> [e-mail]
>>> ph: 301-975-8439
>>> GoogleVoice: 571-249-3671
>>> =====================================
>
> =====================================
> Scott Rose
> NIST/CTL/WND
> [e-mail]
> ph: 301-975-8439
> GoogleVoice: 571-249-3671
> =====================================