Re: [DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

Hi Wes,

On 05/08/16 22:18, Wes Hardaker wrote:
> "Stephen Farrell" <[e-mail]> writes:
> 
>> Why omit sha256 (in particular Alg = 8) from this?  That
>> seems like a quite bad plan and *not* a BCP given our
>> current knowledge of hash functions.
> 
> I've changed the text to test for both.  I think that's a good suggestion.

Great thanks. Happy to clear when you post an update with
that handled.

The points below were non-blocking comments, so no need for
us to bat 'em back and forth. (Your responses are reasonable,
even if I might quibble a bit with 'em, but overall it's probably
better to get your doc out.)

Cheers,
S.

> 
>> general, mostly 3.x.y: it'd have been nice to include a
>> dig command line for each of these tests - that'd save the
>> non-expert reader some time and allow easy scripting of
>> most of this BCP.
> 
> I thought about that, but it would require significant explanation and
> not all of the tests (I think) have behavior which is observable by
> dig.  Plus, dig is but one of many software tools and would seem to bias
> the document toward ISC's version.
> 
>> general: Why not say to include a test with a known, but
>> not well-known, public key (or DS) to check if anyone on
>> the path is fibbing? E.g. a tester could remember a few
>> public keys and check that they've not changed in a new
>> location.  While that may only catch out a cheating real
>> parent, did you consider including such a test?
> 
> No, because that game is cat and mouse just like most other security
> detection problems.  There is no way to define a conclusive test that
> can't be fooled by someone on the wire [for once the attacker learns
> once, he'll know the second time to behave differently].
> 
>> - 3.1.4: How is a "recently defined type" a reasonable
>> thing to check for in a BCP? Seems odd anyway.
> 
> I'd think software implementations, as they rolled out, would update
> their test to use the latest assigned type code.  I had an equally hard
> time with that question, but it does provide valuable input though it's
> not easy to adequately describe.
> 
>> - 6.1: what if there is no user? Why not recommend telling
>> some network observatory? Aren't there some for DNSSEC?
> 
> There aren't any.  We do mention logging the results in section 6 though.
>