Subject: Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec-ttl

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Feb 2021 19:31:10 +0000

On Jan 29, 2021, at 9:31 AM, Michael StJohns <[email-masked]> 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

---

From: Michael StJohns <[email-masked]>
Date: Wed, 3 Feb 2021 18:24:09 -0500

> 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.

> 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.

> 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.

> 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 aut…

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 verify.... and MUST NOT serve data that 
fails that verification step".    Most of the documents talk about 
setting this bit or clearing that bit in the data source, but then don't 
take the step of indicating that the AS must do a sanity check and 
refuse to serve bogus data.   E.g. if a human screws up in the provision 
of the data the AS screws up.

Separate from the protocol model, most providers of modern DNS AS 
implementations tend to treat the data origin tools as part and parcel 
of the AS, and does some verification during the record creation 
process.  But that's an implementation choice, rather than a requirement 
of the specification.   Mostly that's not a problem, be cause we mostly 
do specify the behavior of the client upon receipt of the possibly bogus 
data and all of that takes place without a human in the loop.

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.

Later, Mike

ps - Peter -sorry I missed your immediate response.  I think the above 
covers your comments as well, but feel free to bring up anything I missed.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Feb 2021 23:54:22 +0000

On Feb 3, 2021, at 3:24 PM, Michael StJohns <[email-masked]> wrote:
> 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.

> 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.

> 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.

Agree.

> 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".

Good, we are in more agreement here. I'd like to see a bunch of technical changes (including the SHOULD -> MUST for the updated documents), and have a second last call for objections.

--Paul Hoffman

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 4 Feb 2021 00:38:16 +0000

> 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. 
> 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…

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

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 4 Feb 2021 08:54:48 +0100

> 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 SHOUL…

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