Re: [TLS] Refactoring the negotiation syntax

Eric Rescorla <ekr@rtfm.com> Wed, 13 July 2016 20:23 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAA612B037 for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 13:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 e_iu5d1kDvDY for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 13:23:41 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51AE912D7B9 for <tls@ietf.org>; Wed, 13 Jul 2016 13:23:41 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id i12so53708053ywa.1 for <tls@ietf.org>; Wed, 13 Jul 2016 13:23:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uOsZCB2TLoT9yYKu1d664ZITDTglQ1xhXKRyIeXeeog=; b=Eu9eweVrgarUYuHPjYCJ+KuQ9DmXJGvF4Vn2nCscmMwM0CLUcbn9sFJt6vMatjibhP FFEVij9GNUk9caUN45MGdoYCpDzNywd7hJ4DddetPQ962LAKvi5+zmKHrghTA+8Egsdo 6EneyDTlnjKc1zXK9f8K/rMP4JBxO1lLnBU5OjPMI0e867ABtPEh8spZn2AGi7mumH8v N5flo003ifoVc5L3/4K4m/O1/4ytZP3RRO6Sdke2sEBrzg5kXFv8EVa3Z+EOPy83PTu2 EcpzsqRNQc5kebpKEUieF8GWuGmrHS1qDTWZ4EDx2+j7bxqtJ2cADgceD3osFtvJx2Eq z02g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uOsZCB2TLoT9yYKu1d664ZITDTglQ1xhXKRyIeXeeog=; b=ME80c8RI2Bhmz/EV6vWLSivu5atu6gduywFEG+blgmdHQk0Rrx+JMGvkEsYV+2gPIt WjX9Mr+7Ol64UMDA1VQUc415PT9njtmqFwSA+JN4eGHaM1j82Tt2b0GR5A8+uT7zkvHH 3qZNhDEyxurVUBQaPF4jywrTC5U/CaRbnCVwc/lnbJZvGZ1avlqjCg8gHTHB5HIQ4kVG mnFaSQ63cEepPxZwNfRViLWANscCumAoTIXVEzjOV60165S2MfdsqGnoSoz85MLwWaIN y2a3Ts6FDR/bhDf4uws/XNhl5awMHw7VSpBechQgbeiVv18rOQ9K4wxLlBrudYYKidRJ S1tw==
X-Gm-Message-State: ALyK8tJ7JxuzitNFpuiQVrgmk+jrauN1X5FUFdggbRegCBR8UI6hHEjMA7YsumdH+vSOtyBjYC0svtJCd5+W9A==
X-Received: by 10.13.201.134 with SMTP id l128mr7688650ywd.93.1468441420567; Wed, 13 Jul 2016 13:23:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.152.13 with HTTP; Wed, 13 Jul 2016 13:23:01 -0700 (PDT)
In-Reply-To: <201607131401.12856.davemgarrett@gmail.com>
References: <CABcZeBPh+BGtnBb725G+YzZZzdSUh5KtViqh3Z339apSKRpygg@mail.gmail.com> <201607131401.12856.davemgarrett@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 13 Jul 2016 13:23:01 -0700
Message-ID: <CABcZeBPZdUn-kjoe_E_FV_=nRPKGDKjf4ZiRoA9SjSqm1TLmQQ@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary=001a114e630e3f4a0e05378a294a
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WrjGSB_eQBGE3yRlUNRhnDuD6Ds>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Refactoring the negotiation syntax
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jul 2016 20:23:42 -0000

On Wed, Jul 13, 2016 at 11:01 AM, Dave Garrett <davemgarrett@gmail.com>
wrote:

> On Wednesday, July 13, 2016 01:12:54 pm Eric Rescorla wrote:
> > The basic idea here is to factor out the TLS 1.3 negotiation into three
> > mostly orthogonal axes.
> >
> > - Symmetric cipher/PRF  -- indicated by the cipher suite list as in TLS
> 1.2
> > - Key exchange -- indicated by the key_shares and pre_shared_key
> extensions
> > - Authentication -- indicated the signature_algorithms and pre_shared_key
> >   extensions
> >
> > A proposal for how to do this is below. See the end for other options,
> > caveats, etc.
> >
> >
> > If we take PSK out of the picture, this gives us a very simple structure:
> >
> > - The client offers a set of key_shares and the server picks one that it
> >   likes [1].
> > - The client offers a list of signature_algorithms and the server picks
> >   a certificate/key that matches that list and signs with it.
>
> Your proposal ignores the supported_groups extension.


I don't think it affects it either way.


The requirement of this is one of the wrenches that causes the complexity
> of this whole system to increase. HelloRetryRequest is the other wrench
> here. We very much could do everything supported_groups does in key_share;
> just stick unsent supported groups in the share with null keys.


David suggested this offline, but I don't think this makes things
significantly simpler, because now.


As to the PSK side of things, one idea which I brought up at some point is
> to merge the PSK extension into the key share extension to create one
> unified key exchange extension. We just assign some group ID to PSK, then
> the identity is just its equivalent of a key to be in the bag of keys. One
> less new extension to worry about, and instead one new extension that is
> 100% required for all TLS 1.3 requests, without exceptions that might need
> to be handled. (blending into the other current list thread, here) The
> special handling of PSK is another one of these metaphorical wrenches that
> increases the design complexity in various places.
>

I think this actually makes matters *worse* because then you have one
situation where (ECDHE) where the server sends one key share and one
(ECDHE-PSK) where the server has to send/acknowledge two

-Ekr


As to the actual core proposal, it could work. I too am not ideally in
> favor of redoing everything at this late stage, but I'm not against
> reconsidering it, if we can all actually agree on an alternative.
>
>
> Dave
>