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

Nikos Mavrogiannopoulos <nmav@redhat.com> Mon, 20 July 2015 07:02 UTC

Return-Path: <nmav@redhat.com>
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 00A3E1A00DC for <tls@ietfa.amsl.com>; Mon, 20 Jul 2015 00:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 Ai3e_awaHSZ4 for <tls@ietfa.amsl.com>; Mon, 20 Jul 2015 00:02:25 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA841A00E0 for <tls@ietf.org>; Mon, 20 Jul 2015 00:02:21 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 1936192494; Mon, 20 Jul 2015 07:02:21 +0000 (UTC)
Received: from dhcp-10-40-3-77.brq.redhat.com (dhcp-10-40-3-77.brq.redhat.com [10.40.3.77]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6K72IRZ013704 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2015 03:02:20 -0400
Message-ID: <1437375738.3377.3.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Dave Garrett <davemgarrett@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>, Eric Rescorla <ekr@rtfm.com>
Date: Mon, 20 Jul 2015 09:02:18 +0200
In-Reply-To: <201507182122.12566.davemgarrett@gmail.com>
References: <201507182122.12566.davemgarrett@gmail.com>
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.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/xmZ6YvspF3o9S8E_uounZR-lEzQ>
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: Mon, 20 Jul 2015 07:02:29 -0000

On Sat, 2015-07-18 at 21:22 -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?

The extensions which indicate the type of server (ALPN) or the name of
server must be able to be sent in the clear. The reason is that middle
-boxes or proxies must be able to determine the actual server to
transfer the session without terminating it.

regards,
Nikos