Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums

[Benjamin Kaduk <[e-mail]>]

On Mon, Sep 25, 2017 at 01:03:11PM -0400, Simo Sorce wrote:
> On Sat, 2017-09-23 at 14:05 -0500, Benjamin Kaduk wrote:
> > On Wed, Sep 20, 2017 at 11:09:29AM -0400, Simo Sorce wrote:
> > 
> > There's two aspects that push me this way: first, from a standards process
> > point of view, now we have to also Update a core protocol spec and hope
> > that people remember to check our new document whenver they try to make
> > a new enctype/checksum type.  While it's unlikely that a hyptoehtical
> > future document would actually get through the full process with such an
> > error, it does add to the burden on future work in this space.  The second
> > concern relates to implementations, in that there will need to be some sort
> > of logic to handle the interaction of single-DES and SPAKE preauth.  If
> > we were in a place where implementations were actively removing the code
> > for single-DES support, I would not see this as an issue, but my understanding
> > is that we're still several years (at least!) away from completely removing
> > the code (as opposed to just not using it by default).  Even though we
> > know that no one ought to be using the two things together, our code still
> > has to come up with something to do in that case, and if we get the logic
> > wrong things could break badly.
> 
> Why not simply state in the spake document that single-DES MUST NOT be
> supported ?

The potential reason to not do that that I have in mind is roughly that
"it makes things easy for us now but could make things harder for
us/others further down the line".  But perhaps it is not actually that
hard, given that DES will be used less and less.

> > 
> > Hmm, so no we have a split on 2 vs. 3, unless we can somehow make 1
> > more
> > appetizing.  Do we have the collective will to make single-DES
> > actually
> > go away entirely and force any continued users to either run custom
> > solutions
> > or stay on old software?
> 
> I say that if you are on old software you have bigger problems to deal
> with than not being able to use SPAKE, and having SPAKE actively
> disallow a knowingly broken enctype is not a bad thing at all. It gives
> you one more lever to get off of DES.

Another lever to get of DES is, on the face of it, good.  On the other
hand, we just removed the text preventing SPAKE from using a knowingly
broken hash algorithm (MD5), which is not quite the same situation
but bears some similarities.  And over in the TLS WG trying to use
TLS 1.3 as a lever to force adoption of RSA-PSS signatures is not
going terribly well, so I don't know how much weight to give to the
argument of having another lever to get rid of ${bad-thing}.

That said, Greg noted on IRC that if we do have a "no DES and SPAKE
together" requirement, the KDC knows the initial reply key and can
do the right thing fairly easiliy, including rejecting optimistic
attempts from (broken) clients.  So, I'm starting to come around to
the camp of "prevent SPAKE with 1DES, and require all future mandatory
checksum types to be deterministic".  (Possibly all future checksum
types entirely, but that may be too aggressive.)

-Ben