Re: [TLS] Comments on EndOfEarlyData

Britta Hale <britta.hale@ntnu.no> Tue, 16 May 2017 23:02 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 46A2712EA6A for <tls@ietfa.amsl.com>; Tue, 16 May 2017 16:02:18 -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 IL_EKaOUG6qZ for <tls@ietfa.amsl.com>; Tue, 16 May 2017 16:02:15 -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 BEEB212EAAB for <tls@ietf.org>; Tue, 16 May 2017 15:57:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by samson.item.ntnu.no (Postfix) with ESMTP id 39FC5480089; Wed, 17 May 2017 00:57:57 +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 xjicFpKlMBHs; Wed, 17 May 2017 00:57:56 +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 9E937480087; Wed, 17 May 2017 00:57:56 +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> <238d04ec-eb56-7879-b8c5-754c910bae30@ntnu.no> <CABcZeBPJUQXxoE2FYyrnG7yYPRhUxy2y_D6CdvwZKEuyRopA3g@mail.gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
From: Britta Hale <britta.hale@ntnu.no>
Message-ID: <c270a7db-73e6-9d7f-e1f7-1bc45ba25717@ntnu.no>
Date: Wed, 17 May 2017 00:57:55 +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: <CABcZeBPJUQXxoE2FYyrnG7yYPRhUxy2y_D6CdvwZKEuyRopA3g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/E8C5-Wbk7zkhcNQWCJW4jAuhJ7A>
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 23:02:18 -0000

On 17. mai 2017 00:25, Eric Rescorla wrote:

>> 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.
>>
> This seems like a point where reasonable people can differ, especially as
> ultimately
> the motivation for this change was some sense of architectural consistency.
>
> To go back to my earlier question: does this change actually present some
> analytic
> difficulty, or do you just find it unaesthetic?
>
It is a matter of consistency not aesthetics, and that has actual 
implications on analysis. 

Classifying message types is meaningful in terms of truncation attacks.
Under a application traffic secret, a receiver is only guaranteed protection 
from a truncation if it receives an alert (close_notify). According to the 
current draft, a server is only guaranteed protection from such an attack 
for 0-RTT data if it receives a handshake message. Such a difference is sloppy
in terms of analysis.

Furthermore, there is the inconsistency of placement of the EOED message in 
the Finished hash. The lack of synchronization of EOED, i.e. not being fixed 
with respect to the other handshake messages, could complicate analysis in 
terms of matching server/client transcripts.

-- Britta