On Thu, 14 Mar 2019 at 15:09, Tony Finch <d...@dotat.at> wrote:

> Martin Hoffmann <mar...@opennetlabs.com> wrote:
> >
> > As such, I would like to propose to move HMAC-MD5 to optional and only
> > retain SHA-1 and SHA-256 as mandatory.
>
> That seems sensible. There should at the very least be a reference to
> RFC6151, Updated Security Considerations for the MD5 Message-Digest and
> the HMAC-MD5 Algorithms.


Is there any continuing justification for the special treatment of SHA-1
enshrined
in the footnote to Table 1.

Section 8 make abundantly clear that algorithm selection and applicable
truncation
is a matter of policy and agreement between client and server.  Taken
together with
the detailed requirements in section 6.5.2.1, and the statement that a
reply SHOULD
be sent with a MAC at least as long as that in the corresponding request,
removes
the need for specific numerical length constraints to be stated in this
document.

IMHO the SHOULD here should become MUST, promoting this to a full
requirement.

The special cases identified in 6.5.1 and 6.5.2 are obviously not subject
to the
general policy.

Security conscious users will define their policy having regard to
performance and
size versus strength trade-offs and weaknesses of particular algorithms
about which
there is no shortage of published material.

                 Requirement Name
                   ----------- ------------------------
                   Mandatory   HMAC-MD5.SIG-ALG.REG.INT
                   Optional    gss-tsig
                   Mandatory   hmac-sha1
                   Optional    hmac-sha224
                   Mandatory   hmac-sha256
                   Optional    hmac-sha384
                   Optional    hmac-sha512

                                  Table 1

   SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.



--Dick
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to