From nobody Wed Nov 23 07:29:59 2022 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E824DC14F73A for ; Wed, 23 Nov 2022 07:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lor2NolafZP2 for ; Wed, 23 Nov 2022 07:29:54 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73D8C14F731 for ; Wed, 23 Nov 2022 07:29:53 -0800 (PST) Received: from [IPV6:2a02:768:2d1c:226:7d40:5e72:44a9:ea88] (unknown [IPv6:2a02:768:2d1c:226:7d40:5e72:44a9:ea88]) by mail.nic.cz (Postfix) with ESMTPSA id 93BA31C1807; Wed, 23 Nov 2022 16:29:49 +0100 (CET) Authentication-Results: mail.nic.cz; auth=pass smtp.auth=vladimir.cunat@nic.cz smtp.mailfrom=vladimir.cunat+ietf@nic.cz Content-Type: multipart/alternative; boundary="------------aLi9aPDFZKAW8q0NV00Fpnkx" Message-ID: Date: Wed, 23 Nov 2022 16:29:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Content-Language: cs, en-US To: dnsop@ietf.org References: <65d26b98-e0d6-e69b-10d4-17632451cab6@nic.cz> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Cc: Daniel Migault In-Reply-To: X-Virus-Scanned: clamav-milter 0.103.7 at mail X-Virus-Status: Clean X-Rspamd-Server: mail X-Rspamd-Queue-Id: 93BA31C1807 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.10 / 20.00]; BAYES_HAM(-5.00)[100.00%]; R_MIXED_CHARSET(1.00)[subject]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; ASN(0.00)[asn:44489, ipnet:2a02:768::/32, country:CZ]; RCVD_COUNT_ZERO(0.00)[0]; TAGGED_FROM(0.00)[ietf]; NEURAL_HAM(-0.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; TAGGED_RCPT(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; FREEMAIL_CC(0.00)[gmail.com] X-Rspamd-Action: no action Archived-At: Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2022 15:29:58 -0000 This is a multi-part message in MIME format. --------------aLi9aPDFZKAW8q0NV00Fpnkx Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit OK, thanks.  The changes are certainly improvements, in my eyes.  Below I'll further clarify what I meant. > 4033 indicates it does not make much sense to keep a RRSIG whose > validity period has expired ( TTL > Validity period). Yes, I should stress that I do agree with trimming TTL of whole RRset by expiration of RRSIG that's used to validate it, and there are good reasons for that.  I even had implemented that some time ago for Knot Resolver. As I wrote (perhaps unclearly), I was puzzled mainly by the recommendation that followed.  I'm failing to really understand what it meant exactly, and by what mechanism it's meant to ensure coherence (in some cases?).  And perhaps, how a validator operator could enforce such conditions without forking their validator. The line: > RRsets TTL SHOULD NOT exceed the DS, KSK or ZSK initial TTL value, > that TTL SHOULD trigger delegation revalidation as described in > {{!I-D.ietf-dnsop-ns-revalidation}}. > I agree we need to ensure good practice with 8624. > I do agree this might not be very very useful today, but the reason we > recommended this is also to ease communication between the resolvers > and authorities. My impression is that it is hard to change the > signature scheme on the authoritative side as we do not know what > resolver will support it. Recommendations for authoritatives are a bit tangential here.  I believe that RFCs (8624 or others) currently don't give a good idea about internet-wide support of resolvers for the algorithms, but you can find good measurements if you pay attention around IETF, OARC, etc.  Alg. 13 is widely used for some time, even on TLDs, but 15 seems unfortunately still rather "risky" (or recently was): https://www.potaroo.net/ispcol/2021-06/eddi.html > The question seems whether we should use such recommendations to > improve communication between authoritative and resolvers or favor a > more centralized approach where all software is more sticking to one > document 8624. That latter approach seems to me to have too long > cycles and I wished that we could benefit from new crypto ed25519 > earlier than when all resolvers are updated. Well yes, I'm in favor of keeping the supported-algorithm set centralized internet-wide, instead of trying to start deploying a decentralized mechanism. Validators don't need to talk to *authoritative* servers.  I believe it's quite common to have more than one layer of resolvers/caches, in which case an EDNS0 signal is just a bad mechanism, even if we somehow managed to deploy it widely.  (which wouldn't be easy, kinda similarly to widely deploying EdDSA validation) I mainly wanted to dissuade from early algorithm deprecation on validator side.  Validator operators might not understand that instead of validating a zone with a (supposedly) weak algorithm, they won't validate it at all.  So the only improvement is the AD=1 bit which gets stricter by that, but most use cases don't even look at that bit and only rely on the protection by SERVFAILs. > I am surprised  you would not recommend RFC 5011 5011 needs persistent state, a thing that resolvers/validators often don't need at all otherwise (cache is safe to delete).  5011 doesn't always work, so you need to combine with some fallback mechanism(s) anyway - for new installations and for stale ones (missed rotation).  Root rollover has happened only once in history, non-root TAs aren't that common, and 5011 algorithm isn't very simple, so the code can easily get some bugs without anyone noticing until it's too late. Lots of down-sides, so I rather put the TAs into SW updates, for the root TA case at least.  I'd recommend trying to avoid non-root TAs, but if I had to choose, I'd put them into configuration. Again a thing that I have to provision *anyway*, so I get the occasional TA updates basically for free, without needing to worry about those 5011 disadvantages.  (occasional = 5011 defaults to requiring 30 days of overlap) --Vladimir --------------aLi9aPDFZKAW8q0NV00Fpnkx Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

OK, thanks.  The changes are certainly improvements, in my eyes.  Below I'll further clarify what I meant.


4033 indicates it does not make much sense to keep a RRSIG whose validity period has expired ( TTL > Validity period).

Yes, I should stress that I do agree with trimming TTL of whole RRset by expiration of RRSIG that's used to validate it, and there are good reasons for that.  I even had implemented that some time ago for Knot Resolver.

As I wrote (perhaps unclearly), I was puzzled mainly by the recommendation that followed.  I'm failing to really understand what it meant exactly, and by what mechanism it's meant to ensure coherence (in some cases?).  And perhaps, how a validator operator could enforce such conditions without forking their validator.  The line:

RRsets TTL SHOULD NOT exceed the DS, KSK or ZSK initial TTL value, that TTL SHOULD trigger delegation revalidation as described in {{!I-D.ietf-dnsop-ns-revalidation}}.



I agree we need to ensure good practice with 8624. 
I do agree this might not be very very useful today, but the reason we recommended this is also to ease communication between the resolvers and authorities. My impression is that it is hard to change the signature scheme on the authoritative side as we do not know what resolver will support it.
Recommendations for authoritatives are a bit tangential here.  I believe that RFCs (8624 or others) currently don't give a good idea about internet-wide support of resolvers for the algorithms, but you can find good measurements if you pay attention around IETF, OARC, etc.  Alg. 13 is widely used for some time, even on TLDs, but 15 seems unfortunately still rather "risky" (or recently was): https://www.potaroo.net/ispcol/2021-06/eddi.html



The question seems whether we should use such recommendations to improve communication between authoritative and resolvers or favor a more centralized approach where all software is more sticking to one document 8624. That latter approach seems to me to have too long cycles and I wished that we could benefit from new crypto ed25519 earlier than when all resolvers are updated.
Well yes, I'm in favor of keeping the supported-algorithm set centralized internet-wide, instead of trying to start deploying a decentralized mechanism.

Validators don't need to talk to *authoritative* servers.  I believe it's quite common to have more than one layer of resolvers/caches, in which case an EDNS0 signal is just a bad mechanism, even if we somehow managed to deploy it widely.  (which wouldn't be easy, kinda similarly to widely deploying EdDSA validation)

I mainly wanted to dissuade from early algorithm deprecation on validator side.  Validator operators might not understand that instead of validating a zone with a (supposedly) weak algorithm, they won't validate it at all.  So the only improvement is the AD=1 bit which gets stricter by that, but most use cases don't even look at that bit and only rely on the protection by SERVFAILs.



I am surprised  you would not recommend RFC 5011

5011 needs persistent state, a thing that resolvers/validators often don't need at all otherwise (cache is safe to delete).  5011 doesn't always work, so you need to combine with some fallback mechanism(s) anyway - for new installations and for stale ones (missed rotation).  Root rollover has happened only once in history, non-root TAs aren't that common, and 5011 algorithm isn't very simple, so the code can easily get some bugs without anyone noticing until it's too late.

Lots of down-sides, so I rather put the TAs into SW updates, for the root TA case at least.  I'd recommend trying to avoid non-root TAs, but if I had to choose, I'd put them into configuration.  Again a thing that I have to provision *anyway*, so I get the occasional TA updates basically for free, without needing to worry about those 5011 disadvantages.  (occasional = 5011 defaults to requiring 30 days of overlap)


--Vladimir

--------------aLi9aPDFZKAW8q0NV00Fpnkx--