"Stephen Farrell" <stephen.farr...@cs.tcd.ie> 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. > 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. -- Wes Hardaker Parsons _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
