Re: [TLS] Comments on EndOfEarlyData

Britta Hale <britta.hale@ntnu.no> Tue, 16 May 2017 21:46 UTC

Return-Path: <britta.hale@ntnu.no>
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 2919E129B4C for <tls@ietfa.amsl.com>; Tue, 16 May 2017 14:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.304
X-Spam-Level:
X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 LDtRGikK9z7c for <tls@ietfa.amsl.com>; Tue, 16 May 2017 14:46:18 -0700 (PDT)
Received: from samson.item.ntnu.no (samson.item.ntnu.no [129.241.200.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2DB129BFC for <tls@ietf.org>; Tue, 16 May 2017 14:41:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by samson.item.ntnu.no (Postfix) with ESMTP id 2EECD480089; Tue, 16 May 2017 23:41:08 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at item.ntnu.no
Received: from samson.item.ntnu.no ([127.0.0.1]) by localhost (samson.item.ntnu.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhHliYFggc_S; Tue, 16 May 2017 23:41:07 +0200 (CEST)
Received: from [192.168.1.168] (84-52-238.131.3p.ntebredband.no [84.52.238.131]) by samson.item.ntnu.no (Postfix) with ESMTPSA id A44E5480087; Tue, 16 May 2017 23:41:07 +0200 (CEST)
To: Eric Rescorla <ekr@rtfm.com>
References: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no> <CABcZeBMu=9KPvmz-sDknXpa4Vjer=md=ZqsFqGd6WNEFdAxSdg@mail.gmail.com> <1f7c62a1-db73-aeae-97d0-77c769606198@ntnu.no> <CABcZeBPb6HrykcJ8qxktiaH1rMaGv4jEkBBJnDNkdMjOSG-5sw@mail.gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
From: Britta Hale <britta.hale@ntnu.no>
Message-ID: <238d04ec-eb56-7879-b8c5-754c910bae30@ntnu.no>
Date: Tue, 16 May 2017 23:41:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBPb6HrykcJ8qxktiaH1rMaGv4jEkBBJnDNkdMjOSG-5sw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WuBsokjD5RHJ4fYOoJjKEJM8eVs>
Subject: Re: [TLS] Comments on EndOfEarlyData
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 16 May 2017 21:46:22 -0000

On 16. mai 2017 23:28, Eric Rescorla wrote:

>
>> Avoiding getting caught on the word "connection", EOED signals the end of key
>> use like other alerts, which is the central issue. Notably, EOED does
>> not signal key change, unlike a KeyUpdate message or Finished message - even
>> the name indicates that it is for "end of data". Its behavior is fundamentally
>> like an alert's, indicating only end-of-key use for application data.
> I'm not sure why you say it doesn't signal a key change: EOED signals the
> transition
> between data encrypted with the early traffic keys and that encrypted with
> the handshake
> key.

EOED signals the end of data encrypted with early traffic keys, yes, and the next 
message is the Finished message encrypted with the handshake traffic key. However, 
the Finished message is not *data*, and use of the application traffic key is signaled
by the Finished message, not EOED. The Finished message, like a KeyUpdate message, are 
handshake messages, and both signal the start of a new key use for application data. 
In comparison, EOED signals the end of key use for application data - which correlates 
to alert behavior.