[DNSOP] Re: [Ext] [Technical Errata Reported] RFC8624 (8144)
This is a purposely technical change to the document, and thus should be rejected. It is not an errata at all. The correct way to ask for a technical change such as this is to first ask the DNSOP WG, then possibly write a draft. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] DNSOPPossible breaking inconsistencies in draft-ietf-dnsop-rfc8624-bis-01
On Oct 15, 2024, at 10:30, Peter Thomassen wrote: > On 10/15/24 19:02, Paul Hoffman wrote: >>>> In specific, "Use for DNSSSEC Signing" and "Use for DNSSSEC >>>> Delegation" do not make sense if there is more than one "MUST" in that >>>> column. You cannot use two algorithms to sign or delegate at the same >>>> time. > > I think you misread, Paul; the second column is "use for validation" (not > delegation). I think I did not. The draft adds "Use for DNSSEC Delegation" to the table in section 4. That column in that table has the same "MUST but MAY" problem I brought up. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] DNSOPPossible breaking inconsistencies in draft-ietf-dnsop-rfc8624-bis-01
On Oct 15, 2024, at 07:49, Wes Hardaker wrote: > > Paul Hoffman writes: > >> In specific, "Use for DNSSSEC Signing" and "Use for DNSSSEC >> Delegation" do not make sense if there is more than one "MUST" in that >> column. You cannot use two algorithms to sign or delegate at the same >> time. > > Thank you for the analysis. I think there are three (obvious) paths forward: > > 1. Define what MUST means in the context for the Use columns. > 2. Use RECOMMENDED instead. > 3. Only allow a single MUST in the Use column because that's what we want > people to really use (which does sound more like a SHOULD). IE, if we > believe ideally there should be one cryptographic algorithm deployed to > simplify the deployed base, we could pick this route. I doubt it would be > popular though, as we already have a fractured ecosystem and it is generally > working. > > Feedback from the WG appreciated :-) Yes, please! My preference would be #2. If we do #1, it will not match what most IETFers think of "MUST". #3 seems like it would increase ossification, which is the opposite direction from what the IETF is moving. >> How can both 8 and 13 be "MUST use for signing" at the same time? > > Do note that this problem actually isn't new, technically. We disagree. > The values > we pick basically mirror 8624 but 8624 really didn't talk about recommending > *usage* which is what the discussion around this document clearly picked up. It always made sense to say to implementers that they must implement more than one algorithm in their products. The current draft basically adds "and you have to use more of them at the same time, but we can't say how". > Note that 8624 has this to say as well: > > [RFC2119] considers the term SHOULD equivalent to RECOMMENDED, and > SHOULD NOT equivalent to NOT RECOMMENDED. The authors of this > document have chosen to use the terms RECOMMENDED and NOT > RECOMMENDED, as this more clearly expresses the intent to > implementers. > >> How can 14 and 16 be "MAY use for signing" if there are other values >> that MUST be used instead? > > I think that switching to "RECOMMENDED" from "MUST" may solve your concerns? It would, but let's see what the rest of the WG says. (It still would be good to add a sentence or two saying "when there are multiple recommended algorithms in the "use" column, you get to choose the one you want based on local policy". >> Is 15 more recommended than 14 and 16 even though 14 and 16 are >> currently obviously stronger? > > There is no intent to do algorithm comparisons by values encoded in the > columns. I think that's more what Steve and Russ' document are likely > targeting. More importantly, I don't think we should have comparison text > and each row should stand alone. In that case, I request that 14, 15, and 16 be at the same level for "use". It is a bad smell for the WG to say "this weaker algorithm is better for reasons we are not saying". > If you have specific concrete suggestions for value changes, it would be > helpful but do note our goal was to do value changes generally in follow on > documents. We had to break that a little bit because we doubled the number > of recommended columns by adding the "Use" ones. We can't break it "a little bit". The recommendations in this document are all of equal importance. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Possible breaking inconsistencies in draft-ietf-dnsop-rfc8624-bis-01
On Oct 12, 2024, at 09:20, Steve Crocker wrote: > You wrote, "You cannot use two algorithms to sign or delegate at the same > time." If there are two or more independent signers for a zone -- see RFC > 8901 -- then multiple algorithms might be in use at the same time. > > I think there is some wording that says the algorithms must be the same, I > believe there is an effort to remove that restriction. If there are multiple > signers, each of them will likely change the algorithm it uses, so it's > necessary to permit the concurrent use of distinct algorithms. This would mean that the draft's use of "MUST" means "MUST be one of these". If so, that should be stated. But even if that is so, it still contradicts the idea there can be both MUST and RECOMMENDED or MAY in the column. > With respect to MUST, etc., I'm not a big fan of these designations in this > context, but the terms are deeply embedded in the RFC culture and impossible > to avoid. That said, both 8624-bis and our lifecycle document anticipate > there may be multiple acceptable algorithms to use at any one time. Indeed, > in order to support transitions from one algorithm to another, use of > multiple algorithms concurrently is necessary. If those words don't work for us, then we can make up different words. Or use symbols that translate to rules that are not inherently self-contradictory. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Possible breaking inconsistencies in draft-ietf-dnsop-rfc8624-bis-01
Earlier, Wes said "I believe the 8624bis document is functionally "done" and should be published." However, there has been too little discussion on what the new columns actually mean, and someone reading the new IANA registries would not know what to do. In specific, "Use for DNSSSEC Signing" and "Use for DNSSSEC Delegation" do not make sense if there is more than one "MUST" in that column. You cannot use two algorithms to sign or delegate at the same time. Table 2 is for "Domain Name System Security (DNSSEC) Algorithm Numbers". It reads in part: +==+===+===+===+===+===+ |N |Mnemonics |Use for|Use for|Implement |Implement | | | |DNSSEC |DNSSEC |for DNSSEC |for DNSSEC | | | |Signing|Validation |Signing|Validation | +==+===+===+===+===+===+ +--+---+---+---+---+---+ |8 |RSASHA256 |MUST |MUST |MUST |MUST | +--+---+---+---+---+---+ |10|RSASHA512 |NOT|MUST |NOT|MUST | | | |RECOMMENDED| |RECOMMENDED| | +--+---+---+---+---+---+ |13|ECDSAP256SHA256|MUST |MUST |MUST |MUST | +--+---+---+---+---+---+ |14|ECDSAP384SHA384|MAY|RECOMMENDED|MAY|RECOMMENDED| +--+---+---+---+---+---+ |15|ED25519|RECOMMENDED|RECOMMENDED|RECOMMENDED|RECOMMENDED| +--+---+---+---+---+---+ |16|ED448 |MAY|RECOMMENDED|MAY|RECOMMENDED| +--+---+---+---+---+---+ How can both 8 and 13 be "MUST use for signing" at the same time? How can 14 and 16 be "MAY use for signing" if there are other values that MUST be used instead? Is 15 more recommended than 14 and 16 even though 14 and 16 are currently obviously stronger? Without more description of what the new columns mean, a reader of the IANA registry will have no idea what to use when choosing a signing algorithm. The same is true for the new column in the DS table. Either there has to be definitions of the terms above the new tables at IANA, or a pointer to a concise description of the terms in an RFC, such as in a short appendix in this draft. However, I still don't see how defining these terms using the normal use of MUST in the IETF would make sense for this new column. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] draft-crocker-dnsop-dnssec-algorithm-lifecycle-01
On Oct 4, 2024, at 12:24, Russ Housley wrote: > > This document is related to draft-ietf-dnsop-rfc8624-bis. We ask the DSNOP > WG to adopt it. I support the adoption of this document before the WG finishes with draft-ietf-dnsop-rfc8624-bis. The two are tightly related, and might even be combined. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Call for Adoption: draft-huque-dnsop-grease
I support WG adoption of this draft. After adoption, we can start filling in some of the holes, but the idea that is covered and the structure of the draft seem fine. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] [EDE] Registering a few more error codes
On Sep 11, 2024, at 06:22, Stephane Bortzmeyer wrote: > > In the current registry for Extended DNS Error Codes (RFC 8914), there > are codes that may be interesting to add: > > * One to say that the response was deliberately minimal (RFC 8482) > * One to say that the response comes from a local root (RFC 8806) > * One to say that the response has been tailored because of ECS (RFC > 7871) [the most useful, IMHO] > > I am thinking about asking for a registration. Policy for this > registry is "first come, first served". Before I start sending email > to IANA, I ask your advice. Is it a good idea? Will the authors of > resolver / authoritative software use it? Personally, I like the first and third, and can see value for receivers for them. The second seems like a diagnostic, and one that would rarely be used because it would only be relevant for queries about TLDs. As much as I like RFC 8806, I don't think having minimal and possibly bad data about it would help anyone. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] [RESINFO] Registering a "DNSSEC validation" resolver information key?
This is an interesting proposal, but it should instead be sent to the ADD WG, given that RFC 9606 and friends came from there, not DNSOP. --Paul Hoffman On Sep 11, 2024, at 05:36, Stephane Bortzmeyer wrote: > > In the current registry for DNS Resolver Information Keys (RFC 9606), > there is no key to indicate that the resolver validates with > DNSSEC. For me, it is an important criterion to evaluate a resolver. > > I am thinking about asking for a registration. Policy for this > registry is "specification required". Before I start writing one, I > ask your advice. Is it a good idea? Will managers of resolvers use it? > Or do we assume that any serious resolver validates anyway? > > Short proposal for the specification: > > dnssecval: The presence of this key indicates that the DNS resolver > validates all answers with DNSSEC [RFC4033][RFC4034][RFC4035]. Note > that, per the rules for the keys defined in Section 6.4 of [RFC6763], > if there is no '=' in a key, then it is a boolean attribute, simply > identified as being present, with no value. > > (And advise that exterr should then include the EDE for DNSSEC?) ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Dnsdir telechat review of draft-ietf-dnsop-rfc7958bis-05
> Authors, please integrate these. Done in the -06, just published. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.
On Aug 27, 2024, at 16:46, Warren Kumari wrote: > > Thank you very much for your comments. We've had some discussions, and the > authors will be publishing a new version in the next few days addressing > these. As you can see, we have turned in -05. We think this deals with the comments from Petr and Mike. In the diff, you can see that we moved all things that said what a relying party who accepts the trust anchor file MUST/SHOULD do to the Security Considerations; this puts them in one place and gives the context for them. We also added some text about how to do the comparison for the two fields (referring to the specific part of RFC 4034 that they need). Given that this is still in your (Warren's) two hands, not the WG's many hands, let us know if you need any more changes before the assigned telegchat. --Paul Hoffman (for the authors) ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.
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 wrote: > > On 8/9/2024 5:09 PM, Paul Hoffman wrote: >> On Aug 9, 2024, at 12:16, Michael StJohns 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 irr
[DNSOP] Re: [Ext] Intdir telechat review of draft-ietf-dnsop-rfc8109bis-06
Thanks for the review! Those nits are the kind of thing the RFC Editor picks up, so unless we have to revise the document for the IESG, we'll let them catch them during the editorial process. --Paul Hoffman On Aug 19, 2024, at 06:23, Dirk Von Hugo via Datatracker wrote: > > Reviewer: Dirk Von Hugo > Review result: Ready with Nits > > Dear all, > I am an assigned INT directorate reviewer for draft-ietf-dnsop-rfc8109bis. > These comments were written primarily for the benefit of the Internet Area > Directors. Document editors and shepherd(s) should treat these comments just > like they would treat comments from any other IETF contributors and resolve > them along with any other Last Call comments that have been received. For more > details on the INT Directorate, see > https://datatracker.ietf.org/group/intdir/about/ > > Though not being a DNS expert I think that the document is very useful, well > written, and complete for the time being to help improve security and > reliability of DNS practice. I have only few very minor suggestions for IMO > improved readability: > > P.1: > current NS Resource Record Set => current Name Server (NS) Resource Record Set > > P.3: > for the IN class. => for the Internet class (IN class). /perhaps add ref. > (e.g. > to RFC 1034) > > P.4: > Therefore, it is important that resolvers be able to => Therefore, it is > important that resolvers are able to > > P.8: > and it gets a query => and it receives a query > > Thanks and best regards > Dirk > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Re: Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.
On Aug 13, 2024, at 14:24, Andres Pavez wrote: > > I am writing to report an typo in the document. > > In Section 3.3, the text currently reads > "[...] Note, however, that cryptographic assurance for the contents of the > trust anchor now comes from the web PKI or the IANA CA, as described in > Section 3.2. [...]" > > The correct text should be: > "[...] Note, however, that cryptographic assurance for the contents of the > trust anchor now comes from the web PKI or the ICANN CA, as described in > Section 3.2. [...]" > > Proposed Correction: Replace "IANA CA" with "ICANN CA." Yipes, that's a good catch. Thanks for watching carefully! We'll note this for the IESG so that someone does a "needs new draft" and this will be reflected there. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.
On Aug 9, 2024, at 12:16, Michael StJohns 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. > 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. > 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. > 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." > It may make some sense here to use is the > field type the appropriate mapping here - 0101 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. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.
To everyone who reviewed draft-ietf-dnsop-rfc7958bis in WG Last Call: please carefully review the diff. Based on a very good IETF Last Call review from Petr Špaček, we had to make a significant technical change to the XML format, and we want to be sure that it works for everyone. We also updated the example (of course), and in doing so found a way to simplify the material around the example. All comments welcome (until my birthday, August 18). --Paul Hoffman On Aug 9, 2024, at 11:05, Warren Kumari wrote: > > > Dear DNSOP, > > During the DNSDIR review of draft-ietf-dnsop-rfc7958bis-03, Petr Špaček > identified an issue: if you include the DNSKEY material you also need to > include the flags. > > The authors have published a new version addressing these changes, as well as > addressing more minor comments received during IETF LC. > > As this required a change to the XML syntax, I'd like to get the DNSOP WGs > review / feedback on these changes. > > The IANA is eagerly awaiting this becoming a standard so that they can update > their trust anchor with the DNSKEY material - so, if you have any strong > objections to these changes, please let me know by end of day (anywhere!) on > Aug 18th > > Latest version: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/ > Diff from -03: > https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-rfc7958bis-03&url2=draft-ietf-dnsop-rfc7958bis-04&difftype=--html > > Thanks, > W ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Genart last call review of draft-ietf-dnsop-rfc7958bis-03
Thanks for your review. On Aug 2, 2024, at 07:06, Dan Romascanu via Datatracker wrote: > Summary: > > The document is clear and detailed in all its technical aspects. I have two > issues that I would suggest to be addressed before approval. If they are > already addressed indirectly I would be glad to be pointed to the text. I > categorized them as Minor, as they probably do not impact interoperability > within the same version of the mechanism. > > Major issues: > > Minor issues: > > 1. Section 1.2 includes a detailed list of changes from RFC 7985 which is > fine. > What I am missing, however, is a clear description of the motivation that led > to the update. Was that to include the content of the Errata? Was it because > of > operational or security problems in the deployment? Something else. The initial motivations were a significant errata, and also requests for two new features (the PublicKey entity and XML comments). > 2. Is there a requirement for backwards interoperability with the format and > publication mechanisms described in RFC 7958. Somewhat. DNS has a backwards-compatibility problem as strong as most other parts of the Internet protocols. The assumption in this version is that a relying party who is reading the trust anchor file is using a normal XML processor (so it won't barf on XML comments) and that the processor can handle new entities if given a new RELAX NG schema. > If yes, how is this ensured? It cannot be. If software that retrieves a file with the extended format fails, it will not have any trust anchors. This would hopefully be noticed by the operator. > In > any case, what is IANA instructed to do with the old records? There are no such instructions. There is only one URL in the RFC and draft, for the current trust anchor file. > Nits/editorial comments: > > Section 1.2 mentions 'Added an IANA Considerations section' as a change from > RFC 7598. Actually there is an IANA Considerations section in RFC 7598. So > probably what was meant was probably 'Updated the RFC Considerations Section'. Good catch; fixed. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Re: [dnsext] [Technical Errata Reported] RFC4035 (8037)
On Aug 2, 2024, at 08:29, Elias Heftrig wrote: > > is the other thread dealing with these errata on dnsop? Mail archive searches > for RFC8640 and errata report 8038 were unsuccessful. Would be glad to be > pointed to it. The thread is not dealing with this erratum report (which is not an erratum but a request for update), but it is dealing with the same issue of validator trying all the signatures and thus possibly being DDoSed. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Dnsdir last call review of draft-ietf-dnsop-rfc7958bis-03
THanks for keeping in on this!
> On Aug 2, 2024, at 02:14, Petr Špaček wrote:
>
> On 02. 08. 24 2:41, Paul Hoffman wrote:
>> On Aug 1, 2024, at 06:37, Petr Špaček 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 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).
>> I'm still not understanding the need here. The flags are included in the
>> 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.
> Revocation sets REVOKE bit=1, along with a validUntil date set to the past.
> Now the current format would contain DS hash which does not match the
> reconstructed DNSKEY RR.
It sounds like you assuming that IANA would change the DNSKEY by setting the
Revoke bit, but not update the trust anchor. That is possible, but it seems
unlikely to me.
Would it be sufficient for you if the document was updated to say "If IANA
makes any change to the DNSKEY record for a trust anchor, such as a change in a
flag, IANA MUST update the trust anchor file to reflect this change."
> Standardizing a format which by definition leads to internally inconsistent
> data fields sounds like a had idea to me.
Fully agree.
> Example 2. Non-REVOKEd flag - based on
> draft-ietf-dnsop-delegation-only-02.txt:
> Say that a future TA has DNSKEY flags ZONE + SEP + DELEGATION_ONLY set to 1.
> Such TA cannot be represented correctly as DNSKEY using the proposed format
> because the proposal assumes only ZONE + SEP bits are ever set to 1. Again,
> DS hash and the reconstructed DNSKEY would not match.
>
> In other words, the current proposed format ossifies DNSKEY flags for TAs.
...only if IANA doesn't update the trust anchor file, I believe. Please see the
above proposed addition.
>
>>> 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 (whic
[DNSOP] Re: [Ext] Re: [dnsext] [Technical Errata Reported] RFC4035 (8037)
On Aug 2, 2024, at 06:11, Eric Vyncke (evyncke) wrote: > > As you kindly added me in cc, Iet me chime in (after a couple of PTO days): > per the IESG statement on errata processing [1]: > - as the errata clearly does not represent the DNSEXT WG intent at the > publication time, this erratum cannot be “verified” > - nevertheless, it can be “held for document update” (and I will act > accordingly on Monday if I hear no strong objection) as the IESG statement > includes “any future update of the document *might* consider it” Ahhh, I had missed that. Earlier, that phrase was meant to indicate that the errata reviewers assumed the fix *would* be included; I'm glad to see that expectation has been toned down. I stand by my statement that the errata process is poorly defined and not all that well executed, but I fully admit that there is little will to fix it in the near future. > Perhaps time to write an I-D updating RFC 4035 in DNSOP ? Already done: see RFC 6840. DNSOP has been discussing the topic that caused this errata in another thread, and there are various arguments about whether there is any real value for changing the MUST to a SHOULD given the wording in other standards-track RFCs. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Dnsdir last call review of draft-ietf-dnsop-rfc7958bis-03
On Aug 1, 2024, at 06:37, Petr Špaček 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 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).
I'm still not understanding the need here. The flags are included in the
calculation for the DS record, which is mandatory in the file format.
> 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?
Some software vendors complained that they needed the full DNSKEY for the trust
anchors. They could not use the file: they had to wait for the DNSKEY records
to appear in the root zone. At least one of those vendors scraped the ceremony
materials to find the DNSKEY to use as their trust anchor before the record
appeared in the root zone.
> 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.
That might be true for your own implementation, but it was requested and
accepted by the WG.
>>> 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
>>> implemente
[DNSOP] Re: [Ext] Secdir last call review of draft-ietf-dnsop-rfc7958bis-03
Thank you for the review. On Aug 1, 2024, at 11:33, Klaas Wierenga via Datatracker wrote: > > Reviewer: Klaas Wierenga > Review result: Has Nits > > The draft reads well and is clear. I have one question that is maybe worth > answering in the security considerations. What is the impact of retrieving the > trust anchors over http instead of https? Does that lead to a risk of ending > up > with an invalid set of trust anchors? I agree with Joe that we can't really list all the possible attacks and mitigations. To that end, I propose the following text be added to the Security Considerations: Some of the methods described (such as accessing over the web with or without verifying the signature on the file) have different security properties; users of the trust anchor file need to consider these when choosing whether to load the set of trust anchors. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Dnsdir last call review of draft-ietf-dnsop-rfc7958bis-03
tly. (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? > 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. > 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. > 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. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Artart last call review of draft-ietf-dnsop-rfc7958bis-03
Thanks for the review! On Jul 29, 2024, at 06:10, Scott Hollenbeck via Datatracker wrote: > > "More information about IANA's policies and procedures for how the > cryptographic keys for the DNS root zone are managed (also known as "DNSSEC > Practice Statements" or "DPSs") can be found at > https://www.iana.org/dnssec/procedures > (https://www.iana.org/dnssec/procedures)." > > The URL is shown twice. The URL in parentheses can be removed. This is an artifact of how the XML is rendered in text. It shows fine in the HTML. > The [DPS] reference includes this URL, with a reference year of 2020: > > https://www.iana.org/dnssec/procedures > > However, that URL leads to a page of policy and procedure statements. This is > the URL for the cited practice statement, with a reference year of 2024: > > https://www.iana.org/dnssec/procedures/ksk-operator/ksk-dps-20240315.html The page at <https://www.iana.org/dnssec/procedures> lists two DPSs, one for the KSK and one for the ZSK. I would prefer to retain the shorter URL so that readers can see both. However, thanks for noticing the bad date of 2020: we will remove the date from the document. > I tried to validate the XML examples using the RELAX NG Compact Schema > provided > in Section 2.1 but was unable to find a working online validator. It all looks > correct, but I can't confirm that everything is valid. It's always good to check. I don't know of any online validators, but I have just checked with `jing`, and the example does indeed validate with the compact RNG. (Thanks to Tim Bray for pointing me at this tool!) --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] New draft on collision free key tags in DNSSEC
On Jul 25, 2024, at 17:34, Shumon Huque wrote: > > Folks, > > For discussion ... > > Mark Andrews, Elias Heftrig, and I have a new draft on collision free key > tags in DNSSEC. This topic has been in the air since the Keytrap > vulnerability disclosure -- and IETF120 hallway track conversations this week > prompted us to write up a rough initial proposal for this. Will need much > more fleshing out of details etc, but we hope this can serve as a starting > point ... > > https://datatracker.ietf.org/doc/html/draft-huque-dnsop-keytags-00 > [datatracker.ietf.org] The problems are listed as: Colliding key tags impose additional work on a validating resolver, which then has to check signatures for each of the candidate set of keys identified by the Key Tag. Furthermore, they open up resolvers to computational denial of service attacks by adversaries deploying specially crafted zones with many intentionally colliding key tags [KEYTRAP]. The main part of the proposed solution is listed as: DNSKEY algorithms MUST have DNSKEY RRsets that do not have colliding key tags There is a mismatch here. If the worry is an attacker creating colliding key tags to cause more work, that attacker is simply going to ignore the MUST requirement. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Opsdir last call review of draft-ietf-dnsop-rfc8109bis-05
Thanks for following up. I've removed text about places were we are already fixing the text. On Jul 25, 2024, at 12:39, Joe Clarke (jclarke) wrote: > > > First, in Section 3 why not just say that RD bit MUST NOT be set? Why > > leave it > > to a MAY when setting the bit is undefined? Seems like the more > > prescriptive > > you are the better. > > Some systems might set RD to 1 for all queries, such as due to lazy > programming. Setting it to 1 does no harm to anyone. > [JMC] Been there. Would it make sense, then, to say, “server MUST ignore > RD”? No, and for similar reasons. Some authoritative server software might pay attention to it, and there is no downside for it doing so. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Opsdir last call review of draft-ietf-dnsop-rfc8109bis-05
Thanks for the review! Comments below. On Jul 24, 2024, at 18:21, Joe Clarke via Datatracker wrote: > > Reviewer: Joe Clarke > Review result: Has Issues > > I have been asked to review this draft on behalf of the OPS Directorate. This > draft describes to initialize a recursive DNS resolver when its cache is empty > (i.e., at initial start time). While I found the document well-written, it > left me with a few questions. Maybe these are more my issues vs. issues with > the document, but I wanted to ask to see if some clarifying text might better > help other operators. > > First, in Section 3 why not just say that RD bit MUST NOT be set? Why leave > it > to a MAY when setting the bit is undefined? Seems like the more prescriptive > you are the better. Some systems might set RD to 1 for all queries, such as due to lazy programming. Setting it to 1 does no harm to anyone. > More importantly, I found Section 4 a bit confusing. Section 4 itself starts > by saying, "A priming query is a normal DNS query". This is good. Makes > things simple. But then in Section 4.1 there are specific requirements for > the > priming response. Those requirements seem reasonable, but it kind of > conflicted (at least in my mind) with the second sentence in Section 4: "Thus, > a root server cannot distinguish a priming query from any other query for the > root NS RRset." So I'm not sure that a server could know to adhere to those > requirements in its response. I suppose this could be cleared up by being > explicit that the client processing the priming response MUST ensure the > response has those properties or it must not prime its cache with that > response. The requirements in 4.1 and 4.1 are the normal requirements for any server authoritative for a particular zone. They are just restated here for clarity. > One other question left in my head is with the priming targets configuration. > You mentioned named.root (which I'm familiar with), but you say this should > not > be used. The text in 2.1 says that the root server identifiers (such as "l.root-servers.net") that appear in named.root should not be used in priming. > I think bind does use this by default, and I _think_ this is okay > with this draft since the point is that it shouldn't solely rely on those > addresses. That is, it should use that as a list of initial target addresses, > but still use the NS priming process to get the current set of A/ records > for the roots. I guess what I'm asking is that if that language could be > softened a bit to say that this file _could_ be used as that initial address > configuration? I think we can make this clearer by adding an example of a root server identifier as the thing that should not be used; we'll do so in the next version. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Dnsdir last call review of draft-ietf-dnsop-rfc8109bis-05
On Jul 16, 2024, at 00:06, Di Ma via Datatracker wrote: > > Reviewer: Di Ma > Review result: Ready with Issues > > This version adds more discussions about DNSSEC to priming exchange, which I > think need clearer statements. > > In this document, the authors say “With such resolvers, an attacker that > controls a rogue root server effectively controls the entire domain name space > and can view all queries and alter all unsigned data undetected.” > > However, this is not true when a DNSSEC-aware resolver has been configured > with > one or more Trust Anchors from some TLDs. In such case, it is not safe to say > "an attacker that controls a rogue root server effectively controls the entire > domain name space". Thank you for your review. Your addition is technically accurate, but that configuration is not known to be common. Further, your note would apply to any level in the DNS hierarchy, and describing it would be difficult in a document that is about priming the root. If there is any research that indicates widespread use of such TLD-or-below trust anchors, that would be really interesting to hear about. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Re: Working Group Last Call for draft-ietf-dnsop-rfc7958bis
Thanks for the quick responses! On Jul 8, 2024, at 11:21, Peter Thomassen wrote: > > On 7/8/24 20:08, Paul Hoffman wrote: >>> OLD >>> The Zone element in the TrustAnchor element states to which DNS zone >>> this container applies. The root zone is indicated by a single >>> period (.) character without any quotation marks. >>> >>> This is underspecified w.r.t. to format, for labels containing dots. >>> >>> But, the whole document is about the root (it's even in the title), and I >>> wonder why the Zone element is there in the first place. >>> >>> Instead of fixing the Zone element format, why not just drop the whole Zone >>> element? >> The zone element is there in case someone other than the root operator wants >> to use the format. Dropping it might cause some current users of the format >> to fail, so we are leaving it in. > > So it remains underspecified for labels containing dots. (I'm OK with that, > just spelling it out.) It is indeed unspecified, which seems fine because we also haven't seen any strong use case for it. > >>> OLD >>> The id attribute in the KeyDigest element is an opaque string that >>> identifies the hash. >>> >>> Is the id attribute expected to be unique within the XML file? > [...] >> The spec says it is "an opaque string". Your proposal is to extend that and >> make it unique. This could cause a serious problem in the future if IANA >> does not change the id string for some reason. We are leaving it as just >> opaque. > > That's fine. However, the attribute name "id" suggests uniqueness, Without any definition of uniqueness in the document, it shouldn't. For example, in your earlier message, you suggested a few different ways this could be unique. Without such a definition, a reader can't assume they know what kind of uniqueness to infer. > because that's how IDs usually work. I suggest something like "opaque (but > not necessarily unique)", or renaming it to something else, to prevent this > misinterpretation. Changing the name of an attribute for a widely-used protocol seems incredibly dangerous. Adding "(but not necessarily unique)" doesn't make sense because "opaque" doesn't imply uniqueness. > >>> OLD >>> If a system >>> retrieving the trust anchors trusts the CA that IANA uses for the >>> "data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in >>> order to have assurance of data origin. >>> >>> Does this really mean that if I don't trust the CA, then I should be using >>> HTTP? >> Yes. >>> How does that make things any better? >> It does not, but the text doesn't indicate that it makes anything better. > > I wonder then why we need the "if" clause in that sentence. I'd remove it, > but I don't feel strongly. Without the clause, it sounds like the document is telling the reader they SHOULD trust the CA that IANA uses. Given that IANA gets to choose its CA based on its own risk assessment, and even large CAs seem to become untrusted for other reasons, I wouldn't want to do that. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Re: Working Group Last Call for draft-ietf-dnsop-rfc7958bis
Thanks for the comments. Some are addressed in the revised draft coming out
shortly. I have noted below only the ones that are not.
--Paul Hoffman
> On Jul 1, 2024, at 11:08, Peter Thomassen wrote:
> Section 2.2
> ---
>
> OLD
> The Zone element in the TrustAnchor element states to which DNS zone
> this container applies. The root zone is indicated by a single
> period (.) character without any quotation marks.
>
> This is underspecified w.r.t. to format, for labels containing dots.
>
> But, the whole document is about the root (it's even in the title), and I
> wonder why the Zone element is there in the first place.
>
> Instead of fixing the Zone element format, why not just drop the whole Zone
> element?
The zone element is there in case someone other than the root operator wants to
use the format. Dropping it might cause some current users of the format to
fail, so we are leaving it in.
> OLD
> The id attribute in the KeyDigest element is an opaque string that
> identifies the hash.
>
> Is the id attribute expected to be unique within the XML file?
>
> If so, does this also apply if the same digest is re-published with an added
> validUntil attribute, or even published twice with different validity ranges?
>
> Also, if two digests (of different hash type) are published for the same key,
> do those KeyDigests share an id?
>
> This aspect uncovers a structural issue, because the public key is not really
> an attribute of the key digest; rather, they are in a 1:n relationship.
>
> I am wondering if it would be better to move the PublicKey element out of the
> KeyDigest element, by allowing any number of them to be direct children of
> TrustAnchor, with the relevant key identified by its keytag and/or validFrom
> attribute. This would require the schema to be updated as follows:
>
> start = element TrustAnchor {
>attribute id { xsd:string },
>attribute source { xsd:string },
>element Zone { xsd:string },
>
>keydigest+
>publickey*
> }
>
> keydigest = element KeyDigest ...
>
> publickey = element PublicKey {
>attribute id { xsd:string },
>attribute keytag { xsd:nonNegativeInteger { maxInclusive = "65535" } },
> // or validFrom
>xsd:base64Binary
> }
>
> The uniqueness concern is simplest addressed by adding "uniquely within the
> XML file" or something.
>
> Howeve, it's surprising then that two digests that relate to the same key
> have different IDs, and I think the structural change would be cleaner. (This
> would then require no two keys to be published for the root with the same
> keytag and/or validFrom).
The spec says it is "an opaque string". Your proposal is to extend that and
make it unique. This could cause a serious problem in the future if IANA does
not change the id string for some reason. We are leaving it as just opaque.
> Section 2.5
> ---
>
> For the still-valid key, even if it's just an example example, I suggest not
> to use any signing and digest algorithm that are no longer fully recommended
> by RFC 8624. (This applies to both algorithm 5 and digest type 1.)
Using type 1 means that the example will not wrap around in the text version of
the eventual RFC (it will be fine in the HTML version). If people feel strongly
about this, we can indeed update this later.
> Section 3.2
> ---
>
> Like John, I'm not sure about the CMS mechanism, but I don't feel strongly.
> Perhaps some more about bootstrapping that trust could be said, or declared
> out of scope? At least a link to something that talks about that CA would be
> useful.
>
> OLD
> If a system
> retrieving the trust anchors trusts the CA that IANA uses for the
> "data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in
> order to have assurance of data origin.
>
> Does this really mean that if I don't trust the CA, then I should be using
> HTTP?
Yes.
> How does that make things any better?
It does not, but the text doesn't indicate that it makes anything better.
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Re: Working Group Last Call for draft-ietf-dnsop-rfc7958bis
On Jul 3, 2024, at 07:50, Ben Schwartz wrote: > Section 1.1 > > I like the "assumed and not derived" notion for a "trust anchor", but it's > tricky and bears a bit more explanation. Rather than repeating it in the > following sentence, perhaps you could say "the decision to trust this entity > is made outside of the system that relies on it". My point is that "assumed > and not derived" requires a certain sort of "horizon" comprising a single > "system"; expand the horizon and it is indeed derived. For example, trust in > these DNSKEYs can be derived from the CMS signature, making the ICANN CA the > trust anchor, but that process is outside of DNSSEC, so from DNSSEC's > perspective the root key is the trust anchor. This is addressed in the revised draft coming out shortly. > Section 3.1 > > The existence of a protocol called "HTTPS" is controversial in the HTTP > world. I recommend checking with the HTTPBIS chairs or other relevant > experts on this point of style. This can be done during IETF Last Call. I'm hesitant to change this based on opinions that are not instantiated in an RFC. > Section 3.3 > > This section says "cryptographic assurance for the contents of the trust > anchor now comes from the web PKI as described in Section 3.2", but Section > 3.2 outlines two ways to verify the contents: an attached signature or TLS. > The TLS case looks like the Web PKI, especially since it is not guaranteed to > chain to any particular root CA, but the attached signature does not seem to > represent a dependency on the Web PKI. This is addressed in the revised draft coming out shortly. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Re: Working Group Last Call for draft-ietf-dnsop-rfc7958bis
Thanks for the comments. They are all addressed in the revised draft coming out shortly. --Paul Hoffman On Jun 30, 2024, at 15:31, John R Levine wrote: > > I took a look and didn't find anything particularly troubling. I agree that > adding the new optional DNSKEY element doesn't need a version number. Getting > rid of private certificates in favor of a CA signed cert for the HTTPS server > makes sense. > > On the other hand, I don't understand what the point of the new optional > DNSKEY field in the XML is. I see that IANA does not currently include it. > > It's always been possible to retrieve the DNSKEY records from the live root > and check that one of them matches the digest in the XML. Is this to provide > a way to remember the old DNSKEYs that have been rotated out of the root? A > sentence or two describing the motivation would help. > > The third paragraph of section 3.2 describes a detached CMS signature. While > I realize it's there in 7958, I don't see how it provides any security at > all. It's signed with an ICANN private key but there's no way I can see to > tell the "real" ICANN CA from one that I just made up to sign my fake XML. > The useful security is the accredited CA signed HTTPS certificate described > in the following paragraph, so I'd take the CMS signature out or at least > note that it's trivial to defeat unless you have external knowledge about > ICANN's private CA. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Working Group Last Call for draft-ietf-dnsop-rfc7958bis
Thanks for the comments. They are all addressed in the revised draft coming out shortly. --Paul Hoffman > On Jun 26, 2024, at 13:31, James Mitchell wrote: > > All, > Please find my comments below. > The draft introduces a new optional field PublicKey without providing a > versioning mechanism - both current and new formats are retrieved from the > same path. I have reviewed a few publicly available parsers and did not > identify any obvious issues that could arise following the addition of the > PublicKey element (implementations appear to key of element/tag names, > concerns if any, could be memory management with the larger and unused > PublicKey CDATA). I do not believe versioning is required on the > understanding that IANA may revert to the previous version if necessary - > there appear to be a few clients with operational dependencies on the file. > Looking ahead to the addition of the PublicKey element, we discussed whether > to publish the PublicKey element for historical TAs and whether we would > remove the PublicKey for future-historical TAs. While we have not formalized > plans, can we assume these are operational decisions to be made by IANA? If > so, does the draft require text to clarify that the PublicKey may be present > for some KeyDigests and that the element may be removed if previously present? >A few editorial comments: > The introduction says: > This document describes the formats and distribution methods of DNSSEC trust > anchors that have been used by IANA for the root zone of the DNS since 2010. > This is not quite true given a format with the publicKey element was not > possible back in 2010. >The following sentence is difficult to read: > 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 DNSKEY > elements of the KeyDigest are the same as the previous trust anchor. > I think it can be removed entirely - text regarding duration of use is > covered in a prior sentence - and I'm not sure what it adds. My problems with > this are: 1) one does not "change to a trust anchor" following the addition > of a (future?) validUntil attribute - it is the same trust anchor; 2) the > "it" in "it can change" is difficult to understand, in part because of the > prior issue and because it is the validUntil that is changing; 3) DNSKEY > elements is not defined - it should not be the (optional) PublicKey which is > most definitely a DNSKEY element. >Section 2.4 Converting to DNSKEY records - A DNSKEY constructed from the > KeyDigest will fail to match a published DNSKEY when the REVOKE bit is set - > this doesn't create an issue for this protocol but may cause confusion during > a rollover. It might be clearer to say something to the effect of the file > does not provide values for DNSKEY protocol or flags - for the purpose of > this mechanism, clients can assume valid trust anchors will be for protocol 3 > and that the ZONE and SEP flag bits will be set. > Thanks, > James Mitchell > Director IANA Technical Services ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE
On Jul 5, 2024, at 14:33, Erik Kline wrote: > > "expect to find two strings" > > I didn't see this specified so thought I'd ask: what is the separator of the > two strings? ASCII whitespace, or ...? Welcome to RFC 1035 and and TXT records. There is no separator: the TXT record (and thus now the WALLET record) takes "One or more s". A is "a single length octet followed by that number of characters". --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE
On Jul 5, 2024, at 05:19, Petr Špaček wrote: > > I wonder if it needs some words how to handle wallet addresses longer than > 255 characters? To date, every known blockchain uses 256-bit signature keys. Most use truncated hashes of the public key, and all use either hexadecimal or some other ASCII encoding for the wallet address. I have not seen any suggestion that future blockchains would use post-quantum signatures. Thus, 255 characters is more than sufficient for all known and currently-expected wallet addresses. > Maybe we safely leave this up to the application because the first field > should identify the type anyway ... Just thinking aloud. Exactly. And, if someone comes up with a wallet that needs more than 255 characters, they can define a WALLET2 RRTYPE for those addresses. I find this exceedingly unlikely to happen because space is extremely expensive on blockchains, and every transaction has two wallet addresses. And the interest in blockchains may have subsided before there is any chance of needing post-quantum signatures. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Re: Fwd: I-D Action: draft-zhang-dnsop-ns-selection-00.txt
On Jul 3, 2024, at 09:32, Peter Thomassen wrote:
>
>
>
> On 7/3/24 17:19, Ben Schwartz wrote:
>> Hi Davey,
>> To clarify, the "DNS Load Balancing" side meeting will not be concerned
>> primarily with nameserver selection. Instead, the topic of the side meeting
>> will be about using DNS to perform load balancing of other services and
>> protocols.
>> I think this draft's term ("Nameserver Selection") is good, and we should
>> use that to distinguish it from "DNS Load Balancing".
>
> I think the latter suffers from some ambiguity, which could be removed by
> calling it "DNS-based Load Balancing".
A big +1 to that suggestion. When I first saw "Side Meeting - DNS Load
Balancing", I assumed it was about the generic load balancers sometimes put in
front of a bank of authoritative servers.
--Paul Hoffman
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE
Thanks again for the input on the new RRTYPE. I submitted it to the RRTYPE expert reviewers, and the new definition is posted at <https://www.iana.org/assignments/dns-parameters/WALLET/wallet-completed-template>. It has "2024-06-24" as its submission date. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Working Group Last Call for draft-ietf-dnsop-rfc7958bis
On Jun 26, 2024, at 13:31, James Mitchell wrote: > > Please find my comments below. Thanks for the review, James. These all seem easy to deal with. Of particular note: > Looking ahead to the addition of the PublicKey element, we discussed whether > to publish the PublicKey element for historical TAs and whether we would > remove the PublicKey for future-historical TAs. While we have not formalized > plans, can we assume these are operational decisions to be made by IANA? Absolutely. > If so, does the draft require text to clarify that the PublicKey may be > present for some KeyDigests and that the element may be removed if previously > present? We can add that wording, but it is really up to IANA at any given time how they want to handle historic trust anchors within the given XML syntax. We still look forward to others in the WG commenting in WG Last Call. This draft affects way more than IANA. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Revised the application for the WALLET RRTYPE
Greetings again. Based on the concerns expressed here about the difficulty to implement parsing of the new RRTYPE, I have turned in a modified application that changes it to using the same definition as a TXT record, with an explanation of what receivers should expect for the resulting string. I'll report back to this list after I hear back from the RRTYPE expert reviewer and IANA about the modified application. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Re: Paul Wouters' Discuss on draft-ietf-dnsop-zoneversion-08: (with DISCUSS and COMMENT)
Responding to one bit of Duane's response. On Jun 18, 2024, at 10:40, Wessels, Duane wrote: >> What should an authoritative nameserver return as zone version if it is >> configured as authoritative nameserver but can't get the zone version (eg >> because "no permission to read file") One way would be to allow it to return >> a zero length for ANY type and define that as an error condition. > > I think the authors will need to discuss how to handle error conditions like > this > and get back to you. PaulW's DISCUSS on this topic doesn't make sense. If a server is authoritative for a zone, it has know the version of the zone: the zone is incomplete without its version. If the server doesn't know the version, it should not be answering any queries for that zone at all. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] To sign root-servers.net or not?
On Jun 17, 2024, at 13:33, Geoff Huston wrote: > > [change of topic] > > " things that the IETF may not have the final say on." > > Possibly true in this case, but not having the final say is very different to > "having a say" > > I would find it interesting to understand the current state of thinking in > DNSOP as to > whether to DNSSEC-sign the root-servers.net zone. Are there folk with thoughts > and opinions on this topic? Thoughts *and data*! A few weeks ago on this list (https://mailarchive.ietf.org/arch/msg/dnsop/JEChrjGKGhQzwo5dCuWZm4lcm5g) I posted: > FWIW, this new text is somewhat based on the findings from NLnetLabs and SIDN > on a project supported by ICANN. You can see the report, and an earlier > report on a related topic, at: > > https://www.icann.org/resources/pages/octo-commissioned-documents-2020-11-05-en --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [DNSOP]Re: [Ext] Requesting final comments on draft-ietf-dnsop-rfc8109bis
On Jun 17, 2024, at 13:39, Joe Abley wrote: > > Hi Paul, > > On 17 Jun 2024, at 21:18, Paul Hoffman wrote: > >> The paragraph reads: >> >> If the "root-servers.net" zone is later signed, or if the root servers are >> named in a >> different zone and that zone is signed, having DNSSEC validation for the >> priming queries >> might be valuable. >> The benefits and costs of resolvers validating the responses will depend >> heavily on >> the naming scheme used. >> >> It is still accurate as it stands, does not lead to an assumption of what >> name would be signed and, more importantly, strongly indicates that the name >> that eventually gets signed might be different than root-servers.net. I'm >> not sure why we would want to remove that. > > It might be technically true (although I could still nitpick about the > assumption that the root server names must necessarily live in a zone other > than the root) but I don't think it's useful. I find it useful, but I see that it is also off-topic for current priming. Please note that the first sentence was actually part of RFC 8109, and I don't remember people objecting to it then. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [DNSOP]Re: [Ext] Requesting final comments on draft-ietf-dnsop-rfc8109bis
On Jun 17, 2024, at 09:52, Tim Wicinski wrote: > > > > On Mon, Jun 17, 2024 at 12:19 PM Joe Abley wrote: > On 17 Jun 2024, at 17:54, Tim Wicinski wrote: > >> Oh that's a very good point, and does make that assumption. "will be >> valuable if root-servers.net [root-servers.net] is DNSSEC signed" does not >> make that assumption. > > It perhaps narrowly avoids one of the assumptions I mentioned but it still > warmly embraces the other one. > > I still think this text speculates about the future and I still don't know > why we think that is a good idea. > > > The more I think about this, I believe you are correct that we can not make > any assumptions about the future. > > It then feels like that last paragraph is removed. Thoughts? The paragraph reads: If the "root-servers.net" zone is later signed, or if the root servers are named in a different zone and that zone is signed, having DNSSEC validation for the priming queries might be valuable. The benefits and costs of resolvers validating the responses will depend heavily on the naming scheme used. It is still accurate as it stands, does not lead to an assumption of what name would be signed and, more importantly, strongly indicates that the name that eventually gets signed might be different than root-servers.net. I'm not sure why we would want to remove that. --Paul Hoffman ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [DNSOP]Re: [Ext] Requesting final comments on draft-ietf-dnsop-rfc8109bis
One more nudge on this, before the deadline tomorrow. --Paul Hoffman On Jun 5, 2024, at 09:28, Paul Hoffman wrote: > > Tim jumped the gun by about an hour: we just submitted the -05. It > incorporates the suggested text from below; you can see the diff at: >https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8109bis-05 > > FWIW, this new text is somewhat based on the findings from NLnetLabs and SIDN > on a project supported by ICANN. You can see the report, and an earlier > report on a related topic, at: > > https://www.icann.org/resources/pages/octo-commissioned-documents-2020-11-05-en > > Please let us know if you have any issues with the changed text in the new > version. > > --Paul Hoffman > > > On Jun 5, 2024, at 08:25, Tim Wicinski wrote: >> >> All >> >> The chairs are requesting some final comments on >> draft-ietf-dnsop-rfc8109bis. As you might recall, this document has already >> been through WGLC and had consensus to advance, but our AD reviewed it and >> raised some additional questions. (Warren Kumari, “AD Review of >> draft-ietf-dnsop-rfc8109bis,” email to the list on 31 January.) ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [Ext] Requesting final comments on draft-ietf-dnsop-rfc8109bis
Tim jumped the gun by about an hour: we just submitted the -05. It incorporates the suggested text from below; you can see the diff at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8109bis-05 FWIW, this new text is somewhat based on the findings from NLnetLabs and SIDN on a project supported by ICANN. You can see the report, and an earlier report on a related topic, at: https://www.icann.org/resources/pages/octo-commissioned-documents-2020-11-05-en Please let us know if you have any issues with the changed text in the new version. --Paul Hoffman On Jun 5, 2024, at 08:25, Tim Wicinski wrote: > > All > > The chairs are requesting some final comments on draft-ietf-dnsop-rfc8109bis. > As you might recall, this document has already been through WGLC and had > consensus to advance, but our AD reviewed it and raised some additional > questions. (Warren Kumari, “AD Review of draft-ietf-dnsop-rfc8109bis,” email > to the list on 31 January.) > > Here are specific things we particularly want feedback on: > > > -Discussion on the list suggested a change regarding the use of the TC bit in > the context of a priming response, which appears in the -04 (current) version > of the document but hasn’t been reviewed by the full WG: > > OLD: > Note that [RFC9471] updates [RFC1035] with respect to the use of the TC bit. > It says "If message size constraints prevent the inclusion of all glue > records for in-domain name servers, the server must set the TC (Truncated) > flag to inform the client that the response is incomplete and that the client > should use another transport to retrieve the full response." Note, however, > the root server addresses are not glue records, so setting the TC bit in > truncated responses from the root servers is not required by [RFC9471]. > > NEW: > Note that [RFC9471] updates [RFC1035] with respect to the use of the TC bit. > It says "If message size constraints prevent the inclusion of all glue > records for in-domain name servers, the server must set the TC (Truncated) > flag to inform the client that the response is incomplete and that the client > should use another transport to retrieve the full response." Because the > priming response is not a referral, root server addresses in the priming > response are not considered glue records. Thus, [RFC9471] does not apply to > the priming response and root servers are not required to set the TC bit if > not all root server addresses fit within message size constraints. There are > no requirements on the number of root server addresses that a root server > must include in a priming response. > > Willem's email to the list which suggests changes to section 3.3 to better > explain what is signed when; the chairs feel that these changes should be > incorporated into the draft as well > https://mailarchive.ietf.org/arch/msg/dnsop/D2Ha-Hk2lpvvkcXx7k4RILpgaPQ/ > [mailarchive.ietf.org] > The addition of a reference to RSSAC 0028 > (https://www.icann.org/en/system/files/files/rssac-028-03aug17-en.pdf, > “Technical Analysis of the Naming Scheme Used For Individual Root Servers,” > as an informative reference; it discusses the rationale for not signing > root-servers.net [root-servers.net]. > > > We liked to hear from the WG on this by Friday June 14, 2024. > > Thanks > tim, et al ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Questions before adopting must-not-sha1
On Apr 30, 2024, at 16:20, Wes Hardaker wrote: > 3. The whole discussion, IMHO, is side-stepping the real issue: if not > now, then when? IE, do we never put something at MUST NOT? Is there a > usage threshold? Is it "must be zero"? Is it "known to be broken and > everyone must have a flag day instead of a slower process"? > > These are not easy questions, and there does seem to be many different > opinions. RedHat led the pack(ish), and maybe Paul and others will be > the tail end at some very late value. There is no right or wrong, and > the line of people are likely to spread out along the timeline. Thank you for asking the question about questions. But, please, don't simplify with the phrase "MUST NOT" given that the draft has that for two different parts of the DNS: signers and resolvers. My personal feeling is that "MUST NOT sign because RedHat" is an unfortunate position for us to be in, but one that is defensible. "MUST NOT validate because of some security issue that might never happen" is not defensible, at least to me. The argument "you signing something that we know many resolvers cannot validate is actively bad for security" is defensible. Until someone can show that a reduction in collision resistance can lead to a reduction in real-world security for DNSSEC, we can wait for "MUST NOT validate", possibly forever. There is no good reason for this group to say to a zone operator who signed their zone in good faith "we are now making your zone insecure"; it's even worse for us to say to zone owners "we're forcing you to pick a different TLD if you still want to be secure". And, to be clear: I don't support waiting for a usage threshold for "MUST NOT validate". If there is any noticeable chance that an attacker can create a key or signature for a zone they don't control, that is a good enough reason to go to "MUST NOT validate" and let the resolvers decide if they want to be compliant with the new standard. But we aren't there yet, and when we are, the RFC needs to say how we got to that conclusion. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Apr 30, 2024, at 16:00, Paul Wouters wrote: > > On Apr 30, 2024, at 18:42, Paul Hoffman wrote: >> >> This cull-because-of-low usage thread incorrectly assumes that the DNS is >> flat instead of a hierarchy. The last I saw, there are 14 TLDs who use >> RSASHA1. Advancing this draft as-is means that all of the zones under those >> TLDs would be completely wiped out as well. Or maybe that's what the WG >> wants? > > Not wiped out. Being made insecure (versus part of the world only treating > them insecure) Fair point. "Made their efforts to use DNSSEC useless" would have been a better way to say it. > It’s worth contacting them for timelines of migration away from SHA1, as RFC > 8624 is five years old and that already told them to start moving. > > Is that something within the realm of ICANN? Perhaps the DNS Tech Day ? You ask those questions sounding as if ICANN staff had not already done so. > Or perhaps a liaison statement from IETF to ICANN ? Such a statement would be quite a different action than the threat of making all the zones under many TLDs go insecure. This thread is about WG adoption of a draft that would do the latter. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
This cull-because-of-low usage thread incorrectly assumes that the DNS is flat instead of a hierarchy. The last I saw, there are 14 TLDs who use RSASHA1. Advancing this draft as-is means that all of the zones under those TLDs would be completely wiped out as well. Or maybe that's what the WG wants? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
The people arguing for adoption seem to have two major arguments: 1) we should punish zones that sign with old algorithms by making compliant resolvers treat them as insecure 2) we should make it impossible for zones to sign or re-sign with old algorithms #1 affects resolvers, in particular the resolver's security policies. It is based on as-yet unsupported assertions of the lack of safety for SHA-1 in DNSSEC signatures or DS records. #2 affects signing software (and maybe authoritative software?). It is based on the fact that there is a large known set of resolvers that will treat zones signed with SHA-1 (and maybe zones covered with SHA-1 DS records?) as insecure, and the fact that there are easily-chosen alternatives that do not (yet) have this problem. The current must-not-sha1 is worded around #1. I am currently against adoption for that reason. If it was instead worded around #2, it would be easier to support. I am still saddened by the level of interest in these documents, at the expense of other DNSSEC-related documents that are clearly more important. We could be much closer to more stable DNSSEC operations if people showed interest in those WG drafts instead of wanting to pile on more drafts, particularly those that make DNSSEC less safe for some existing users. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Apr 29, 2024, at 13:30, Paul Wouters wrote: > > On Mon, 29 Apr 2024, Paul Hoffman wrote: > >> If the purpose of deprecating validation that involves SHA-1 is the decision >> by RedHat to make that entire section of the DNS insecure, the documents >> should say that explicitly. Conflating the pre-image weaknesses of SHA-1 and >> actual useful attacks on DNSSEC, and then using that conflation as the >> reason for the WG adopting these documents, is not useful. > > Redhat is not the source of this. It is the certification people that say you > cannot use SHA1 in cryptographic functions related to authentication, > encryption, or digital signatures. And that these requirements are > getting centrally codified in an OS that cannot take DNS into account. It is still RedHat's choice to read those certification requirements the way that they did; others read them differently. But, regardless of whether we agree with RedHat's decision, if it is that decision that is driving the drafts, the drafts should say that instead of saying that it is some vague concern that has not been substantiated. > Tony Finch and Viktor Dukovhny believe an attack with SHA1 > is possible. I have not yet been convinced by them. See: > https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html I too am not convinced that an attack that needs >250 bytes of identical preamble can apply to DNSSEC-relevant records such as DS, DNSKEY, NSEC, and NSEC3. More than four years after it was published, the original paper (https://sha-mbles.github.io/) has not been updated with any more detail related to DNSSEC, nor do others seem to have followed up. (Note: I could totally have missed such followups; if so, I'm quite interested to hear of them!) --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Apr 29, 2024, at 13:00, Paul Wouters wrote: > That said, a number of OSes have already forced the issue by failing > SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So > right now, if you run DNSSEC with SHA1 (which includes NSEC3 using > SHA1), your validator might already return it as an insecure zone. If the purpose of deprecating validation that involves SHA-1 is the decision by RedHat to make that entire section of the DNS insecure, the documents should say that explicitly. Conflating the pre-image weaknesses of SHA-1 and actual useful attacks on DNSSEC, and then using that conflation as the reason for the WG adopting these documents, is not useful. --Paul Hoffman (And, if anyone believes that collision reduction attacks on a hash are likely to lead to preimage reduction attacks, please look at the literature about MD5. The collision resistance has been massively reduced, and there is still zero preimage reduction after almost 20 years.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Apr 27, 2024, at 17:38, Tim Wicinski wrote: > Please review these drafts to see if you think they are suitable for adoption > by DNSOP, and send any comments to the list, clearly stating your view. The WG already has many important DNSSEC-related documents that are not getting enough attention from WG participants. Each of those documents would have much more significant effects on the security of the DNS than these proposed documents. The WG should not adopt these proposed documents until the more important documents have been standardized. In the future, there may be more relevant attacks on SHA-1 and ECC-GOST, and adopting these documents would make sense then. The advances in practical attacks on SHA-1 have been slow and somewhat predictable. The use of ECC-GOST outside of regions where it was required is nearly non-existent. The WG's attention is valuable, and spending that attention on documents that do not noticeably affect the actual security of the DNS is not a good use of our time. I propose that Wes keep the drafts alive as personal documents until the WG's DNSSEC documents with much more impact are finished. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt
On Mar 11, 2024, at 07:30, Ray Bellis wrote: > > I think this document gives an opportunity to explicitly clarify expectations > regarding the NS records either side of the zone cut. Wearing my co-author hat: yes, that's the purpose. > I get the impression with DELEG on the horizon that there's a shift towards > the parent side data being considered more "authoritative" even though in > protocol terms it explicitly isn't. Wearing my BoF co-chair hat: it is waaay to soon to say that. There were explicit requests for child-side declarations to be in scope for the eventual working group. > Even if that's not the case, discussion of when child-side NS records should > be purged and then re-learned by following the parent-side delegation would > be useful. Wearing my DNSOP participant hat: that's why I encouraged Shumon and PaulV to revive <https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/>. > I also idly wonder what would happen if one were able to incorrectly put the > DS records for a zone into the child zone... Wearing my Hackathon hat: I'm working on a small testbed, using Shumon's code, that could test that. --Paul Hoffman, who rarely actually wears hats, but will in Brisbane because of the sun ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RFC 9539 on Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS
[[ Of likely interest to this WG, for the people who unsubscribed from DPRIVE ]] A new Request for Comments is now available in online RFC libraries. RFC 9539 Title: Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS Author: D. K. Gillmor, Ed., J. Salazar, Ed., P. Hoffman, Ed. Status: Experimental Stream: IETF Date: February 2024 Mailbox:d...@fifthhorseman.net, joeyg...@gmail.com, paul.hoff...@icann.org Pages: 24 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dprive-unilateral-probing-13.txt URL:https://www.rfc-editor.org/info/rfc9539 DOI:10.17487/RFC9539 This document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor. The protections provided by the guidance in this document can be defeated by an active attacker, but they should be simpler and less risky to deploy than more powerful defenses. The goal of this document is to simplify and speed up deployment of opportunistic encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem. Wider easy deployment of the underlying encrypted transport on an opportunistic basis may facilitate the future specification of stronger cryptographic protections against more-powerful attacks. This document is a product of the DNS PRIVate Exchange Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On Feb 28, 2024, at 13:25, Mark Andrews wrote: > The point of forbidding is to allow the validator to safely stop as soon as > possible when it is under attack. If that is the point, why not just document that a validator is allowed to do that, such as if it sees three matching keytags? That seems much more direct. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On Feb 28, 2024, at 03:52, libor.peltan wrote: > > Hi John, > Dne 27. 02. 24 v 21:24 John Levine napsal(a): >> The total number of domains where I found duplicate tags was 105. >> >> > As I said earlier, is while I appreciate such research, I warn against > misinterpreting it. The main point isn't about the zones that are currently > experiencing a keytag-conflict; it's about the zones where there is a > potential threat that they might do tomorrow (considering the case when many > mainstream validating resolvers would start enforcing strong > keytag-conflict-intolerance). You quoted the less-important part of his message. The most important part was: > The total number where there were more than two tags with the same ID was > ZERO. An operational suggestion to validators of "stop if there are more than three keytags with the same value because that seems suspicious" would solve the problem for the validators much more quickly than "wait for some years after the prohibition on issuers goes through the IETF and is then implemented". It also means we don't have to update a 20-year-old spec. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] on private use TLDS: .interNAL -> .LAN
On Feb 27, 2024, at 10:53, Toerless Eckert wrote: > > On Tue, Feb 27, 2024 at 01:48:22PM +0100, Joe Abley wrote: >> Op 27 feb 2024 om 12:08 heeft Toerless Eckert het volgende >> geschreven: >> >>> I would like to see a BCP RFC on the use of the "internal" TLD, >>> and ICANN should not finalize availability of the TLD unless that RFC >>> exists. >> >> Surely what ICANN is preparing to do is make a decision that an "internal" >> TLD should never be available. > > How did you come to that conclusion. It sounded to me as if ICANN > is on the road to assign .internal for the purpose. No, not at all. The wording of the proposal says "string to be reserved for the purpose of a top-level domain that may be used for internal or private use applications". Here, "reserved" means never put in the root zone. I note that the term "reserved" was never defined. I'll try to get that rectified. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On Feb 16, 2024, at 08:12, Petr Špaček wrote: > > I think you describe it accurately, but people who implement resolvers in > this thread (me, Ralf, Brian W.) apparently disagree where the pain should > land - should resolvers suffer from more complex code & work, or should > signers suffer if they do something very unusual? It's not just "the signers", it's also all the people who have signed zones, and particularly the companies who might use multiple providers. "Fail when seeing first colliding pair" is clearly worse for them than "fail when seeing first colliding triple". I keep hoping that this group will focus more on those who go through the effort to sign their zones than those who write the software. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On Feb 15, 2024, at 10:03, Ralf Weber wrote: > > Moin! > > On 15 Feb 2024, at 9:53, Paul Hoffman wrote: >>> A fairly simple way to deal with this issue is a Flag Day. As Ralf said in >>> a later post, the number of zones with colliding key tags is relatively >>> small. >> >> Anything above zero is significant. > > If you are waiting for zero you might wait forever. Yes, exactly. >>> It would certainly be reasonable to declare that at some time in the >>> future, colliding keys will not be handled by validators. >> >> Why? Many people on this thread have said they have or will implement caps >> on how many collisions for a key set they will allow. An operational change >> such as that is vastly easier to implement than a flag day, and gets better >> results. > > There is a difference between what a lot of people on this thread did to keep > the Internet alive and what is a good solution going forward. I think long > term Brian and Petr are right that key collisions should not be allowed. Resolvers can already have policies that don't allow them; that has been true for 20 years. There is nothing stopping any resolver from saying "I found a keytag collision so I'm not going to validate". Fortunately, we're seeing resolvers instead saying "I'll bound the amount of work I do when I see colliding keytags". Compare that to "we're going to change a 20-year-old spec, wait for years for the changes to be implemented, and only then change the way validators work". The current situation is much more sustainable. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On Feb 15, 2024, at 09:48, Wellington, Brian wrote: > > > >> On Feb 15, 2024, at 6:02 AM, Paul Wouters wrote: >> >> On Feb 15, 2024, at 04:37, Petr Špaček wrote: >>> >>> If you think colliding keys should be allowed, please propose your own >>> limits for sensible behavior. >> >> I do think they need to be allowed because they have always been allowed so >> far. Reasons for not allowing them seems to be implementation details. Sure, >> if the RFCs had warned implementers this wouldn’t have happened, and we can >> learn from that (and I gained appreciation and validation for whining about >> security and operational consideration sections) >> >> You seem willing to (statistically) throw 1/65536 zones under the bus. That >> would roughly be 2500 .com domains if all of .com was signed (without key >> sharing) >> >> I don’t see why we should do this. > > A fairly simple way to deal with this issue is a Flag Day. As Ralf said in a > later post, the number of zones with colliding key tags is relatively small. Anything above zero is significant. > It would certainly be reasonable to declare that at some time in the future, > colliding keys will not be handled by validators. Why? Many people on this thread have said they have or will implement caps on how many collisions for a key set they will allow. An operational change such as that is vastly easier to implement than a flag day, and gets better results. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On Feb 14, 2024, at 07:10, Jim Reid wrote: > That said, I think a minor tweak to the core DNSSEC specs would be a good > idea. For instance, whenever a validator comes across a key tag collision, it > MUST stop validating and either return a hard error or an unvalidated > response. > > My concern here is a bad actor using key tag collisions to disrupt important > validating resolver services. For some definition of important. That is not a "minor tweak", that will occasionally break validation in hard-to-detect ways. The problem is not the collisions, it is the collisions causing almost unbounded processing. A better update would be to say "watch for excessive processing due to keytag collisions and abort when you detect it". --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On Feb 14, 2024, at 01:39, Petr Špaček wrote: > In my mind this is good enough reason to outlaw keytag collisions - without > them it would be _much_ easier to implement reasonable limits without risk of > breaking legitimate clients. Outlawing keytag collisions implies that the signer has to keep a copy of every keytag they've ever emitted. Adding that requirement nearly 20 years after the RFCs were finished is incredibly unlikely to work universally, so validators could not rely on it. Why add a requirement that cannot be relied on? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
I'm not a big fan of "whereas" clauses, partially because I'm related to rather large number of lawyers. Does anyone object to the following? Since the priming response is not a referral, root server addresses in the priming response are not considered glue records. Thus, RFC 9471 does not apply to the priming response and root servers are not required to set the TC bit if not all root server addresses fit within message size constraints. There are no requirements on the number of root server addresses that a root server must include in a priming response. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Dnsdir early review of draft-ietf-dnsop-rfc7958bis-00
On Feb 6, 2024, at 07:17, Florian Obser via Datatracker wrote: > > Reviewer: Florian Obser > Review result: Ready with Nits > > I have been selected as the DNS Directorate reviewer for this draft. The > DNS Directorate seeks to review all DNS or DNS-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the ADs. > For more information about the DNS Directorate, please see > https://urldefense.com/v3/__https://wiki.ietf.org/en/group/dnsdir__;!!PtGJab4!6S9q28SHczOYdpnCKXaXJu1oilTfH7vLs0xQf_RWxiIQcNuTmGpm3Twl69l62UsGqODyeK6cR8oBuSNSRi3HNmvz$ > [wiki[.]ietf[.]org] > > I think the document is basically ready. I spotted a few nits, feel free to > ignore as many as you like. > > * Abstract > >> This document describes the format and publication mechanisms IANA >> intends to use to distribute the DNSSEC trust anchors. > > while in "1. Introduction" we have: > >> This document describes the formats and distribution methods of DNSSEC >> trust anchors that have been used by IANA for the root zone of the DNS >> since 2010. > > Which one is it? Maybe this would be better: > >> This document describes the format and publication mechanisms IANA >> uses to distribute the DNSSEC trust anchors. Yep, that's better for the abstract. > > * 1. Introduction > >> A detailed description of corresponding >> key management practices can be found in [DPS], which can be >> retrieved from the IANA Repository at <https://www.iana.org/dnssec/>. > > It seems redundant to add a reference as [DPS] and then provide a link > in-line. Additionally the reference and in-line link are different: > https://www.iana.org/dnssec/ > vs. > https://www.iana.org/dnssec/procedures > > Maybe just shorten it to > >> A detailed description of corresponding key management practices can >> be found in [DPS]. Fair point. > > * 2. IANA DNSSEC Root Zone Trust Anchor Formats and Semantics > >> IANA publishes trust anchors for the root zone as an XML document >> that contains the hashes of the DNSKEY records. > > since IANA wishes to also publish the DNSKEY itself, maybe this is better: > >> IANA publishes trust anchors for the root zone as an XML document >> that contains the hashes of the DNSKEY records and optionally the keys >> from the DNSKEY records. Good catch! > > * Appendix A. Historical Note > > Missing text: >> The second KSK for use in the root zone of the DNS was [ MORE GOES >> HERE ]. > Yep, still TBD. Will fix. Thanks! --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
A note to those with opinions about what the root server operators (RSOs) should do: the draft authors would like the eventual RFC to be accurate, not aspirational. The RSOs are free to implement and deploy what they want within their own internal rules that are not covered in this document. Nothing in this document should be read to indicate what an RSO should do; if any text does, it is an error that we should correct (please send text diffs). --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
I have submitted -03, which covers the issues you raised in your AD review. Note that Duane and Mark had more to say on the topic of TC from the roots, but there was no agreement nor specific text proposed. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] New mailing list: DNS Delegation
Greetings. After the DNSOP interim meeting last week, Warren set up a new mailing list. Its description is: = There is a desire to have better methods for parent zones in the DNS to advertise DNS nameserver capabilities and zone features to resolvers. This list discusses mechanisms to provide this support within the DNS. This includes the ability to provide more information about a DNS delegation in record(s) at the parent, as well as additional capabilities beyond the DNS's current NS-style delegation. Examples include aliasing delegation with other domain names, delegating DNSSEC management to operators, specifying encrypted transports, and so on. = The new mailing list is a good place to discuss both the general idea of new types of delegation for the DNS, as well as specific proposals like the DELEG proposal which was first discussed at IETF-118. The list can be found at https://www.ietf.org/mailman/listinfo/dd Anyone interested in how delegation might work in the future should join. Thanks! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] BoF: New DNS Delegation, was DELEG Capabilities BoF
(Answering as the person who is currently supposed to run the BoF) On Feb 1, 2024, at 15:03, Paul Vixie wrote: > Thanks Roy. Would a new working group be open to skeptics? You have been in the IETF long enough to know that the answer is of course yes. > I remain concerned about gradually increasing systemic complexity, and I have > some ideas about how some stated goals of the DELEG proposal could have > complexity increase precisely linear to new functionality -- so, extending > beyond but not replacing the NS RRset model. > > But I would not want to crash a party. Nothing in the BoF description feels like a party... --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
On Jan 31, 2024, at 17:39, Paul Wouters wrote: > > On Wed, 31 Jan 2024, Paul Hoffman wrote: > >> On Jan 31, 2024, at 15:15, Paul Wouters wrote: >>> Can they write a draft with why they are going against the RFC? >> >> Yes, that is possible. However, I think it would be unfair to the DNS >> community to hold up draft-ietf-dnsop-rfc8109bis waiting for that to happen, >> and it would be a bad policy to make draft-ietf-dnsop-rfc8109bis less honest >> about the current and possible future waiting for that to happen. > > As Mark just clarified. This isn't glue, so perhaps the text just needs > updating. The current text is: If some root server addresses are omitted from the Additional section, there is no expectation that the TC bit in the response will be set to 1. At the time that this document is written, many of the root servers are not setting the TC bit when omitting addresses from the Additional section. Note that updates with respect to the use of the TC bit. It says "If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server must set the TC (Truncated) flag to inform the client that the response is incomplete and that the client should use another transport to retrieve the full response." Maybe we should add to the second paragraph: Note, however, the root server addresses are not glue records, so setting the TC bit in truncated responses from the root servers is not required by RFC 9471. Does this solve your and Warren's issues? > It raises another question why some root servers do set the TC > bit though. If I read 1035 correctly, it specified the TC bit for all truncation, not just for truncated glue records. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
On Jan 31, 2024, at 15:15, Paul Wouters wrote: > Can they write a draft with why they are going against the RFC? Yes, that is possible. However, I think it would be unfair to the DNS community to hold up draft-ietf-dnsop-rfc8109bis waiting for that to happen, and it would be a bad policy to make draft-ietf-dnsop-rfc8109bis less honest about the current and possible future waiting for that to happen. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
On Jan 31, 2024, at 11:38, Warren Kumari wrote: > > Hi there, authors (and WG), > > Thank you for this document — I have some questions / comments before I can > progress it. > > Firstly, the (presumably) easy one: > The document says: > "This document, when published, obsoletes RFC 8109." - can you add something > along the lines of "Section 1.1 contains a list of changes from RFC 8109" or > similar…. Sure. > > Now the harder one… > Sec 4.2: > "If some root server addresses are omitted from the Additional section, there > is no expectation that the TC bit in the response will be set to 1. At the > time that this document is written, many of the root servers are not setting > the TC bit when omitting addresses from the Additional section. > > Note that [RFC9471] updates [RFC1035] with respect to the use of the TC bit. > It says "If message size constraints prevent the inclusion of all glue > records for in-domain name servers, the server must set the TC (Truncated) > flag to inform the client that the response is incomplete and that the client > should use another transport to retrieve the full response." " > > IMO, this text is confusing…. > It sounds like it is saying "RFC9471 says you must set TC if you truncate the > glue. The root server folk are ignoring RFC9471, bad root server folk…" > > I have read the discussion in the WGLC ( inc > https://mailarchive.ietf.org/arch/msg/dnsop/wtjuoVqkKmww988Hyq2QDq_nKpA/ and > am assuming it was rewritten as "If some root server addresses are omitted > from the Additional section…".), but I don't really think that really > addresses my concern — it's easy to miss the subtleties and the "all glue > records" vs "some addresses" bit is tricky. > > It's also true that "At the time that this document is written, many of the > root servers are not setting the TC bit when omitting addresses from the > Additional section." — RFC9471 was only published at the end of September, > there is an open BIND bug to update this behavior (I think! - > https://gitlab.isc.org/isc-projects/bind9/-/issues/4540 ), and is planned to > change in 9.19.x (I think!) > > So, while what it written is all technically correct[0], the tone feels > weird. I think that some of this is because ot the timing of when this and > RFC9471 were written. Nope. The tone is because some root server operators want the ability to continue to not set the TC bit due to root server operational independence. We have to be honest about what is happening, and what the rules are. > RFC8109 was published 7 years ago, and I'm hoping that rfc8109bis will > survive at least that long. Yep, if not longer. > I don't know how we address my concern, but it feels like, in e.g 6 years, > this text will have aged poorly... Or it might still be accurate. We cannot tell ahead of time. > Can you see about some more massaging of this text? Not without suggestions from you or the WG about how to massage while being honest. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Two points by Joe - was Re: [Ext] Re: DELEG and parent only resolution
On Jan 31, 2024, at 10:03, Dave Lawrence wrote: > > Edward Lewis writes: >> The impact on the registration system wasn’t raised at the table. > > Not entirely true. We did recognize that there'd need to be an EPP > draft too. And a very early one is available: https://datatracker.ietf.org/doc/draft-brown-epp-deleg/ --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] on private use TLDS: .interNAL -> .LAN
Wearing my ICANN hat: When a topic is in a public comment period, it is very appropriate and appreciated for community members to send comments in, as Paul Marks has. Having a discussion on an external forum will have no effect on the public comment period because the comment from Paul Marks is already logged. When the comment period is over, IANA will read all the comments and respond in a single large report. (In case you want to comment: https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024) --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Followup Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping
I support the publication of this document. As I told the authors a long time
ago, I'm still uneasy with all the capitalization ("Client" and so on) because
it disagrees with our Terminology RFC, and still offer to do a massive pull
request to fix it, but if they want to keep it, that's up to them.
--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc8109bis
On Jan 16, 2024, at 16:46, Wessels, Duane wrote: > > I made a pass through the document and have the following feedback. Thanks! >> Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. The >> scenario used in that description, that of a recursive server that is >> also authoritative, is no longer as common. > > Since RFC 1034 doesn't use the term "priming" maybe it would be good to be > more descriptive here? For example: > > Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034], where > it is referred to as a "safety belt" or part of the SBELT structure. Yep, already got that from earlier comments. > >> Research shows that after those addresses change, some resolvers >> never get the new addresses. > > If you feel like this would benefit from a reference, > https://indico.dns-oarc.net/event/24/contributions/378/ is one such that > would fit. Sounds good. Let's hope DNS-OARC prevents URL rot. >> Root server >> identifier and address changes are the main reasons that resolvers >> need to do priming instead of just going from a configured list to >> get a full and accurate list of root servers. > > I find "to get a full..." at the end here to be confusing. Maybe a slight > reordering and rewording? > > Root server identifier and address changes are the main reasons that > resolvers need to use priming to get a full and accurate list of root > servers, instead of just using a statically configured list. Excellent, yes. > >> A priming query is a DNS query used to get the root server >> information in a resolver. > > I find the above imprecise. Perhaps: > > A priming query is a DNS query whose response provides root server > names and addresses. Yep. > >> If a resolver chooses to pre-fetch the root NS RRset before that >> RRset has expired in its cache, it needs to choose whether to use the >> addresses for the root NS RRset that it already has in its cache or >> to use the addresses it has in its configuration. Such a resolver >> SHOULD send queries to the addresses in its cache in order to reduce >> the chance of delay due to out-of-date addresses in its >> configuration. > > This section doesn't say what a non-pre-fetching resolver should do. > Does it imply or mean that a non-pre-fetching resolver can only re-prime > from the original configuration? No, it just doesn't say. This was discussed during the run-up to RFC 8109, and there was not consensus on a SHOULD for those resolvers. >> Resolver software SHOULD NOT expect 13 NS RRs because > > This is somewhat out of the blue. There is no prior discussion on the number > of > root server identifiers. Although there is immediately after... Already fixed from an earlier comment. > >> If the Additional section is truncated, there is no expectation that >> the TC bit in the response will be set to 1. At the time that this >> document is written, many of the root servers are not setting the TC >> bit on responses with a truncated Additional section. > > I think I tried to argue about this phrasing before, but looks like I was > unsuccessful. > IMO truncated should mean TC=1 and TC=1 should mean truncated. I don't think > its okay to say that a message can be truncated but TC bit not set. RFC 1035 > says: > > TCTrunCation - specifies that this message was truncated >due to length greater than that permitted on the >transmission channel. > > It would be better to use "partial" instead of "truncated" here. e.g.: > > If the Additional section contains a partial set of A / RRsets, there > is no expectation that > the TC bit in the response will be set to 1. At the time that this > document is written, many of the root servers are not setting the TC > bit on responses when not all A / RRsets fit in the Additional section. This too was caught in an earlier review, and is now "If the Additional section omits some root server addresses..." --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc8109bis
On Jan 16, 2024, at 12:30, Tim Wicinski wrote: > > This is a followup on our Working Group Last Call for > draft-ietf-dnsop-rfc8109bis is ongoing until Monday January 22, 2024. > > There has been support for publication, but we are always looking for more > feedback. > The comments raised appear to have been resolved by the authors. If someone > feels we missed something, please speak up. ...and we still would love more feedback! --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc8109bis
Thanks for the support and comments so far. The authors have incorporated the comments in the repo for a new version after WG Last Call; see <https://github.com/paulehoffman/priming-bis>. Please keep them coming! --Paul Hoffman On Jan 8, 2024, at 17:54, Tim Wicinski wrote: > All > > > This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis > "Initializing a DNS Resolver with Priming Queries" > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/ > > The Current Intended Status of this document is: Best Current Practice > > Please review the draft and offer relevant comments. > > For WGLC, we need *positive support and constructive comments*; lack of > objection is not enough. > So if you think this draft should be published as an RFC, please say so. > > If you feel the document is *not* ready for publication, please speak out > with your reasons. > > > This starts a two week Working Group Last Call process, and ends on: January > 22, 2024 > > thanks ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc8109bis
On Jan 10, 2024, at 14:05, Roy Arends wrote:
> I support this documents.
Thanks!
> Furthermore, here are some comments:
>
>2. Description of Priming
>
>Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. The
>scenario used in that description, that of a recursive server that is
>also authoritative, is no longer as common.
>
> The term “Priming” is not used in RFC1034. What is used in RFC1034 is the
> term SBELT ("safety belt” structure), defined in 5.3.2. The reference is more
> useful when the term SBELT is included.
Good idea; fixed.
> “published”
Already caught in all places, thanks.
>A machine-in-the-middle attack on the priming query could direct a
>resolver to a rogue root name server. Note, however, that a
>validating resolver will not accept responses from rogue root servers
>if they are different from the real responses because the resolver
>has a trust anchor for the root and the answers from the root are
>signed. Thus, if there is a machine-in-the-middle attack on the
>priming query, the results for a validating resolver could be a
>denial of service, or the attacker seeing queries while returning
>good answers, but not the resolver's accepting the bad responses.
>
> This is misleading. Not all answers from the root are signed. Some content in
> the root zone is signed, delegation point NS records are not. This attack
> will be successful when rogue root-servers change delegation information to
> unsigned zones. This needs to be more precise.
>
>If the "root-servers.net" zone is later signed, or if the root
>servers are named in a different zone and that zone is signed, having
>DNSSEC validation for the priming queries might be valuable. The
>benefits and costs of resolvers validating the responses will depend
>heavily on the naming scheme used.
>
> Not necessarily. This attack will be successful when rogue root-servers
> change delegation information to unsigned zones (see above) and is not
> dependent on a naming scheme.
Excellent catch: fixed. (Background: more than a few ccTLDs are not signed.)
>4. Priming Responses
>
>A priming query is a normal DNS query. Thus, a root server cannot
>distinguish a priming query from any other query for the root NS
>RRset. Thus, the root server's response will also be a normal DNS
>response.
>
> Apologies for sounding pedantic, but what is “a normal DNS query” or a
> “normal DNS response” ?
>
> If there is no definition, maybe the following works for you:
>
> The term “Priming” reflects the intent of the resolver. A root server cannot
> distinguish a priming query from any other root type NS query. The root
> server's response will therefore be an ordinary DNS response.
We could replace "normal" with "ordinary", but they sound similar to me.
>
>4.2. Completeness of the Response
>
>At the time this document is pulished, there are 13 root servers.
>
> “published"
>
> There are 13 hostnames, or root server identifiers. "13 root servers" implies
> that there are 13 physical boxes.
Already fixed from earlier comments.
>Each has one IPv4 address and one IPv6 address. Not even counting
>the NS RRset, the combined size of all the A and RRsets exceeds
>the original 512-octet payload limit from [RFC1035].
>
> Remove “Not even counting the NS RRset, ”. The remainder of the sentence says
> enough.
Ack.
>In the event of a response where the Additional section omits certain
>root server address information, re-issuing of the priming query does
>not help with those root name servers that respond with a fixed order
>of addresses in the Additional section. Instead, the recursive
>resolver needs to issue direct queries for A and RRsets for the
>remaining names. At the time this document is pulished, these RRsets
>
> “published”
>
>would be authoritatively available from the root name servers.
>
>5. Post-Priming Strategies
>
>When a resolver has a zone's NS RRset in cache, and it gets a query
>for a domain in that zone that cannot be answered from its cache, the
>resolver has to choose which NS to send queries to. (This statement
>is as true for the root zone as for any other zone in the DNS.) Two
>common strategies for choosing are "determine the fastest nameserver
>
> “name server”
Ack.
Thanks!
--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Priming and RFC 8806
On Jan 9, 2024, at 19:17, Paul Hoffman wrote: >> Perhaps a recommendation could be to check with ZONEMD and do an AXFR, >> eg recomend implementing RFC 8806 - "Running a Root Server Local to a >> Resolver". >> Comes with added bonuses on top of a signature on all the root glue. >> >> I still think this would also still be good to mention. > > This would be a very comfusing mention because the resolver isn't really > "priming" at that point, it's using a complete root zone. I'll cover this > with an addition to the Security Considerations section: > > This document does not cover the use of (or the need for) priming when > serving a copy of the full root zone on the same server as the resolver, > such as is described in . > In such a setup, the resolver never really primes its cache because the > cache is full as soon as the resolver pulls down a new complete root zone. > > (Suggestions for better wording are welcome!) Or, as PaulW just pointed out to me offline, I might just be wrong. RFC 8806 puts a copy of the root zone in an authoritative service next to the resolver, not into the cache. Thus, priming the cache is still needed, it's just done much more locally. I have removed the paragraph proposed above, and replace it near the front of the document with: Some systems serve a copy of the full root zone on the same server as the resolver, such as is described in . In such a setup, the resolver primes its cache using the same methods as described in the rest of this document. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc8109bis
Thanks for the support for the doc; I hope others chime in as well. On Jan 9, 2024, at 08:33, Paul Wouters wrote: > > there are 13 root servers. > > I would really like to see this changed. We keep trying to tell people > that are not DNS insiders that the world does not depend on just 13 > physical machines. This will cause that confusion to strengthen again. Good catch; fixed. >> It is in DNS master file format >> >> Maybe use "zone file presentation format" instead of "master file format" > > This still stands as well. Agree; fixed. > Perhaps a recommendation could be to check with ZONEMD and do an AXFR, > eg recomend implementing RFC 8806 - "Running a Root Server Local to a > Resolver". > Comes with added bonuses on top of a signature on all the root glue. > > I still think this would also still be good to mention. This would be a very comfusing mention because the resolver isn't really "priming" at that point, it's using a complete root zone. I'll cover this with an addition to the Security Considerations section: This document does not cover the use of (or the need for) priming when serving a copy of the full root zone on the same server as the resolver, such as is described in . In such a setup, the resolver never really primes its cache because the cache is full as soon as the resolver pulls down a new complete root zone. (Suggestions for better wording are welcome!) > >> [[ This section talks about sending the DO bit, but does not actually >>talk about validating the response to the priming query. This became >>important after the root KSK rollover in 2018 because some resolvers >>apparently were validating and only had the old KSK, but were still >>sending RFC 8145 telemetry even after failing to validate their >>priming response. ]] > > I said before: > > Nothing much can be done here other than advising implementers to check > if the obtained DNSKEY RRset no longer contains any KSK that is > configured as part of the software, and then doing some kind of > exponential back-off to slow down the query rate? > > The comment was removed but no text was added for this ? Should there be? I'm not seeing what adding this would solve. The only possible attack is that the old key was compromised by the machine-in-the-middle attacker, but that is a completely separate issue from priming because the priming response is not (currently) signed. > I also wrote before: > > So now I do think the document is ready, but I think it would be nice to > mention ZONEMD and local root configurations as methods to protect > against spoofed glue. See above. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] WGLC draft-ietf-dnsop-rfc8109bis (2nd round)
On Dec 28, 2023, at 13:34, Tim Wicinski wrote: > > All, > > We wrapped up the second working group last call for > draft-ietf-dnsop-rfc8109bis with no comments pro or con. > The chairs can only assume the working group is not interested in moving this > work forward. > > We are going to discuss this with Warren on our next steps here. Wearing my co-author hat, I'm interested in what the WG wants to do with the changes from RFC 8109 that are listed in the latest draft. 1.1. Changes from RFC 8109 This document obsoletes [RFC8109]. The significant changes from RFC 8109 are: * Added section on the content of priming information. * Added paragraph about no expectation that the TC bit in responses will be set. * Added paragraph about RFC 9471 and requirements on authoritative servers and the TC bit. * Changed "man-in-the-middle" to "machine-in-the-middle" to be both less sexist and more technically accurate. * Clarified that there are other effects of machine-in-the-middle attacks. * Clarified language for root server domain names as "root server identifiers". * Added short discussion of post-priming strategies. * Added informative references to RSSAC documents. * Added short discussion about this document and private DNS. * Added discussion of where resolvers that pre-fetch should get the root NS addresses. * Elevated the expectations in "Expected Properties of the Priming Response" to MUST-level. * Clarified that "currently" means at the time that this document is published. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Notification Call for Adoption: draft-bash-rfc7958bis
On Dec 19, 2023, at 11:27, Michael StJohns wrote: > > After reading the thread, I'm confused as to why there's any question as to > adoption. This is an independent submission replacing an independent > submission The whole point to a call for adoption in an IETF WG is that this is *not* meant to be an independent submission: it is meant to be an IETF work product. > , and is directive only on ICANN and explanatory for everyone else. > > Section 5 has "This document describes how DNSSEC trust anchors for the root > zone of the DNS are published." That's incomplete: "This document describes > ... are published by ICANN." is more correct. Good point; will fix. > So the IETF will have no real change control over this document. Not at all true. The IETF gets complete change control over any WG document. Of course, if the WG doesn't adopt the draft, it will likely go through the ISE stream again, but the intent of IANA and the authors is to have this be an IETF document. > There's no reason to make this a WG draft - and lots of (we're too busy > already) reasons not to. If the IETF wants input about how the root's trust anchors are handled, doing so in an IETF-managed RFC seems like the best way to do that. > Instead, make sure the ISE knows that we'd (DNSOP) like a chance to comment > before publication, but that DNSOPs comments should not be show stoppers. To > address Geoff's note below - the mere desire to have external/peer review > does not translate into a need to make this a WG draft. Fully agree: making this a WG draft *also* gives the WG control over its contents. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Notification Call for Adoption: draft-bash-rfc7958bis
On Dec 18, 2023, at 18:33, Paul Wouters wrote: > > On Mon, 18 Dec 2023, Geoff Huston wrote: > >> I am in support of adoption by the Working Group. The process of peer review >> has proved to be highly valuable over the years and the result is generally >> a more robust framework for critical elements of the DNS infrastructure. > > I agree, but also understand the situation could be strange. What if the > WG would want some text but the authors representing the Root Zone > operator cannot or do not want to do this? This is a very weird question. The authors of a WG document serve at the behest of the WG via the chairs. The authors never get to override WG consensus or, later, IETF consensus. > I guess at that point the > document would have to move to the ISE ? If a group of authors want to write an RFC that doesn't need to have IETF consensus, they should go straight to the ISE. This group of authors very intentionally didn't do that. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: Change the status of GOST Signature Algorithms in DNSSEC in the IETF stream to Historic
[[Forwarding this to DNSOP because apparently the IESG forgot to...]] The IESG has received a request from an individual participant to make the following status changes: - RFC5933 from Proposed Standard to Historic (Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC) The supporting document for this request can be found here: https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic/ The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The affected document can be obtained via https://datatracker.ietf.org/doc/rfc5933/ IESG discussion of this request can be tracked via https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic/ballot/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] QNAME minimization is bad
On Nov 10, 2023, at 21:41, David Conrad wrote: > > John, > > On Nov 10, 2023, at 11:55 AM, John Levine wrote: >> DNSBLs have been around a lot longer than QNAME minimization. > > Not sure that’s relevant — I presume you’re not suggesting DNSBLs are a > predominant use of the DNS. DNSBLs are one of the biggest use cases for the DNS outside of "find me the host". They are one of the primary reasons your inbox is not drowning worse in spam. >> They >> work(ed) fine without minimization and I don't think it is reasonable >> to expect every mail system in the world to change their configuration >> to work around our performance bug. > > I thought the point of QNAME minimization was to improve privacy. It is. Nothing in the John's proposal would reduce that, would it? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] QNAME minimization is bad
On Nov 10, 2023, at 14:23, Paul Wouters wrote: > >> I'd like to write a draft that updates RFC 9156 by describing situations >> like this that caches could recognize and avoid useless churn, added to >> section 2.3 which already suggests special casing underscored labels. > > Couldn't the RBL's add an underscore in their base zone name to trigger > the special casing in 9156? That would not require a new RFC and > perhaps might not require code updates? As I understand it, John is proposing a non-normative update for one small set of queriers, which is similar to what we already have for a different set of queriers. I don't have a problem with that. And other people may have other observations on QNAMEmin that would be good to document. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Warren did a bad (was Re: Datatracker State Update Notice: )
On Oct 22, 2023, at 10:28, Paul Wouters wrote: > > I thought we all agreed the IESG would mark the old GOST RFCs Historic and > then the new RFCs don’t have to obsolete anything ? Define "we all". I don't think that decision was made (nor even announced) in the DNSOP WG where the documents originated. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-bash-rfc7958bis
On Oct 13, 2023, at 08:21, Paul Wouters wrote: > > On Thu, 12 Oct 2023, Tim Wicinski wrote: > >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-bash-rfc7958bis/ >> Here is the diff from RFC7958 itself: >> https://author-tools.ietf.org/iddiff?url1=rfc7958&url2=draft-bash-rfc7958bis-01&difftype=--html >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and send any comments to the list, clearly stating your view. >> Please also indicate if you are willing to contribute text, review, etc. > > Suitable for adoption. I do find it a little strange the document is > basically IANA publishing policy, and the document containing > non-IANA/ICANN authors :P The same was true for RFC 7958. Maybe we've mostly forgotten the "OP" part of DNSOP. In order to operate a validating DNS resolver, you need to understand how the trust anchors are published. This describes that. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc8109bis
On Sep 14, 2023, at 18:46, Tim Wicinski wrote: > We chairs heard back from the authors and we're pulling this working group > last call. We have turned in a -01 that addresses the initial comments in the WG Last Call that the document had obvious labeled holes in it. One of those holes had an old label on it, but the others needed filling, and we have done that now. Whenever the chairs have another slot to start a WG Last Call, we think this is now ready for it. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Zaheduzzaman Sarker's Discuss on draft-ietf-dnsop-rfc8499bis-09: (with DISCUSS and COMMENT)
On Sep 21, 2023, at 1:26 AM, Zaheduzzaman Sarker wrote: > Thanks Paul, will wait for the fixes in the upcoming revision and I will > clear my Discuss when that version is out. Greetings again. We have just submitted -10 which we think fixes the issue in your DISCUSS ballot. Please see the diff at <https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8499bis-10>. Thanks again for your comments! --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Zaheduzzaman Sarker's Discuss on draft-ietf-dnsop-rfc8499bis-09: (with DISCUSS and COMMENT)
On Sep 20, 2023, at 2:48 PM, Zaheduzzaman Sarker wrote: > > > > On Wed, Sep 20, 2023 at 5:22 PM Paul Hoffman wrote: > On Sep 20, 2023, at 3:23 AM, Zaheduzzaman Sarker via Datatracker > wrote: > > -- > > DISCUSS: > > -- > > > > Thanks for working on this documentation. > > > > I have one point that I would like to discuss to clarify the definition > > understanding, I hope addressing this would improve this document. > > > > It defines- > > > >Full resolver: > > This term is used in [RFC1035], but it is not defined there. RFC 1123 > > defines a > > "full-service resolver" that may or may not be what was intended by "full > > resolver" in [RFC1035]. This term is not properly defined in any RFC. > > > > While section 6 starts with - "This section defines the terms used for the > > systems that act as DNS clients, DNS servers, or both. ". It does not really > > define "Full resolver". I am not sure what I am supposed to do with the > > definition (more like description) provided here. This should be clarified. > > what was the consideration here? > >> We touch on the topic of "not defined in earlier RFCs" at the beginning of >> the introduction, and there are other terms in other parts of the document >> that fall into that category, most notably "host name". In the case of "full >> resolver", the WG decided not to make up a definition in this document >> because the term in not used much any more. However, because it is used many >> times in the foundational DNS documents (RFCs 1035 and 1123), the WG wanted >> it listed here to show that it there is no current agreement on what it >> means. >> >> Would it help if we amended the above description (you are correct that it >> is not a definition) by changing the last sentence to "This term is not >> properly defined in any RFC, and there is no consensus on what the term >> means"? >> > This could work, as there is no "consensus on what the team means" and we > can't undefine it as it is in the foundational document. I think we can > actually discourage the usage of this term. May I suggest which will help > reader like me to understand what to do - > > "This term is not properly defined in any RFC, and there is no consensus on > what the term means. Hence the use of these term without proper context is > discouraged" Will fix. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Zaheduzzaman Sarker's Discuss on draft-ietf-dnsop-rfc8499bis-09: (with DISCUSS and COMMENT)
On Sep 20, 2023, at 3:23 AM, Zaheduzzaman Sarker via Datatracker wrote: > -- > DISCUSS: > -- > > Thanks for working on this documentation. > > I have one point that I would like to discuss to clarify the definition > understanding, I hope addressing this would improve this document. > > It defines- > >Full resolver: > This term is used in [RFC1035], but it is not defined there. RFC 1123 defines > a > "full-service resolver" that may or may not be what was intended by "full > resolver" in [RFC1035]. This term is not properly defined in any RFC. > > While section 6 starts with - "This section defines the terms used for the > systems that act as DNS clients, DNS servers, or both. ". It does not really > define "Full resolver". I am not sure what I am supposed to do with the > definition (more like description) provided here. This should be clarified. > what was the consideration here? We touch on the topic of "not defined in earlier RFCs" at the beginning of the introduction, and there are other terms in other parts of the document that fall into that category, most notably "host name". In the case of "full resolver", the WG decided not to make up a definition in this document because the term in not used much any more. However, because it is used many times in the foundational DNS documents (RFCs 1035 and 1123), the WG wanted it listed here to show that it there is no current agreement on what it means. Would it help if we amended the above description (you are correct that it is not a definition) by changing the last sentence to "This term is not properly defined in any RFC, and there is no consensus on what the term means"? > -- > COMMENT: > -- > > In the spirit of defining the "global DNS" and "private DNS", the security > section should perhaps remove the use of "the DNS" and use "global DNS" and > "private DNS" instead. A very minor comment. But a good one! Given that some people will read the Security Considerations more carefully than the other sections, it's good to remind the reader of the difference here. Will fix. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Murray Kucherawy's No Objection on draft-ietf-dnsop-rfc8499bis-09: (with COMMENT)
On Sep 16, 2023, at 11:07 PM, Murray Kucherawy via Datatracker wrote: > > I thought the IESG (though maybe not this particular one) had previously > discouraged publishing "living documents" like this one in the RFC series. Is there a better reference to this policy? If the IESG has made a statement about this, it would be good for the relevant AD to know so they can remind the WG of this well before a doc gets to IESG review. > So > why aren't we doing this as a wiki page or something? I would be surprised if the IESG wanted to make a BCP (which this document is) "wiki page or something", but if you did, we could do that conversion. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09
On Sep 15, 2023, at 6:01 PM, Salz, Rich wrote: > >> This is the first time someone has suggested this, even though you're right >> that it is a term we still sometimes here. I think it is unwise to add this >> this late in the review cycle (it's already on the telechat agenda, and a >> new definition would have to go back to the WG), but we'll try to remember >> it if there is a fourth edition of the doc. > > If you coordinate with the AD, you only have to remember until the RFC is > published and then file an errata. A completely new definition that has not been vetted by the WG is inappropriate for an erratum. > On the other hand, spending a week or two repeating a cycle to get an > important term in the current document seems like a better solution. If the WG agrees that this is an important term, sure. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Question regarding RFC 7793
This is the wrong mailing list to get help with your individual problem. You really need to get advice from the device vendor or their support forums. Good luck! --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09
Thanks for your review!
On Sep 15, 2023, at 12:39 PM, Vijay Gurbani via Datatracker
wrote:
> Minor:
> - Global
> - I am surprised that the term "Round robin DNS" is not defined in this
> document. Is it worth defining? It is used quite a bit.
This is the first time someone has suggested this, even though you're right
that it is a term we still sometimes here. I think it is unwise to add this
this late in the review cycle (it's already on the telechat agenda, and a new
definition would have to go back to the WG), but we'll try to remember it if
there is a fourth edition of the doc.
> - S2, in the definition of "Global DNS", second paragraph: In the last
> sentence of the paragraph, you use "octet" and "byte" interchangably.
> Perhaps stick to octets as we are talking about a collection of eight
> bits on the wire.
Good catch. We use "octet" when that was in the original definition, and "byte"
otherwise. We will add a note about this equivalence in the introduction.
> - S5, in the definition of EDNS, the text says, "...to indicate the version
> number." Is there a EDNS(1) (or EDNS1)?
No, not yet.
> I don't believe so, but it has
> been a while since I was caught up on latest work in DNS. AFAIK, it has
> always been called EDNS0, from back in rfc2671, RFC6891 continued with
> EDNS0 instead of EDNS1. Is it worth to provide historical perspective
> and say that till now, the version number has not changed since rfc2671?
It might be premature. The topic of "let's fix EDNS0" comes up occasionally,
although so far has not progressed. I'd rather not have this document look like
it is taking a stand at all.
> - S6, RDoT and ADoT: I do not believe that rfc7858 definies these terms.
> Is it worth referencing where these terms originated from?
We will make it clear that they came up informally, not in RFCs. (There is an
RFC that is in front of the IESG simultaneous to this one that defines them,
but that is not where they were first used.)
> Nits
> - S2, right above "Private DNS:", please expand PTI on first use.
Will do.
> - S3, in the definition of QNAME,
> s/this creates kind of confusion/this creates confusion/
> ("kind of" is okay for colloquial use, but not in standards documents.)
Agree.
Thanks!
--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Dnsdir early review of draft-ietf-dnsop-rfc8109bis-00
Thanks for the early review! We will fix these things in the -01 On Aug 29, 2023, at 1:17 AM, Di Ma via Datatracker wrote: > 1)In Section 2.1, there is a typo in “The priming information in software may > be in any format that gives he software the addresses associated with at least > some of the root server identifiers.” > > “he” right before “software ” should have been “the”. Yep. > 2)In Section 3.1, as in “Because the NS records for the root are not special”, > there would be better “root zone” here instead of just “root”. Agree. > 3)In Section 4.2, as in “There are currently 13 root servers. All have one > IPv4 > address and one IPv6 address. ” > > I suggest “Each has one single IPv4 address and one single IPv6 address. ” Yes, better. > 4)On the whole, this document uses “root name server” somewhere and “root > server” somewhere else. I suggest using only one of them to keep terminology > consistence. Agree. We'll do a -01 when there are more reviews. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Dnsdir last call review of draft-ietf-dnsop-rfc8499bis-09
Thanks for your review! On Aug 28, 2023, at 1:24 AM, James Gannon via Datatracker wrote: > Section 1: > Personal Preference: The intro section seems to be a little unfocused, if you > take another pass at the document I would suggest tightening it down to the > doc's goal more succinctly. I agree that the introduction has now strayed beyond "what are the goals of this document", but the other things there were added at the request of the WG (mostly in RFC 7719 or 8499) and should be seen before you read the body of the document. I don't think adding a sub-section 1.1 would make it much better. > Section 2: Context for resolving a name: The global DNS root zone distributed > by PTI. - This line seems to be very light compared to others It is, because we wanted to be as succinct as possible on this contentious topic. If you have suggested text for a helpful expansion that doesn't cause too much grief in the WG, that would be great. > Suggestion: This kind of document would work well in a more dynamic format > similar to some of the work being done on updating the IETF Tao, something to > potentially consider post-publishing. Humorous side-note: I was the person who spearheaded moving the Tao to a web site. It was ultimately useful, but the process engendered strongly-held design opinions from a surprisingly wide audience. I would not recommend to anyone... --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] should all ccTLD be on the Public Suffix list?
Why is this discussion here and not on the PSL mailing list (https://groups.google.com/g/publicsuffix-discuss)? Having it there would greatly increase the chance that the discussion would actually help the PSL. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] draft-dnsop-dnssec-extension-pkix on IETF117 dnsop agenda?
On Jul 16, 2023, at 12:06 PM, Viktor Dukhovni wrote: > Would it possible to defer discussion of this document to such time as > some evidence of support emerges, and in the meantime use the timeslot > for more realistically productive proposals? +1. The 15 minutes allocated to this draft would be better spent on longer mic lines for the other drafts that have a higher likelihood of adoption. Once this draft has more on-list discussion, if those of us who are skeptical are wrong, the discussion in Prague will be even more fruitful. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
