Re: [TLS] Does the ServerHello really need unencrypted extensions at all?

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Sun, 19 July 2015 08:02 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D83C1A1B95 for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 01:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 NR3Rw9bS5Rzs for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 01:02:33 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329431A21AD for <tls@ietf.org>; Sun, 19 Jul 2015 01:02:24 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 8F95F1A25EC; Sun, 19 Jul 2015 11:02:21 +0300 (EEST)
Date: Sun, 19 Jul 2015 11:02:21 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Dave Garrett <davemgarrett@gmail.com>
Message-ID: <20150719080221.GA15730@LK-Perkele-VII>
References: <201507182122.12566.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <201507182122.12566.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/4VwQBGRhYwL5ldLLGHJ3H7X8-y8>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Does the ServerHello really need unencrypted extensions at all?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 19 Jul 2015 08:02:35 -0000

On Sat, Jul 18, 2015 at 09:22:12PM -0400, Dave Garrett wrote:
> There's two issues (basically duplicates) for this topic, as well as an inline TODO.
> https://github.com/tlswg/tls13-spec/issues/66
> https://github.com/tlswg/tls13-spec/issues/72
> https://tlswg.github.io/tls13-spec/#server-hello
> 
> The current expectation is to separate extensions into unencrypted and encrypted, with:
> "The ServerHello MUST only include extensions which are required to establish the cryptographic context."
> 
> The rest then go into the new EncryptedExtensions message.
> 
> Are there really any extensions that this applies to? What extension
> couldn't we get away with encrypting? As soon as ServerKeyShare is sent,
> the client should have enough information to decrypt the encrypted
> extensions message.

Going through extension list, I think the following need to go to
ServerHello (and aren't considered deprecated):

max_fragment_length (existing, IIRC, a single enumeration)
known_configuration (new in TLS 1.3, just an ACK flag)
pre_shared_key (new in TLS 1.3, PSK only, 1 octet string)
early_data(?) (new in TLS 1.3, just an ACK flag)

(Technically known_configuration and early_data could be pushed
further, but that would create annoying special cases).


Additionally, if the handshake shape is to be fixed by CH/SH,
the following need to go to SH, because these introduce or change
messages (post EE, so with variable shape, EE is possible):

client_certificate_url
status_request
user_mapping
client_authz
server_authz
status_request_v2
signed_certificate_timestamp


> Site note: ServerKeyShare could probably just be merged into
> ServerHello at this point:
> 
>    struct {
>        ProtocolVersion server_version;
>        Random random;
>        CipherSuite cipher_suite;
>        select (DH) {
>            case true:
>                NamedGroup group;
>                opaque key_exchange<1..2^16-1>;
>            case false:
>                struct {};
>        };
>    } ServerHello;
> 
> Even if an extension is desired to set up a cryptographic context,
> then ideally you'd want to set up a basic extension-less one _first_,
> send an encrypted extensions message containing that needed extension,
> then send a second encrypted extensions message using the new context
> using the extension. The goal is to encrypt all the things, per TLS WG
> charter, so I don't see a point in allowing unencrypted extensions in
> ServerHellos at all anymore.

Changing ServerHello has the problem of then having incompatible
message with the same message type (the only offender for this currently
is IIRC ServerConfig, which collides with TLS 1.2 ServerHelloDone).

Additionally, if you ever need a security fix extension (:vomit:), those
likely would have to go to ServerHello.


-Ilari