Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5802 (2652)

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 06 Feb 2011 21:07:52 -0500

On Thu, 2011-01-20 at 23:48 -0500, Greg Hudson wrote:
> On Thu, 2011-01-20 at 15:50 -0500, Simon Josefsson wrote:
> > > If you can only interoperate by using salts above a certain length, then
> > > it seems like that should be part of the syntactic or semantic
> > > constraints of the actual standard section describing salts.
> > 
> > I don't think that conclusion follows -- there are many things permitted
> > by syntax rules that are forbidden by semantic rules.  Pushing all
> > semantic rules down into syntax rules is not always a good thing.  I
> > wouldn't oppose doing so if others feel it is a better way.
> 
> I said "syntactic or semantic constraints"; I wasn't advocating one or
> the other.  I was just arguing that interoperability constraints should
> be documented in the appropriate section of the main RFC, not in
> security considerations text.

The security considerations text _is_ part of the main RFC.  This
becomes clear if we stop thinking of security as an add-on.
Particularly in this case, where we are talking about a security
protocol.

RFC2119 requirements language is not limited to cases in which
interoperability is the purpose of the requirement.  In the present
case, Simon proposes a requirement for security reasons, and it is
certainly appropriate to use RFC2119 language in such a case.

In any case, I think this is starting to get a bit silly.  One thing we
should _not_ do is encourage implementations to impose arbitrary limits
on things in the name of "security", when in fact doing so reduces both
security and interoperability.

Suppose a client implementation, following Simon's proposed advice,
imposes a minimum salt length.  For the sake of argument and without
loss of generality, let's call the selected length 16.  Then that client
will fail to interoperate with a server which uses a randomly-generated
salt of length 15.  In practice, what that means is that a user using a
service provided by such a server will sometimes be able to log in and
sometimes not, depending on which client he uses, and neither the user
nor the server operator has a prayer of figuring out why.

Of course, this problem does not arise when using a server which always
generates salts of at least 16.  However, in that case security has been
reduced, because there are strictly fewer possible salts.  Of course,
this difference may be insignificant if the maximum salt length used is
high, but a deployment which uses salts of length 0-16 has considerably
more salts available than one which uses salts only of length 16!

Also, I would remind everyone that we are talking about an erratum, and
so making a change to the protocol is inappropriate.  The purpose of an
erratum is to correct an error in the _document_, not to redesign the
protocol.

-- Jeff