Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

[Robert Edmonds <[e-mail]>]

Mukund Sivaraman wrote:
> Hi Robert
> 
> On Mon, Sep 28, 2015 at 01:30:28PM -0400, Robert Edmonds wrote:
> > 16 bits is an awful lot of space for the ALGORITHM field.  Compare to
> > the DNSSEC algorithm number field, which is only 8 bits.
> 
> Do you suggest changing it to 8 bits too?

If you keep an algorithm field, yes, I suggest changing it to 8 bits.
It seems unlikely more than one or two algorithms would ever be
implemented.  Is algorithm agility really needed, though, given that
there are ~65000 unused EDNS0 option codes?

I am also curious why a cryptographic hash function (SHA-1) is needed
for this.  Is a fast non-cryptographic checksum not suitable (e.g.,
CRC-32C, which can be computed in hardware on x86 CPUs)?

Also, there is a long deployment tail for new EDNS options.  If it's
urgent to deploy a countermeasure against off-path fragment spoofing,
why not something like Unbound's "referral path hardening", or
advertising a smaller EDNS buffer size which is much less likely to
result in fragmentation?  (E.g., I believe OpenDNS advertises a ~1.4
Kbyte EDNS buffer size.)  Those countermeasures can be deployed
unilaterally by the resolver, and on a shorter time scale than a new
EDNS option.

-- 
Robert Edmonds