Re: [TLS] TLS ExtensionType Registry

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 11 August 2016 19:09 UTC

Return-Path: <ilariliusvaara@welho.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 7789012D1BC for <tls@ietfa.amsl.com>; Thu, 11 Aug 2016 12:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 Eb_w-2El3rYW for <tls@ietfa.amsl.com>; Thu, 11 Aug 2016 12:09:41 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id D6DD212B020 for <tls@ietf.org>; Thu, 11 Aug 2016 12:09:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id B0B67D9CB for <tls@ietf.org>; Thu, 11 Aug 2016 22:09:38 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id oyZlD-KGGVUO for <tls@ietf.org>; Thu, 11 Aug 2016 22:09:37 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 6A25D21C for <tls@ietf.org>; Thu, 11 Aug 2016 22:09:37 +0300 (EEST)
Date: Thu, 11 Aug 2016 22:09:29 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: tls@ietf.org
Message-ID: <20160811190929.bowe75bhjeks6bqf@LK-Perkele-V2.elisa-laajakaista.fi>
References: <f5bbef49-6c37-8118-731d-9581ed7db877@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <f5bbef49-6c37-8118-731d-9581ed7db877@gmx.net>
User-Agent: Mutt/1.6.2-neo (2016-07-23)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IIo_gX16gl8vqg8f7bswk3ovDcE>
Subject: Re: [TLS] TLS ExtensionType Registry
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: Thu, 11 Aug 2016 19:09:43 -0000

On Thu, Aug 11, 2016 at 08:56:25PM +0200, Hannes Tschofenig wrote:
> Hi Ekr, Hi all,
> 
> reading through https://tools.ietf.org/html/draft-ietf-tls-tls13-14 I
> noticed the TLS ExtensionType Registry on page 77 & page 78.
> 
> The "TLS 1.3" column has one of four values, namely
> 
>    - "Client", indicating that the server shall not send them.
>    - "Clear", indicating that they shall be in the ServerHello.
>    - "Encrypted", indicating that they shall be
>      in the EncryptedExtensions block
>    - "No" indicating that they are not used in TLS 1.3.
> 
> The following values deserve a closer look:
> 
>    +-------------------------------+-----------+-----------------------+
>    | Extension                     | Recommend |               TLS 1.3 |
>    |                               |        ed |                       |
>    +-------------------------------+-----------+-----------------------+
>    | server_name [RFC6066]         |       Yes |             Encrypted |
>    |                               |           |                       |
>    | max_fragment_length [RFC6066] |       Yes |             Encrypted |
>    |                               |           |                       |
>    | key_share [[this document]]   |       Yes |                 Clear |
>    |                               |           |                       |
>    | pre_shared_key [[this         |       Yes |                 Clear |
>    | document]]                    |           |                       |
>    |                               |           |                       |
>    | cookie [[this document]]      |       Yes | Encrypted/HelloRetryR |
>    |                               |           |                equest |
>    +-------------------------------+-----------+-----------------------+
> 
> The server_name extension is sent in the initial ClientHello and will
> not be encrypted since it will be used to select the right server in a
> hosting environment.

Actually, the server_name could be made into 'client', since the only
thing server sends about server_name is an ACK, meaning it has taken it
into "consideration" (in some vague way).

> The max_fragment_length extension is sent in the initial ClientHello but
> is not as essential as the server_name extension. Still, in most cases
> there is no security context established at the time of sending the
> ClientHello (at least not in the full handshake when ECDHE is used).

I think max_fragement_length should be made into 'clear', given what
it is used for.
 
> The cookie is not sent encrypted in the HelloRetryRequest since the
> HelloRetryRequest is sent when the client has not provided a suitable
> "key_share" value. The DoS protection feature used in the
> HelloRetryRequest is most likely useful only in context of an unreliable
> transport protocol. If you want DoS protection then the server should
> not store per-session state, which establishing security context would
> require.

The "encrypted" seems to be leftover from time when there were inter-
connection cookies (which were removed).
 
> I fear that the use of extension in the encrypted block may be dependent
> on where they can first be used and also in what handshake variant. It
> is also a question whether it makes sense to send an extension encrypted
> in the ServerHello when it first appeared in clear in the ClientHello.

 
> I wonder whether the "TLS 1.3" column in this table could actually be
> simplified to only provide information about extensions that can be used
> in TLS 1.3. Whether something is sent in clear, encrypted or only be the
> client is something that should be described in the protocol
> specification itself.

Actually, in that wide sense, all extensions can be used. TLS 1.3
just forbids negotiation of some extensions. But it does not forbid
client sending any extension if downnegotiation is supported.


-Ilari