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

Benjamin Kaduk <kaduk@mit.edu> Tue, 26 September 2017 02:26 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADA0134641 for <kitten@ietfa.amsl.com>; Mon, 25 Sep 2017 19:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKJOJg6clOOz for <kitten@ietfa.amsl.com>; Mon, 25 Sep 2017 19:25:56 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7FA13463C for <kitten@ietf.org>; Mon, 25 Sep 2017 19:25:56 -0700 (PDT)
X-AuditID: 1209190f-207ff70000007ae5-fd-59c9bab34efd
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A6.49.31461.3BAB9C95; Mon, 25 Sep 2017 22:25:55 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v8Q2PsPS005966; Mon, 25 Sep 2017 22:25:54 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8Q2Pouv006718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Sep 2017 22:25:53 -0400
Date: Mon, 25 Sep 2017 21:25:51 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Simo Sorce <simo@redhat.com>
Cc: kitten@ietf.org
Message-ID: <20170926022550.GZ96685@kduck.kaduk.org>
References: <x7d1sn5zyl8.fsf@equal-rites.mit.edu> <20170919015937.GN96685@kduck.kaduk.org> <1505920169.1143.15.camel@redhat.com> <20170923190527.GU96685@kduck.kaduk.org> <1506358991.3211.1.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1506358991.3211.1.camel@redhat.com>
User-Agent: Mutt/1.8.3 (2017-05-23)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1t2862Skwb0zihZHN69isfgxdxGr A5PHkiU/mTze77vKFsAUxWWTkpqTWZZapG+XwJXxdMcfxoI/EhV7m+UaGK8JdzFyckgImEhM XLyZrYuRi0NIYDGTxI2fe1ggnI2MEkdm7YVyrjJJbFnygw2khUVAVWL/2V8sIDabgIpEQ/dl ZhBbREBBYkH/HbA4s4CwxPI1Z8HqhQVcJM5+WMoEYvMCrbu5YjkzxNBrjBIt7y9CJQQlTs58 AtWsI7Fz6x2gZg4gW1pi+T8OiLC8RPPW2WC7OAUMJZYs+sEKYosKKEvM27eKbQKj4Cwkk2Yh mTQLYdIsJJMWMLKsYpRNya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3ECA5rSf4djHMa vA8xCnAwKvHwNjCdjBRiTSwrrsw9xCjJwaQkynszESjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJ hPf6dqAcb0piZVVqUT5MSpqDRUmcd1vQrkghgfTEktTs1NSC1CKYrAwHh5IE7/adQI2CRanp qRVpmTklCGkmDk6Q4TxAwxt2gAwvLkjMLc5Mh8ifYlSUEufdBNIsAJLIKM2D6wWlHYns/TWv GMWBXhHmPQtSxQNMWXDdr4AGMwEN7p16AmRwSSJCSqqBkbfuy4ENadkTUthFIs4vfHbr4c0/ m+s1nMPXCKx/qLdQnsVWdu/9q7umC7c9Zm8K+FogIVy2lmEh25ubNoJdCyZsdjwWsEhY4fWq k9Wbg2aocKnlBHP+aUuQFRQzTa1KP71H5dR3gSkiyxamiIbPuz4153QIB/PUOZJtzzVrcp2e MLWysd38rMRSnJFoqMVcVJwIACM4sTQWAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/fIq5PB8hxe93rm9gBWPQMLbXjw4>
Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Sep 2017 02:26:00 -0000

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