Re: [TLS] Refactoring the negotiation syntax

Dave Garrett <davemgarrett@gmail.com> Wed, 13 July 2016 18:01 UTC

Return-Path: <davemgarrett@gmail.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 B84F112D0C1 for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 11:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wkYcu4zBGKnk for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 11:01:16 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 B163D12D193 for <tls@ietf.org>; Wed, 13 Jul 2016 11:01:15 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id j17so51161088ywg.0 for <tls@ietf.org>; Wed, 13 Jul 2016 11:01:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-transfer-encoding:message-id; bh=tF0Ta5b14/SZH/qFd3XFMkFPST3suXXPhy+WhdUOAXM=; b=rTOk7kQ7bZu8BdqnX/LIbBegsElKpncJx3VehaTHAoFViNR+3+YnepGvDBcmwhZ/4c ZUOMcynOCN1bn+8MPiKBP7Y5oFI8BEWv0YtcwH6LvzSvwbeHgXnH1HaNgGkBVEbe5WGp 851/vdyke8285fjIwvCMk/oo1IDGqDvNfGiYVFz09i8/8T0jTM00TQUWt03F3fcfe/Js jgwCiU+imNhZv6cZljjZ8fl/ZhqfxLkLU3DqnLO+DH+4TeXaB3i2E73/pkVqioYxZr7a IVy3zAU0HfsZpSwq5lKCpjybHHV3kW6uutfQTDAYp8rBSPuakGn4IsinKBBz4PCaGDhj 5d3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=tF0Ta5b14/SZH/qFd3XFMkFPST3suXXPhy+WhdUOAXM=; b=Ecya5VJvTQS+TSynahklXppUcSsq/UsP72Vgz+IBUNrV+jUcoMxEdUAGI83XgugO3b owCFqoTqdzEWoyY+He0tr7QCcPuZLjjBIk5LXaGsKI31c3+ci6sD7vsxDwxqqOLpYETB k29SpuJWpus/PA1k/oC84k4lZZDJh9B24htq4JMWVS/ECVrihxmZ2R/QieqL7TD5PW9p gcfxbjZnKNkmx0CZMbTVeyoOdUFzISkPb/f6sRjpj8OxvxqCrwKDOJ3dH8h3lYBUzGyC EhtH9yXi6xpl1YCH4301f67caMR8Flxhwk9qERT/tk4AeG9QmL6siwqC62J08fXUq/Or tIMQ==
X-Gm-Message-State: ALyK8tKL9i2Uz8Fk9XwQ/aRqHUINc6WRZZywBwaLJQR4BgpVJs54tKRR74rhuwSgoeCLAQ==
X-Received: by 10.13.251.4 with SMTP id l4mr6903733ywf.132.1468432874696; Wed, 13 Jul 2016 11:01:14 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id a22sm6294ywh.42.2016.07.13.11.01.13 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 13 Jul 2016 11:01:14 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org, Eric Rescorla <ekr@rtfm.com>
Date: Wed, 13 Jul 2016 14:01:12 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CABcZeBPh+BGtnBb725G+YzZZzdSUh5KtViqh3Z339apSKRpygg@mail.gmail.com>
In-Reply-To: <CABcZeBPh+BGtnBb725G+YzZZzdSUh5KtViqh3Z339apSKRpygg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201607131401.12856.davemgarrett@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Qd0T6sLZRXB3fHC2UTmQR7unnGg>
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 18:01:18 -0000

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. 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. The desire to maintain backwards compatibility with a different mechanism using the old version of supported_groups is what makes this a problem. (back compat is not free)

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.

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