[DNSOP] Genart last call review of draft-ietf-dnsop-serve-stale-07

[Brian Carpenter via Datatracker]

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-dnsop-serve-stale-07

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-dnsop-serve-stale-07.txt
Reviewer: Brian Carpenter
Review Date: 2019-09-17
IETF LC End Date: 2019-09-25
IESG Telechat date:  

Summary: Ready with issue


Major issues:
-

"(It [RFC2181] also has the curious suggestion that a value in the
range 2147483648 to 4294967295 should be treated as zero.)"

I don't see why that is "curious". That is the range of unsigned
32-bit integers that would be negative if treated as signed 32-bit
integers. And in any case, the statement seems unfair to the authors
of RFC2181, which actually says this:

"It is
hereby specified that a TTL value is an unsigned number, with a
minimum value of 0, and a maximum value of 2147483647... this value
shall be encoded in the less significant 31 bits..."

It's not a "suggestion"; since the RFC does not use RFC2119 keywords,
it's a requirement. It's unambiguous, and obviously motivated by
resilience to coding errors around signed vs unsigned integers. That
was a legitimate concern in 1997. As best as I can tell, in 1997
standard C did not include uint32; you needed to use unsigned long int
and hope it was mapped to 32 bits.

So the current draft overrides this choice made in RFC2181. Since that
choice had an obvious (but unstated) motivation, how do we know that
allowing TTLs above 2147483647 will not trigger long-standing coding
bugs?

There's an alarm bell later in the draft:

"Regarding the TTL to set on stale records in the response,
historically TTLs of zero seconds have been problematic for some
implementations, and negative values can't effectively be
communicated to existing software."

You bet. If the TTL is specified as an unsigned 32 bit integer, and
stored in a uint32, negative values are impossible. But if the coding
is sloppy and used long int, "if ttl > 0" could go horribly wrong.

Maybe it's all OK and there is no old resolver code out there with coding
errors for values above 2147483647. Did the WG discuss this? I think the
"curious suggestion" text above should be replaced by a brief discussion
of why RFC2181 made the change that it did, and why it's now safe to
reverse it.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-extended-error-09.txt

[Vladimír Čunát]

The following comments are only loosely related to multiple threads
here, so let me post them in a single bunch.

On 9/11/19 8:05 AM, Viktor Dukhovni wrote:
> Section 3.2 (code 2), may warrant more guidance on when this is
> appropriate.  AFAIK, there is nothing wrong with all DNSKEY algorithms
> being unsupported, provided the same holds for the DS RRset.  So,
> while I see a use-case for code 3 (all DS unsupported, perhaps to
> signal why the AD bit is not set, despite the non-empty DS RRset),
> I don't understand when one would use code 2.

I do fail to understand the split codes 1 and 2 for all DS/DNSKEY
algorithms being unsupported, and it actually makes me wonder how to
exactly write the resolver code that would set this pair.  For
validation I need at least one usable DS RR, i.e. one where *both* the
DS and DNSKEY algorithms are supported.  I believe that's the exact
condition to be able to extend the trust chain. (and that's how I
implemented it for Knot Resolver)  It may theoretically even happen that
there is a supported DS algorithm and a supported DNSKEY algorithm but
never paired together in the DS RRset - IIRC it's not perfectly correct
to generate such an RRset but that's probably not something a validator
should care for.


On 9/11/19 8:05 AM, Viktor Dukhovni wrote:
> Section 3.8 [...]
>
>So just *an* expired signature is not really a problem provided
>another signature for the same RRset is not expired.  So I think
>the text could more clearly read "but *all* signatures for an
>RRset in the validation chain expired", or some such.

Nitpick: *if* we were diving into such details... each RRSIG might fail
for a different reason, for example.  That's the general problem with
providing reasons for validation failures: validation is defined in the
sense that you (may) succeed when at least one of various ways
succeeds.  A failure could typically be fixed by multiple different ways
(EDE codes).  Still, I'd hope that in most real-life cases the
implementations can "correctly" guess what's wrong.


On 9/13/19 10:01 PM, Tony Finch wrote:
> 3.5.  Extended DNS Error Code 4 - Forged Answer
> 3.16.  Extended DNS Error Code 15 - Blocked
> 3.17.  Extended DNS Error Code 16 - Censored
> 3.19.  Extended DNS Error Code 18 - Filtered
>
> I don't understand the shades of meaning that these are supposed to
> distinguish.
>
> wrt "filtered", the description implies vaguely RPZ flavoured filtering,
> but it mentions a REFUSED RCODE which isn't what a sensible implementation
> would use for that purpose, so I am more confused.

With the switch to codes not specific to RCODE, I think some more
code-merging would be nice, in particular 3+19: stale (NXDOMAIN)
answer.  Perhaps also drop "4 forged" in favor of the other options?
(blocked, censored, if I understand the definitions)  Or is "forged"
meant for cases like the special top-level invalid. zone?


I think the current -09 "Security considerations" section is a bit
misleading.  It talks about the extended error being unauthenticated in
case of validation failure, but the current SERVFAIL is the very same
and that part is the more important bit (noticed by Paul Hoffman, too). 
With extended errors we only get more information of the same
authenticity.  In general, clients that don't want to validate
themselves can also choose a middle ground where they trust the resolver
and secure their link to it (typically by DoT or DoH).

Also, *if* the EDE codes will only be used for [diagnostics], I don't
really understand why have any "Security considerations" at all. 
Perhaps I'm just confused about the overall intention.
[diagnostics]
https://mailarchive.ietf.org/arch/msg/dnsop/rbkGvMH-vG-P5GHUx06-LRWYRgM


--Vladimir


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

[Vladimír Čunát]

On 9/12/19 8:10 PM, Viktor Dukhovni wrote:
> SERVFAIL means,  and will continue to mean, I can't help you, better luck next
> time (or elsewhere).
>
> The new EDEs are *diagnostic* detail to aid in troubleshoots, but do not
> override RCODEs.  They are not a more fine-grained RCODE one might "act on".
> If we want more fine-grained *actionable* codes, there's plenty of room for
> more values in the 12-bit EDNS RCODE.
>
> [ I chatted off-list with Wes, the above appears to match his take, with a bit
>   luck also rough WG consensus... ]

My understanding was that it was meant for resolvers to change e.g.
their retrying behavior based on the EDEs in some cases, even after
removing that "Retry flag".  I did consider that a significant part of
the (original) motivation, even we did not implement that in the first
prototype (as only server-side was done).

I certainly agree this issue should better be explicitly stated in the
final text.  At least assuming the WG consensus will be that they don't
want resolvers acting on the EDE codes in any way except for diagnostics
(possibly with RFC2119 qualifier).

--Vladimir

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Stephane Bortzmeyer]

On Mon, Feb 19, 2018 at 10:00:39AM -0500,
 Suzanne Woolf  wrote 
 a message of 17 lines which said:

> We’ve let the discussion continue because it’s been so active, but
> we also haven’t forgotten we need to review and determine next steps
> on this draft.

I don't find anything about the decision for the draft
draft-ietf-dnsop-let-localhost-be-localhost (it's now expired for more
than a year), after the working group last call. Can we safely
conclude it's dead?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop