IETF Logo Mail Archive

Re: [kitten] SPAKE Preauth

Nathaniel McCallum <npmccallum@redhat.com> Fri, 01 May 2015 21:32 UTC

Return-Path: <npmccallum@redhat.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A231A19FE for <kitten@ietfa.amsl.com>; Fri, 1 May 2015 14:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.911
X-Spam-Level:
X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 kZrHTlOJ85hv for <kitten@ietfa.amsl.com>; Fri, 1 May 2015 14:32:37 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 973461A01AE for <kitten@ietf.org>; Fri, 1 May 2015 14:32:37 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t41LWaCN012684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 1 May 2015 17:32:36 -0400
Received: from vpn-58-124.rdu2.redhat.com (vpn-58-124.rdu2.redhat.com [10.10.58.124]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t41LWZij006145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 May 2015 17:32:35 -0400
Message-ID: <1430515954.2514.17.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Nico Williams <nico@cryptonector.com>
Date: Fri, 01 May 2015 17:32:34 -0400
In-Reply-To: <20150501213055.GD10065@localhost>
References: <1430138754.2682.10.camel@redhat.com> <553FA2B3.8030301@mit.edu> <alpine.GSO.1.10.1504281531500.22210@multics.mit.edu> <20150501211503.GA10065@localhost> <1430515138.2514.10.camel@redhat.com> <20150501212321.GC10065@localhost> <1430515623.2514.16.camel@redhat.com> <20150501213055.GD10065@localhost>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/lyTxBzFEVZxQuwxyYMq4pvTi1T4>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] SPAKE Preauth
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 01 May 2015 21:32:39 -0000

On Fri, 2015-05-01 at 16:30 -0500, Nico Williams wrote:
> On Fri, May 01, 2015 at 05:27:03PM -0400, Nathaniel McCallum wrote:
> > On Fri, 2015-05-01 at 16:23 -0500, Nico Williams wrote:
> > > It doesn't seem like overkill to me.  Unless the property that an
> > > attacker can't distinguish which factor was wrong is not that
> > > important.
> > > 
> > > Note that AS implementations could just always send 
> > > continuations as
> > > EncryptedData, leaking that way.  What I want is for it to be
> > > possible to implement an AS that doesn't leak.
> > 
> > I don't think that is possible. The cost for sending data in the 
> > clear
> > to avoid leaking EncryptedData is the loss of integrity protection.
> 
> Any OTPs that require continuation then result in this leak.  This 
> has
> to be documented, since avoiding this leak is a core feature of this
> protocol.

Correct. Is the current warning insufficient? It is my understanding
this is spelled out in the security considerations section.

Nathaniel

v2.23.0 | Report a Bug | By Email