Discussion about Cancel-Lock support

Julien ÉLIE julien at trigofacile.com
Mon Dec 7 20:07:15 UTC 2020


Hi Russ,

>>> My inclination would be to support all of the non-MD5 algorithms for
>>> verification but only generate SHA-256.  I don't think there's much
>>> gained by using the other algorithms.
> 
>>> It looks like Gnus still only supports SHA-1.
> 
>> For interoperability reasons, it seems that we'll have to handle a
>> transition period, and generate two hashes for each message (SHA-1 and
>> SHA-256).  And support all of the non-MD5 algorithms to verify cancel
>> keys.
> 
> On the generate side, I think it only matters what other servers support,
> and I have no feel for what server support is out there and thus whether
> we need a transition period for that part.

When Michael wrote RFC 8315 (Cancel-Key), he did the analysis and found 
out that not all servers know other algorithms than sha1.
The previous draft (from the USEFOR WG), written two decades ago, only 
defined sha1; so implementations only used that.

    Implementations of earlier draft versions of this specification
    defined a different value for <scheme> than this version.  The
    following value for <scheme> is now deprecated and SHOULD NOT be
    generated anymore.  Serving agents SHOULD still accept it for a
    transition period as long as the corresponding hash function is not
    considered unsafe (see Section 7 for details) or already marked as
    OBSOLETE in the "Netnews Cancel-Lock Hash Algorithms" registry
    (Section 8.3).

       obs-scheme = "sha1"

    It is important for backward compatibility that the deprecated value
    for <scheme> is not phased out too early.  Security and compatibility
    concerns should be carefully weighed before choosing to remove
    <obs-scheme> from existing implementations (or not implementing it in
    new ones).

=> in the IANA registry related to Cancel-Lock, sha1 is of LIMITED USE 
(still not OBSOLETE)
=> SHA-1 is still not deprecated (unless for signature hashes in TLS 1.2 
through draft-ietf-tls-md5-sha1-deprecate-04 in the process of becoming 
a proposed standard)


> (What we generate won't matter
> for Gnus, since it won't have the secret keys for those hashes anyway.)

Yes, exactly!  A posting agent does not verify these keys.

-- 
Julien ÉLIE

« La femme est beaucoup plus portée que l'homme aux actes imprudents et
   irréfléchis. » (Démocrite)


More information about the inn-workers mailing list