Hi Wes, On 05/08/16 22:18, Wes Hardaker wrote: > "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.
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. >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
