Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec-ttl
On 03-02-2021 20:31, Paul Hoffman wrote: For each of these, I'd recommend specifying what a client does in each of the cases, rather than weasel wording the SHOULD with respect to the zone contents to turn this into an implementable protocol. Here, I agree that the draft is unclear. It should say explicitly "resolvers keep doing $z, there is no change here". Also, for the text about authoritative servers, I agree that changing the SHOULDs from the current standards to MUSTs. Changing this to MUST means that every time a zone changes its SOA TTL or SOA MINIMUM value, the whole chain of NSEC/NSEC3 records need to be updated accordingly immediately. That may be undesirable for a large zone. BIND for example would make such a change incrementally, so there may be a period of time where the NSEC/NSEC3 records still have the TTL of the previous SOA TTL/MINIMUM value. With a SHOULD keyword we can keep this behavior. With a MUST less so, I think. So I am against changing these SHOULDs to MUSTs. Best regards, Matthijs ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec-ttl
> On Feb 3, 2021, at 3:24 PM, Michael StJohns wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > On 2/3/2021 2:31 PM, Paul Hoffman wrote: >> On Jan 29, 2021, at 9:31 AM, Michael StJohns wrote: >>> I can't support this as Standards track even though it purports to update >>> standards as it doesn't actually specify an implementable protocol. >>> Basically, this is dependent upon humans doing the right thing, rather than >>> specifying behavior of the protocol. >> I don't understand the context of this. The draft specifies that the >> protocol is changing, and now authoritative servers change the way they act >> from $x to $y. Where is the "humans" part? > > You're not specifying a change in how the Auth servers work AFAICT, you're > specifying a change in the data parameters for a few records which get set by > humans (and maybe enforced by tools, not necessarily by the server). This is > operational guidance rather than implementation guidance - the servers > continue to serve the data they are provided regardless of whether its > "right" with respect to this guidance. I agree its not specifying a change in how servers work. And I agree its specifying a change in data parameters. But I don't agree that NSEC TTLs get set by humans. Certainly not in the same way that other TTLs do. So in my view this is really implementation advice, not operational advice. > > For example, one of the texts you reference (RFC4034 Section 4) is all about > crafting the contents of the data protocol, rather than what the server > should do to enforce things. It probably should have said instead - "The > authoritative server SHOULD treat (and send) the TTL of the NSEC RR as having > the same value as the SOA minimum TTL field" 4034 probably should've said nothing about NSEC TTLs and just left it to 4035. Where this draft updates 4035 to say "The TTL value for any NSEC RR SHOULD" I think it might be better to say "each NSEC RR" rather than any? > > So I'm fine with the changes to the TTL setting, but you need to impose the > requirement on the client to do the right thing even if the data creator > screws up and does the wrong thing. I think the draft already explains why that it not always possible. The client might not have any other information that it can use to do the right thing. But as Paul is suggesting upthread if the client does have the other information (SOA) then yes, it could change its caching behavior. DW smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec-ttl
On Feb 3, 2021, at 3:24 PM, Michael StJohns wrote: > > On 2/3/2021 2:31 PM, Paul Hoffman wrote: >> On Jan 29, 2021, at 9:31 AM, Michael StJohns wrote: >>> I can't support this as Standards track even though it purports to update >>> standards as it doesn't actually specify an implementable protocol. >>> Basically, this is dependent upon humans doing the right thing, rather than >>> specifying behavior of the protocol. >> I don't understand the context of this. The draft specifies that the >> protocol is changing, and now authoritative servers change the way they act >> from $x to $y. Where is the "humans" part? > > You're not specifying a change in how the Auth servers work AFAICT, you're > specifying a change in the data parameters for a few records which get set by > humans (and maybe enforced by tools, not necessarily by the server). This seems like a deep misreading of RFC 2308. Section 3 says: Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists. This is required so that the response may be cached. The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer. "The TTL of this record is set from" means that the value *in the SOA that is returned* is set to the minimum of $a and $b. I cannot see how this can be read as "The human setting $a of the record sets it as the minimum of $a and $b". That is nonsensical. The sentence is about the TTL in the SOA that is being returned, not the TTL from the record in the file. > This is operational guidance rather than implementation guidance - the > servers continue to serve the data they are provided regardless of whether > its "right" with respect to this guidance. This is implementation guidance: authoritative servers who are about to send out an SOA record need to compare $a and $b, and use the lower of those two as the TTL in the SOA that is sent out. > For example, one of the texts you reference (RFC4034 Section 4) is all about > crafting the contents of the data protocol, rather than what the server > should do to enforce things. It probably should have said instead - "The > authoritative server SHOULD treat (and send) the TTL of the NSEC RR as having > the same value as the SOA minimum TTL field" Yes, exactly! (Notice the lack of humans there.) This draft could update it that way, but to include the "lesser of $x and $y" as well. > But then that gets into signing issues for the NSEC record and its > verification and you'd need to make sure that the signing part of this is > back filled to make sure that what's signed agrees with what the server is > actually sending. Fully agree. A note about that is important as well. > 8198 section 5.4 actually specifies an implementable behavior in that it > tells the client how to treat received and cached data. Agree. >>> For each of these, I'd recommend specifying what a client does in each of >>> the cases, rather than weasel wording the SHOULD with respect to the zone >>> contents to turn this into an implementable protocol. >> Here, I agree that the draft is unclear. It should say explicitly "resolvers >> keep doing $z, there is no change here". Also, for the text about >> authoritative servers, I agree that changing the SHOULDs from the current >> standards to MUSTs. >> >> I note that you didn't appear to accuse the authors of 4034, 4035, and 5155 >> of "weasle wording" when those documents were standardized. Doing so now >> seems out of line. > > As a whole those documents were less specific that I would have liked. > Basically, everywhere there is a SHOULD is a possibility where some resolvers > accept the data and others reject it. > > In any case where see a should, you need companion text to describe what to > do (either on the sender, or the receiver, or both) if you don't follow that > guidance. We agree, and I gave up pleading in the IETF for "every SHOULD needs to clearly explain the exceptions" probably 15 years ago. However, in this case, I think it is better to simply promote these to a MUST. > WRT to the parent documents - as a whole they mix implementable and human in > the loop functions and there's enough of the former to place them as > Standards. But when you extract guidance paragraphs, update them, but then > don't update the client guidance on how to handle the received data, you're > not really updating the standard and hence informational vs standard. Agree. Here, I think that this document should update RFC 8198 to make it clear that the resolver MAY pick the lower of $x and $y in case the authoritative server did not set $x based on this update. >>> E.g. for each of these clauses add something similar to "The client >>>
Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec-ttl
On 2/3/2021 2:31 PM, Paul Hoffman wrote: On Jan 29, 2021, at 9:31 AM, Michael StJohns wrote: I can't support this as Standards track even though it purports to update standards as it doesn't actually specify an implementable protocol. Basically, this is dependent upon humans doing the right thing, rather than specifying behavior of the protocol. I don't understand the context of this. The draft specifies that the protocol is changing, and now authoritative servers change the way they act from $x to $y. Where is the "humans" part? You're not specifying a change in how the Auth servers work AFAICT, you're specifying a change in the data parameters for a few records which get set by humans (and maybe enforced by tools, not necessarily by the server). This is operational guidance rather than implementation guidance - the servers continue to serve the data they are provided regardless of whether its "right" with respect to this guidance. For example, one of the texts you reference (RFC4034 Section 4) is all about crafting the contents of the data protocol, rather than what the server should do to enforce things. It probably should have said instead - "The authoritative server SHOULD treat (and send) the TTL of the NSEC RR as having the same value as the SOA minimum TTL field" But then that gets into signing issues for the NSEC record and its verification and you'd need to make sure that the signing part of this is back filled to make sure that what's signed agrees with what the server is actually sending. 8198 section 5.4 actually specifies an implementable behavior in that it tells the client how to treat received and cached data. For each of these, I'd recommend specifying what a client does in each of the cases, rather than weasel wording the SHOULD with respect to the zone contents to turn this into an implementable protocol. Here, I agree that the draft is unclear. It should say explicitly "resolvers keep doing $z, there is no change here". Also, for the text about authoritative servers, I agree that changing the SHOULDs from the current standards to MUSTs. I note that you didn't appear to accuse the authors of 4034, 4035, and 5155 of "weasle wording" when those documents were standardized. Doing so now seems out of line. As a whole those documents were less specific that I would have liked. Basically, everywhere there is a SHOULD is a possibility where some resolvers accept the data and others reject it. In any case where see a should, you need companion text to describe what to do (either on the sender, or the receiver, or both) if you don't follow that guidance. WRT to the parent documents - as a whole they mix implementable and human in the loop functions and there's enough of the former to place them as Standards. But when you extract guidance paragraphs, update them, but then don't update the client guidance on how to handle the received data, you're not really updating the standard and hence informational vs standard. E.g. for each of these clauses add something similar to "The client SHOULD/MUST reduce the effective TTL for the received NSEC RR to the lesser of the TTL of the current SOA record, the TTL of the SOA, and the TTL of the NSEC RR record and MUST discard the NSEC RR when that effective TTL expires." Again, this is not about the clients, as the document says (but not clearly enough). And that's really the problem. The client should be able to look at the incoming data, do a sanity check on it and then do the appropriate things it needs for self protection. If it can't - if you don't specify it should - then eventually something will break that's rather unexpected and perhaps with a very large impact. If this is important enough to make a change at the server, its certainly important enough to require the corresponding validation change at the client. So - not ready for last call. Sure it is. These are normal last call comments. Given that there was little or not actual discussion on the document, I was quite surprised to see it go for last call. But fair - "not ready to pass last call". In a similar vein, I think that the section on "No updates to RFC8198" should indeed update RFC 8198. The resolver might have the SOA in its cache, and thus could do the right thing even if the authoritative server has not been updated. --Paul Hoffman Longer Discourse - As I model the DNS, I tend think of it as having three main parts: the data source (what used to be called the zone master file), the authoritative servers, and the clients. This is simplistic, but bear with me. In early days, the authoritative servers generally served what the data provider gave them, regardless of mistakes (and somewhere around here I have a number of very broken master files). The AS' were pass through entities to the point that there's very little text that says something like "The AS MUST
Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec-ttl
On Jan 29, 2021, at 9:31 AM, Michael StJohns wrote: > I can't support this as Standards track even though it purports to update > standards as it doesn't actually specify an implementable protocol. > Basically, this is dependent upon humans doing the right thing, rather than > specifying behavior of the protocol. I don't understand the context of this. The draft specifies that the protocol is changing, and now authoritative servers change the way they act from $x to $y. Where is the "humans" part? > For each of these, I'd recommend specifying what a client does in each of the > cases, rather than weasel wording the SHOULD with respect to the zone > contents to turn this into an implementable protocol. Here, I agree that the draft is unclear. It should say explicitly "resolvers keep doing $z, there is no change here". Also, for the text about authoritative servers, I agree that changing the SHOULDs from the current standards to MUSTs. I note that you didn't appear to accuse the authors of 4034, 4035, and 5155 of "weasle wording" when those documents were standardized. Doing so now seems out of line. > E.g. for each of these clauses add something similar to "The client > SHOULD/MUST reduce the effective TTL for the received NSEC RR to the lesser > of the TTL of the current SOA record, the TTL of the SOA, and the TTL of the > NSEC RR record and MUST discard the NSEC RR when that effective TTL expires." Again, this is not about the clients, as the document says (but not clearly enough). > So - not ready for last call. Sure it is. These are normal last call comments. In a similar vein, I think that the section on "No updates to RFC8198" should indeed update RFC 8198. The resolver might have the SOA in its cache, and thus could do the right thing even if the authoritative server has not been updated. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
