Re: [Cfrg] Proposed PAKE Selection Process // Integration in TLS ?

Benjamin Kaduk <kaduk@mit.edu> Tue, 25 June 2019 00:25 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B2F1201A8 for <cfrg@ietfa.amsl.com>; Mon, 24 Jun 2019 17:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 ZfcLGmJRD35A for <cfrg@ietfa.amsl.com>; Mon, 24 Jun 2019 17:25:29 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 AA8F012001E for <cfrg@irtf.org>; Mon, 24 Jun 2019 17:25:29 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5P0PPbu002334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jun 2019 20:25:27 -0400
Date: Mon, 24 Jun 2019 19:25:25 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: =?iso-8859-1?Q?=22Bj=F6rn_Haase=22?= <Bjoern.M.Haase@web.de>
Cc: CFRG <cfrg@irtf.org>
Message-ID: <20190625002524.GI48838@kduck.mit.edu>
References: <trinity-24ffcea8-2b91-42e5-9546-f533a825e019-1560936106868@3c-app-webde-bs23>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <trinity-24ffcea8-2b91-42e5-9546-f533a825e019-1560936106868@3c-app-webde-bs23>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/xV6HpWf96liMei-sRl1H7cZTsjY>
Subject: Re: [Cfrg] Proposed PAKE Selection Process // Integration in TLS ?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2019 00:25:32 -0000

On Wed, Jun 19, 2019 at 11:21:46AM +0200, "Björn Haase" wrote:
> Dear Eric,
> 
> thank you for your feedback! I do agree with and understand your points.
> 
> I am having several questions/remarks which I would like to address in separate threats, starting with the possibly most controversial side-aspects to consider for TLS integration.
> 
> > Eric Crocket wrote:
> >1. We would like to see the standardization of both a standalone scheme and its integration into TLS, similar to SRP (RFCs 2945 and 5054) or OPAQUE
> 
> I fully agree with you and also would also like to see PAKE integrated as a component in TLS. The important aspect to consider, when doing this, IMO will be that we are then integrating components into the TLS stack which today mostly are assigned to the "application layer" (which often should be expected not to consider security adequately). 
> 
> E.g. after a successful TLS-managed login the application on the server will need to know which user is just logged-in, e.g. in order to find out which authorization rights to attribute to the current session.This means that the interface to the TLS system would become somewhat more powerful and complex, by providing interfaces regarding user accounts.

Our experiences with TLS client certificate (re)authentication suggest that
this sort of tight binding between application-layer event and TLS-layer
authentication event is quite difficult to do properly, especially in the
face of HTTP/2 (or /3) and its multiple data streams.

-Ben