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 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.
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).
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).
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.
Joe
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
