Hi Joe Thank you for this review. See comments below:
On Mon, Sep 28, 2015 at 07:53:10PM -0400, Joe Abley wrote: > > > On 28 Sep 2015, at 11:51, Mukund Sivaraman wrote: > > > o draft-muks-dnsop-dns-message-checksums-00 > > Initial draft (renamed version). Removed the NONCE-COPY field as > > it is no longer necessary. Doubled the size of the NONCE field to > > 128 bits. Added sample checksum algorithms. Fixed incorrect > > reference, language and grammar. > > +-------+-------+-----------------+ > | Value | Type | Status, Remarks | > +-------+-------+-----------------+ > | 0 | EMPTY | Empty digest | > | 1 | SHA-1 | Mandatory | > +-------+-------+-----------------+ > > Reserving other values for private use might be useful. The draft has been updated in the git repository towards this. It'll show up in the next version. > The document doesn't describe the expected behaviour when a DNS server > receives a DNS message with a CHECKSUM option that specifies an > algorithm that is unknown by the receiver. Similarly, the draft has been updated in the git repository towards this. It'll show up in the next version. > The IANA Considerations section seems inadequate -- it might be worth > reviewing RFC 5226 and fleshing out the text that instantiates this > registry (or anticipating the smooth passage of > draft-leiba-cotton-iana-5226bis-11 and reading that instead for the > same reason). Similarly, the draft has been updated in the git repository towards this. It'll show up in the next version. Thank you for citing these references that helped in updating this section. You can see a copy here: http://users.isc.org/~muks/draft-muks-dnsop-dns-message-checksums.txt > The Security Considerations section should say more about the > limitations of this approach, e.g. the ability of an off-path attacker > to correct for changes that would change a checksum with other changes > that will restore it, which is my lazy précis of the no-doubt more > succinct observation that Vixie made somewhere in this thread (or > another thread near it). I didn't understand this part. Candidate checksum algorithms will have to be one-way cryptographic hash functions, and they will automatically take care of this. The case that a cryptographic hash function may be weakened in the future is obvious and understood. Perhaps you mean that the security considerations section ought to state explicitly that this case of reversing the hash function doesn't occur when using the algorithms in appendix A? > The primary point of this draft is to offer some degree of integrity > protection for unsigned responses (since signed responses already have > it); it might be useful to spell that out. If I receive a query with > the CHECKSUM option which I support, but I know I'm going to return > signed data (and DO=1 in the query) I might decide to pretend I don't > implement CHECKSUM because it's not especially useful if I have RRSIGs > to tell you about. Does the receiver of my response get to assume that > I don't support CHECKSUM at all, and never ask for it again? > > If I send a query with the CHECKSUM option to a server (or through a > middlebox) that doesn't handle unknown EDNS(0) option types correctly, > and I hear no response, what should I do? If I receive something else > unexpected (like a FORMERR), what should I do? Not accommodating the > errors of others might well be the right thing, here, but we know that > end users don't care about technical correctness when "you are broken > but my neighbour's ISP is fine" and hence there will be pressure to > mitigate the failures of others in some way or other. Having different > implementations fall back differently seems less than desirable. Mark has sufficiently addressed this point in his reply. There is a separate thread that mentions why use of DNSSEC doesn't imply that CHECKSUM ought to be omitted. Mukund
pgpr0AgFGPPpv.pgp
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
