The incremental effort to implement SHA-224 if you are implementing SHA-256
is miniscule. It makes no sense to me for SHA-224 to be NOT RECOMMENDED to
use when SHA-256 is MUST implement and RECOMMENDED to use and you can use
SHA-256 with truncation to 224 or even fewer bits.
Thanks,
Donald
===
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com
On Sat, May 9, 2020 at 9:52 PM Tim Wicinski wrote:
> To follow up on Stephen's comments, a table was added to 2845bis to
> list all the algorithms that are currently in the IANA registry,
> along with suggestions for implementation. This was the first version:
>
>Requirement Name
>---
>OptionalHMAC-MD5.SIG-ALG.REG.INT
>Optionalgss-tsig
>Mandatory hmac-sha1
>Optionalhmac-sha224
>Mandatory hmac-sha256
>Optionalhmac-sha384
>Optionalhmac-sha512
>
> During the IESG review (I think it was the SECDIR review), there was
> a meltdown over implementing SHA-1. But SHA-1 is in use currently.
> My suggestion was to do a variation describing implementation use.
> This is what I came up with(so blame me):
>
> Name Implementation Use
> -- ---
> HMAC-MD5.SIG-ALG.REG.INT MAYMUST NOT
> gss-tsig MAYMAY
> hmac-sha1MUST NOT RECOMMENDED
> hmac-sha224 MAYNOT RECOMMENDED
> hmac-sha256 MUST RECOMMENDED
> hmac-sha256-128 MAYMAY
> hmac-sha384 MAYMAY
> hmac-sha384-192 MAYMAY
> hmac-sha512 MAYMAY
> hmac-sha512-256 MAYMAY
>
> On the use side, these are mostly guesses. We would love to hear
> what the WG has to say about this.
>
> thanks
> tim
>
>
> On Mon, May 4, 2020 at 2:07 PM Stephen Morris
> wrote:
>
>>
>> > On 4 May 2020, at 19:00, internet-dra...@ietf.org wrote:
>> >
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> > This draft is a work item of the Domain Name System Operations WG of
>> the IETF.
>> >
>> >Title : Secret Key Transaction Authentication for DNS
>> (TSIG)
>> >Authors : Francis Dupont
>> > Stephen Morris
>> > Paul Vixie
>> > Donald E. Eastlake 3rd
>> > Olafur Gudmundsson
>> > Brian Wellington
>> > Filename: draft-ietf-dnsop-rfc2845bis-08.txt
>> > Pages : 29
>> > Date: 2020-05-04
>>
>>
>> The update addresses to the draft comments made during the IESG review.
>> There were a fair number of these which led to a number of changes to the
>> document. These are listed below.
>>
>> One significant change is that the list of acceptable algorithms has been
>> extended, and WG approval for this is sought.
>>
>> Stephen
>>
>>
>>
>>
>> Comments from Roman Danyliw
>> ---
>> > ** Section 1.3. Per “In 2017, two nameservers strictly following that
>> document (and the related [RFC4635]) were discovered to have security
>> problems related to this feature”, consider providing a reference to the
>> published vulnerabilities (i.e., CVE-2017-3142 and CVE-2017-3143)
>>
>> I’ve added these (and one other related CVE) as informative references.
>> Using just the CVE number as a reference seemed a bit spartan, so I’ve
>> added a title to each incident. As the description of the CVEs in Mitre’s
>> database don’t contain a title (only a description, which can be rather
>> long), I’ve taken the title from ISC’s KnowledgeBase (for the BIND CVEs)
>> and from the Knot release notes (for the Knot CVE).
>>
>>
>> > ** Section 6. Per “SHA-1 collisions have been demonstrated so the MD5
>> security considerations apply to SHA-1 in a similar manner. Although
>> support for hmac-sha1 in TSIG is still mandatory for compatibility reasons,
>> existing uses should be replaced with hmac-sha256 or other SHA-2 digest
>> algorithms [FIPS180-4], [RFC3874], [RFC6234].
>> >
>> > -- It’s worth repeating those MD5 security considerations here
>>
>> I’m not really keen on doing this, since the security considerations in
>> RFC 6151 cover two paragraphs and including them - or even a summary of
>> them - would detract from the flow of the document. However, I have
>> explicitly included a reference to RFC 6151 in the text.
>>
>>
>> > -- (from Magnus Nystrom’s SECDIR review, thanks Magnus!) it’s worth
>> including references to the recent
