[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-02.txt
On Dec 27, 2005, at 1:18 AM, Wes Hardaker wrote:
On Mon, 26 Dec 2005 23:36:41 -0500, David Blacka
<davidb@verisignlabs.com> said:
David> The use of MUST means that, if an implementation doesn't do the
David> thing, something Will Not Work. All of this language is about
David> preferring SHA-256 to SHA-1. This is a Good Idea, but none
of this
David> is necessary for interoperability. Thus, SHOULD or
RECOMMENDED is
David> the appropriate level for the entire paragraph.
There is a really large number of RFCs that have MUSTs for security
related things. That's because without them, security Will Not Work
(which then affects interoperability).
True.
IMHO, it should stay as a MUST. But... I of course will follow the
consensus of the group.
Ok, let me step back a little. Part of what I'm arguing is that the
paragraph, as currently constructed just isn't using MUST in an
appropriate way. Statements like "client MUST have feature X, SHOULD
use feature X, but MAY choose not to" directly translate to "SHOULD
use feature X". The sentence "...implementations MUST be able to
ignore DS RRs..." is not meaningful in a protocol document. Or, in
other words, pure software requirements have no place in a protocol
document.
The document can say one of two things:
a) validators MUST ignore SHA-1 DSs when SHA-256 DS are present, or
b) validators SHOULD ignore SHA1-1 DSs ...
Currently, your paragraph is actually saying b.
My previous arguments were that b is the correct choice.
Though in this case I think we're not that close to the point where an
attack is actually executable against SHA-1...
Which is at least partly why b is the correct choice.
So, to conclude, I suggest that your paragraph just boil down to:
<t>Validator implementations SHOULD ignore DS RRs containing SHA-1
digests if DS RRs with SHA-256 digests are present in the DS RRset.</t>
--
David Blacka <davidb@verisignlabs.com>
Sr. Engineer Verisign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>