Digest Headers: what about the other algorithms?

[phluid61]

ADLER32 and CRC32c are in the registry, but not mentioned in the text (although they are covered by this blanket statement)

Changes compared to RFC5843

[...]

The status for all other algorithms have been updated to "standard".

Is it ok to gloss them this way?

[ioggstream]

@phluid61 thanks for your question! I really appreciate some guidance here!

What should we put there instead of standard?

Here's the rationale for the current choice:

• I wasn't able to find the RFCs registering CRC32c and ADLER32 in the IANA table;
• RFC5843 doesn't mention them;
• eg. for Adler32, RFC3309 has no iana considerations

This draft:

• does not remove those adler32 and crc32c from https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml
• just updates their status to standard

Thanks for your time!

[phluid61]

I'm pretty sure those RFCs predate standardised registration, so it's definitely going to be a mess.

I think you could mark ADLER32 as 'obsoleted' (see: https://tools.ietf.org/html/rfc4460#section-2.38 ) I think the references in the registry are still the most relevant.

CRC32c is 'standard', as far as I can see.

[LPardue]

WDYT of adding a subsection to section 9 - "Obsolete ADLER32 Digest Algorithm" that cites Stream Control Transmission Protocol (SCTP) Checksum Change https://tools.ietf.org/html/rfc3309

[ioggstream]

Ok for me. Do you agree to leave this to -01 ?

[mnot]

Please keep -00 as close to the draft we adopted as possible.

[ioggstream]

Seems that ADLER32 is still used by various projects, like dcache.org, for a weak form of validation.

@paulmillar is mentioned in the IANA table too :) Can you share your view on the subject?

[manger]

ADLER32 and CRC32c are well-defined, standardised, algorithms. But there is no spec specifically registering them for use in the HTTP Digest header. My judgement at the time (as the designated expert for that IANA table of HTTP Digest Algs) was that it was sufficient for the algorithms to have specs, without demanding an extra spec just to added them to the table.

ADLER32 was added (despite its limitations for short messages described in RFC3309 "SCTP Checksum Change") as it was widely used in FTP, which HTTP was replacing in many situations.

As for the new "Status" column ...
The status of the algorithm is probably more useful than the status of a registration spec, though that would require a separate judgement call.

ADLER32 is deprecated in SCTP, but presumably still widely used in ZLIB. So for the HTTP Digest table ... uhmm ... "obsolete" or "standard" (or "informational"?) is probably fine.

I suggest adding ADLER32 and CRC32c to draft-ietf-httpbis-digest-headers. That tidies up the registration.

[ioggstream]

Thanks @manger.

I thought to two possibilities:

• add CRC32c and ADLER32 in the digest-algorithms (eg like they were never added);
• update the CRC32c and ADLER32 in the IANA considerations with a full definition of all the fields,
  so that this spec becomes a complete reference for the addition of those algorithms.

@reschke who can provide some guidance on that?

[paulmillar]

@ioggstream From a quick read through the document, it seems this document assumes the reason for requesting a checksum is to verify the image has not been modified by a potentially hostile agent. For this use-case, using a non-crypto hash (e.g., ALDER32) or a crypto hash that has been broken (such as MD5) is (very likely) a bad choice.

However, there are potentially other use-cases for requesting a hash. One such example is when a file has been transferred and (soon after) the user/client wishes to verify the integrity of the transfer against accidental (i.e. non-malicious) corruption. In such cases, a non-cryptographically strong algorithm may be acceptable.

The other (related) scenario is where the only known-good value for a file's hash was calculated using an algorithm that is either not intended to be crypto-strong (e.g., ADLER32), or using an algorithm that has been compromised (e.g., MD5). Under these circumstances, the client may wish to know the remote content's hash using such algorithms, as it provides at least some measure of protection.

My suggestion would be something along the lines of ...

Servers MAY support non-cryptographically secure hash algorithms. Clients
MUST ignore any hash values calculated using algorithms that do not
meet the clients requirements.

The onus is on the client to decide which algorithms are appropriate for their use-case. This isn't dictated by the document (and will likely change over time, anyway, as more hash algorithms are broken).

[ioggstream]

@paulmillar thanks for your feedback!

What do you think of this PR? #877

verify the integrity of the transfer against accidental (i.e. non-malicious) corruption.
In such cases, a non-cryptographically strong algorithm may be acceptable.

As the number of messages grow, chance or purpose may not change that much :)
I agree that we can warn about that and push people to use the best
crypto algorithm for their use case (which may be CRC32c).

... or using an algorithm that has been compromised (e.g., MD5).

We decided not to support broken crypto algorithms. If you don't need
crypto quality you can go CRC32c.

The onus is on the client to decide

While the receiver (either client or server) may even ignore Digest, we should foster interoperability around secure choices which, as you correctly said, may change in time.

[paulmillar]

Hi @ioggstream

What do you think of this PR? #877

I've commented on the PR directly, but (in summary) the PR looks OK as-is, but I wondered if it would be helpful to split the behaviour of the agent generating the insecure hash from the behaviour of the recipient. (see PR for a concrete suggestion).

We decided not to support broken crypto algorithms. If you don't need
crypto quality you can go CRC32c.

There's an additional consideration: number of bits. ADLER32 and CRC32 are both 32-bit algorithms. When dealing with large volumes of data there's an increased risk of non-malicious corruption that (by chance) a 32-bit algorithm fails to detect. There is some interest in using MD5 not for its (broken) cryptographic behaviour, but simply because a hash has 128-bits.

[ioggstream]

I've commented on the PR directly

Thanks!

There is some interest in using MD5 not for its (broken) cryptographic behaviour, but simply because a hash has 128-bits.

We deeply discussed MD5 in #867 Feel free to add your comments there - though the decision was taken we are still in draft.

[ioggstream]

@phluid61 @LPardue Addressed via

• Update CRC32C value in iana table. Related to: #828. #891 Update CRC32C in iana table
• Obsolete ADLER-32 but don't forbid it. It's now NOT RECOMMENDED #828  #877 Obsolete Adler32 but don't forbit

Can we close?

[ioggstream]

@phluid61 great!