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

[Mukund Sivaraman <[e-mail]>]

Hi Robert

On Mon, Sep 28, 2015 at 02:20:04PM -0400, Robert Edmonds wrote:
> 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.

OK. I'll make this change. :)

> 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?

If I follow correctly, what you're suggesting is that if an algorithm
becomes weak, we jump to a new EDNS option which has a different EDNS
option code assigned. This seems like a bad idea to me, because as such
option codes get assigned, they will be spread out and the code in DNS
implementations which handle it will look dirty. It's better to keep it
all under one option code, even if it occupies 1 more byte.

> 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)?

SHA-1 was chosen without too much consideration for anything. Appendix A
was empty initially and SHA-1 was added as a placeholder to fill that
section. The list of algorithms is best decided by discussion here, and
SHA-1 can be removed if it is unsuitable.

On the topic, I'll add a penny: checksum algorithms (as we want them
here) have two extremes, one of which is to protect against accidental
modifications of data, and another which is to protect against
malicious/intentional modification of data. There are also others such
as hashing functions (uniform distribution in the mapped output range,
or something more specific). All these have different performance
characteristics.

CRCs serve towards the "accidental modifications" category, and SHA-1
towards the "intentional modification" one. We want something suitable
in the latter category, a cryptographic hash function, though the level
of security it provides need not be as high as that expected for a
long-lived signature.

		Mukund