[TLS] EncryptedExtensions message in [draft-ietf-tls-tls13-10]

John Foley <foleyj@cisco.com> Thu, 10 December 2015 17:40 UTC

Return-Path: <foleyj@cisco.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 277A21A905C for <tls@ietfa.amsl.com>; Thu, 10 Dec 2015 09:40:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 GHW5j6_rYKmI for <tls@ietfa.amsl.com>; Thu, 10 Dec 2015 09:40:24 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143221A9054 for <tls@ietf.org>; Thu, 10 Dec 2015 09:40:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1129; q=dns/txt; s=iport; t=1449769224; x=1450978824; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=D5zz5BasJDVViRq/7jx5hK7Yv2Z+KMLZGG93H1lmsuM=; b=ReIz/TFnNideInXqAUK660UGP/Ef3a9g4Z6xmL0Wn0GHV+2iu6veeHer QC+oIpMJliWWBrFpl0hdNbJt6VqB3h6XunEcxXH5MWOcPeTSVvvNo60kR kX5YoS7S+JL/pxcdM2G/uDwXuU2ZOMcpuNzy6a0DRkLAkKrC/NlRiHMEu o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVBQCNuGlW/5JdJa1egzrAbIdJOxEBA?= =?us-ascii?q?QEBAQEBgQqEXhVANgIFFgsCCwMCAQIBWAgBAYgrnliPcJIOLYEBj3mCUIFJBY4?= =?us-ascii?q?niEiNQ4kkk2U3LIQiIIYOAQEB?=
X-IronPort-AV: E=Sophos;i="5.20,409,1444694400"; d="scan'208";a="52396637"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Dec 2015 17:40:23 +0000
Received: from [10.82.161.102] ([10.82.161.102]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tBAHeMt4014982 for <tls@ietf.org>; Thu, 10 Dec 2015 17:40:23 GMT
To: tls@ietf.org
From: John Foley <foleyj@cisco.com>
Message-ID: <5669B920.9080001@cisco.com>
Date: Thu, 10 Dec 2015 12:40:48 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/BvaqpfvRsK82jzT3-DHjac_JCrU>
Subject: [TLS] EncryptedExtensions message in [draft-ietf-tls-tls13-10]
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: Thu, 10 Dec 2015 17:40:25 -0000

While reviewing the latest TLS 1.3 draft (revision 10), the description 
in section 6.3.3 uses the following wording:

When this message will be sent:

       If this message is sent, it MUST be sent immediately after the
       ServerHello message.  This is the first message that is encrypted
       under keys derived from ES.


The use of the word "if" implies this is an optional message. However, 
Figure 1 in section 6.2 implies the EncryptedExtensions message is not 
optional since it's not footnoted with an asterisk. The asterisk 
footnote is described as:

Indicates optional or situation-dependent messages that are not always sent.


Can anyone comment on whether the EncryptedExtensions message is 
optional?  If it is, should Figure 1 be updated to reflect this? Or, 
should the the text in section 6.3.3 be updated to indicated this 
message is required?

This is an important detail for implementors, since the client-side 
state machine will need to know whether to expect the 
EncryptedExtensions message after the ServerHello, or to expect another 
one of the subsequent messages.