[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: A0AVBQCNuGlW/5JdJa1egzrAbIdJOxEBAQEBAQEBgQqEXhVANgIFFgsCCwMCAQIBWAgBAYgrnliPcJIOLYEBj3mCUIFJBY4niEiNQ4kkk2U3LIQiIIYOAQEB
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.
- [TLS] EncryptedExtensions message in [draft-ietf-… John Foley
- Re: [TLS] EncryptedExtensions message in [draft-i… Eric Rescorla
- Re: [TLS] EncryptedExtensions message in [draft-i… Eric Rescorla
- Re: [TLS] EncryptedExtensions message in [draft-i… John Foley