[TLS] TLS ExtensionType Registry

Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 11 August 2016 18:56 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 7C11712D842 for <tls@ietfa.amsl.com>; Thu, 11 Aug 2016 11:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.848
X-Spam-Level:
X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] 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 YbGqLEHf9MP6 for <tls@ietfa.amsl.com>; Thu, 11 Aug 2016 11:56:30 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEFB12D8EB for <tls@ietf.org>; Thu, 11 Aug 2016 11:56:30 -0700 (PDT)
Received: from [192.168.10.131] ([195.149.223.166]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MUoma-1bhnZH0uNA-00Y9Xs for <tls@ietf.org>; Thu, 11 Aug 2016 20:56:27 +0200
To: "<tls@ietf.org>" <tls@ietf.org>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <f5bbef49-6c37-8118-731d-9581ed7db877@gmx.net>
Date: Thu, 11 Aug 2016 20:56:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UxQQvoR3WeDnmdx2Fv5iMvqTFMVPITtw8"
X-Provags-ID: V03:K0:QF0mPyM7hHSef5vg8H4swOB8L4uPWYW0UgOn3TyESJvshBMNQDT lNIcdAONlJqjX5jgPmtvk+6D+3J7DLIFyPqu8jEuGoYaiU48k24iGYPT9dn+YZ6p3zYaxjh 6qv2QmA/zQeki2Eul1BXnzM5RD4zloOeMqDAR7zsRBDtbklF85HLqUE5QThDmHy9L0r/QBL VW/3LECXMu+3Wvg4DugLQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:bD8WMIY9xn4=:+CbE4IriIcvRlv39CN8R+y ltG0tsfMOTy9PaMry/0trjZsLOY/84q0KTUdG5wpYejf0XhMprWQOoyN+uHHK1yv1WFG5AKcJ HcoSKt+w95/BWnS3t7M7v7EBrgf9oPsMeRb4gtyed9i49168ktSATvfQ7pne+yER8WU7FzBHl tl1PsziLPXMdjO+jTQb4ASYTBgPmXw+EeF+QcYCNEtL9N0e7ICQUOfA8+r6X8yIgjj0cuhHT1 /pNS5TJqka3wo3x5T5nJCwvDCa+itEhHEoEFS6b2HAjFbaSct8H9ZTCLLEZJhpsUv7nKlGOdP 3y58lK17d07cxruepJBZcAEBqRmIU/pYic0UaTo5U8YA9BpbktiLvgJzUj5qyrNbeICIdzL+p yMUQGObboao6Zc++8aZDnyE47HNxMEg0K9pisyjFBt0rrQcTwpH7bocc+E5q6NePVEMLGV1Mj 5QqpHif9BtrG/zwtgLdAEpBMgEEO+OcumklHustNb7eF9o/d+yDkU5YTOt9ubsOvHE3je/mDd vv6MGM04vLLLrRk4kO36lefVkkFyy7L0uqMMJNLUq03+xbauHfipI27A7RVILblfUE470Sffz 0sgp62mAV5PVDTNxz6saxOtAgl4feT8TU1I+KZQJJXSFe2rZnRCNBaAmGCfLuZhX05NBu/mRM ljfCkEnbcO8amzcsFo+ffJkiWKR6SijVzlPrafa5bYnkE7kyGGaYXezIjSucRKBaNil+uGfIE q5PUImr9vqsP28ABOPm7cxLvn+LCEjDz/o//Lmi95SCiRHc5whjd/y5er7Y=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3rxRlIzp7FUaalRAkmgpXB1y4Ak>
Subject: [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 18:56:32 -0000

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.

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).

The key_share & the pre_shared_key extension is sent in clear in the
ClientHello and in the ServerHello.

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.

I believe the definition of 'clear' should be changed to:

    "Clear", indicating that they shall be sent in clear
    in the ClientHello and in the ServerHello.

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.

Ciao
Hannes