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

[Michael StJohns <[e-mail]>]

On 2/3/2021 2:31 PM, Paul Hoffman wrote:
> On Jan 29, 2021, at 9:31 AM, Michael StJohns <[e-mail]> 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 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.