Subject: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-02

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Mar 2010 14:43:07 -0500

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document relaxes the requirement for registration of a crypto
algorithm for DNSSEC, allowing algorithms documented in informational
RFCs (including individual and independent submissions) to be
registered.  Until now, an algorithm had to be on standards track for
registration.

I have mixed feelings about this.  Since I haven't participated in any
conversations about this until now, please forgive me if I'm repeating
things that have (undoubtedly) been discussed already, and take this
with the appropriate condiments.

I understand the reasoning for allowing non-standards-track
algorithms, but I don't understand the reason not to use "Expert
Review", specifying that the documentation required is an RFC, and
giving at least *some* criteria for the expert to consider.
Otherwise, I wonder whether registration of poorly designed algorithms
will happen, and those algorithms may present an attractive nuisance,
getting widely implemented by virtue of being registered, despite what
this document says about that.  Given that this registry is part of
the basis for the security of DNS, I'd rather see at least some
oversight (noting that "oversee" and "overlook" mean very different
things).

Even with expert review, we could allow weak or otherwise poor
algorithms to be registered, if we want to do that, with the addition
of a field in the registry that indicates the expert's assessment:
perhaps it could say "not recommended" as a sufficient warning.  That
would also allow updates later, giving erstwhile-good algorithms a
status of "compromised", "deprecated", or the like (and would be a
better place to note the deprecation of RSA/MD5 than in the algorithm
description, where it is now).

Going to the bullet at the bottom of page 2, what I'd like to ensure
is that an algorithm that "might not have been evaluated thoroughly
enough to be able to be put on the Standards Track" has nonetheless
been evaluated thoroughly enough to be in an "official list" of likely
candidates for implementation.  An "assessment" column would provide
that.

I'd like to see the text of the last paragraph of section 3 change:
OLD
It should be noted that the order of algorithms in the IANA registry
does not signify or imply cryptographic strength or preference.
NEW
It should be noted that the presence of or order of algorithms in the
IANA registry does not signify or imply cryptographic strength or
preference.

I think this should have an informative reference to RFC 5226 section
4.1, which defines the IANA registration policies (and gives the
specific meaning of "RFC Required").

Barry
-- 
Barry Leiba  ([email-masked])
http://internetmessagingtechnology.org/

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Mar 2010 15:31:03 -0500

Hi,

Thanks for the review of this document.

On Tue, Mar 02, 2010 at 02:43:07PM -0500, Barry Leiba wrote:

> this document says about that.

I have a certain amount of sympathy for this comment, but the plain
fact is that the DNS community does not actually have the expertise to
evaluate cryptographic algorithms anyway. 

The upshot therefore of your suggestion is that the expert review
required in this area would probably require an expert panel in each
case, with one member from the DNS community and another from the
security community.  

More importantly, I'm not sure there's actually a problem to solve
here.  Do we have a problem in other protocols where poor crypto
algorithms have won out over better-designed algorithms?

> description, where it is now).

We do in fact have a completely separate effort underway to update the
registry in order to allow certain kinds of indicators like this.  The
WG seemed to agree that these were separate problems and didn't want
to conflate them.  Does that other effort address your concern?

> IANA registry does not signify or imply cryptographic strength or

I see no objection to that alteration.

> specific meaning of "RFC Required").

I have no objection to this reference.

Thanks again for the review,

Andrew (doc shepherd)

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Mar 2010 15:42:24 -0500

> case, with one member from the DNS community and another from the

I understand.

> algorithms have won out over better-designed algorithms?

Actually, we do -- not with "won out", so much as "got implemented",
which then leaves a hole in the algorithm negotiation process.  HTTP
clients and servers, for instance, often support long-broken versions
of SSL, weak encryption algorithms, and too-short key lengths.  The
result is that both clients and servers can be steered, in the
negotiation process, toward use of weak crypto, which can then
undermine the security of the transactions.

> to conflate them.  Does that other effort address your concern?

Partially.  It depends upon how that work resolves the question of who
gets to decide what values those indicators take.  If I can register
the BBC algorithm (Barry's Broken Crypto), and give it soi-disant
"highly recommended" status, then nothing's solved.  If someone *else*
is responsible for controlling that field, then we're back to asking
who the expert (or panel of) is.

Anyway, repeating: my lone opinion on this doesn't override a bunch of
people who spent a lot of time going over this and came to consensus.
I'm just a bit concerned, is all.

Barry

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Mar 2010 18:12:04 -0500

> undermine the security of the transactions.

Hrm.  Well, in DNSSEC, there _is_ no algorithm negotiation process.
The client validates using the signatures that are published, or it
doesn't validate at all.  And remember that in the case of DNSSEC, we
have no reason (so far) to suppose that we'll get to the state where
validation is required.  Under the protocol, if you don't understand
the algorithm on the signature available to you (which could actually
be a subset of the signatures in the zone, due to the effects of
caches), you just treat the response as not secured.  So it's just
like the zone isn't signed. 

There's the additional factor that adding algorithms increases
response size, which increases transit cost for the zone operator.

Because there's no way to negotiate the algorithm and there's an
incentive to keep the number of algorithms in use small, we've had the
idea that validators are likely to converge on one or two good ones,
and tend to stay there.
 
> who the expert (or panel of) is.

The text of this draft currently explicitly notes that it doesn't
change the rules for making an algorithm mandatory to implement.
Since making an algorithm mandatory to implement would update 4034, I
therefore think that it would still require standards action, which
punts the whole business right back to the same process in place
today.  Does that make you less uneasy?

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Mar 2010 18:21:28 -0500

> idea that validators are likely to converge on one or two good ones,
...
> today.  Does that make you less uneasy?

Yes, this whole discussion makes me much happier -- as I said, I
hadn't been involved with this before, so I was coming out of left
field anyway.

Thanks for the discussion, Andrew.  I hope this has been helpful for
the ADs, as well.

Barry

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 2 Mar 2010 18:46:03 -0500 (EST)

> today.  Does that make you less uneasy?

It still leaves me uneasy.  As a casual reader of this doc (and casual 
author of an algorithm definition doc), I'd be inclinded to assume 
that an algorithm definition doc, even if not standards track, could 
at least specify the requirement status for the algorithm it's 
defining.

As I pointed out when reviewing 
draft-ietf-dnsext-dnssec-registry-fixes, I'm worried about the 
possibility of an independent submission (=RFC Editor stream document) 
creating a new "MANDATORY" algorithm or of changing the requirement 
status of other new algorithms, even if those were defined on the 
standards track.  I proposed some text for the registry-fixes doc to 
resolve that, and I suggest repeating it here:

"Unless specified in a Standards Track RFC, new algorithms will have a 
requirements status of OPTIONAL.  Only a Standards Track RFC may set 
or change a requirements status of ENCOURAGED or MANDATORY."

There may be some additional issues around the particular keywords in 
that text, but that's the general idea.

At the very least, rather than say "This document does not change the 
requirements for when an algorithm because (sic) mandatory to 
implement. Such requirements should come in a separate, focused 
document.", actually tell people what the mechanism/threshhold for 
setting a requirement level is.  I don't think it's currently obvious.

-- Sam

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Mar 2010 19:05:09 -0500

On Tue, Mar 02, 2010 at 06:46:03PM -0500, Samuel Weiler wrote:
> were defined on the standards track.  I proposed some text for the 
> registry-fixes doc to resolve that, and I suggest repeating it here:
>
> requirements status of OPTIONAL.  Only a Standards Track RFC may set or 
> change a requirements status of ENCOURAGED or MANDATORY."

The -02 version of registry-fixes says

   The requirement status for all new algorithms will be DISCRETIONARY
   unless a Standards Track document changes that (possibly including
   the Standards Track document defining the algorithm).  Only a
   Standards Track document may make an algorithm ENCOURAGED or
   MANDATORY or remove the MANDATORY or ENCOURAGED designation (to
   DISCOURAGED or OBSOLETE for example).

There is no reference from the current (alg-allocation) document to
the registry-fixes doc because we were trying, very hard, to keep each
document specific and focussed.

Does that help?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 2 Mar 2010 20:00:09 -0500 (EST)

> document specific and focussed.

No.  alg-allocation, read by itself, is still confusing.  Rather than 
cite the new metric for changing requirement status (as being 
defined/changed in registry-fixes), alg-allocation could instead cite 
the current metric.  Earlier in this thread you said that was to 
update 4034 (=standards action).

No matter what the metric is, I want alg-allocation to be explicit 
about the metric.

-- Sam

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Mar 2010 21:53:14 -0500

On Tue, Mar 02, 2010 at 08:00:09PM -0500, Samuel Weiler wrote:
> the current metric.  Earlier in this thread you said that was to update 
> 4034 (=standards action).
>
> No matter what the metric is, I want alg-allocation to be explicit about 
> the metric.

It appears, however, that the approach you're suggesting could
actually make things more confusing in the near term. 

DNSEXT is currently trying to do two, strictly separate things:

    1.  Alter the mechanism to get an algorithm assignment in the IANA
    registry.  That's what the document we're discussing does.

    2.  Clean up the registry to make it easier to find, in one place,
    data like what is mandatory to implement or not.  That's what
    registry-fixes does.

What you are suggesting is that the present document be made to say
not only that it does not alter how you get a "mandatory" flag, but
what the current procedure is.  The problem with that is that we're
actually trying to _change_ what the procedure is, because at the
moment it's "update 4034" or maybe "update 3755" or maybe "update
2536".  In any case, it's certainly standards action; but what that
action is, we'd have to work out when we did it.  It is in fact this
very confusion that regstry-fixes is supposed to help: on its
publication, what you'd have to do is update the registry with the
required flad, and registry-fixes makes clear that such an update
requires standards action.

If we change the current document to say precisely how you get a
mandatory flag today, however, we're out of luck: there's actually no
mandatory flag in the registry as it stands, so there's nowhere to
track this.  This therefore would require a lengthy explanation in the
current document about how there is in fact no such thing as a
mandatory flag in the registry, and that therefore you can't have a
restriction on setting the mandatory flag, but that anyway you can't
have a mandatory-to-implement algorithm without a standards action.

All of that to be obsoleted immediately on publication of whatever
ends up coming out of registry-fixes (since even if one doesn't like
the current words in that document, _something_ needs to be done about
the registry in question).

I'm therefore not actually sure how to make the text clearer for the
immediate circumstance without also making it more confusing in the
hopefully-near future.  If you have suggested text to do this,
however, I'd be interested in seeing it.

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Mar 2010 09:05:24 -0800

At 6:46 PM -0500 3/2/10, Samuel Weiler wrote:
>It still leaves me uneasy.  As a casual reader of this doc (and casual author of an algorithm definition doc), I'd be inclinded to assume that an algorithm definition doc, even if not standards track, could at least specify the requirement status for the algorithm it's defining.

That line of logic would mean that any Informational RFC on any topic can "specify the requirement status". The IETF has never worked that way, and never will.

>As I pointed out when reviewing draft-ietf-dnsext-dnssec-registry-fixes, I'm worried about the possibility of an independent submission (=RFC Editor stream document) creating a new "MANDATORY" algorithm or of changing the requirement status of other new algorithms, even if those were defined on the standards track.  I proposed some text for the registry-fixes doc to resolve that, and I suggest repeating it here:
>
>"Unless specified in a Standards Track RFC, new algorithms will have a requirements status of OPTIONAL.  Only a Standards Track RFC may set or change a requirements status of ENCOURAGED or MANDATORY."

Mixing the contents of these two documents is a terrible idea. It puts the rules for the registry in two documents instead of one.

>At the very least, rather than say "This document does not change the requirements for when an algorithm because (sic) mandatory to implement. Such requirements should come in a separate, focused document.", actually tell people what the mechanism/threshhold for setting a requirement level is.  I don't think it's currently obvious.

It is not because that mechanism is in a different document, as it should be.