Re: [TLS] Comments on EndOfEarlyData

David Benjamin <> Tue, 23 May 2017 18:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DF0112E04F for <>; Tue, 23 May 2017 11:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oO6QW-ZNW6Xc for <>; Tue, 23 May 2017 11:36:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C51A112E049 for <>; Tue, 23 May 2017 11:36:45 -0700 (PDT)
Received: by with SMTP id 9so122555564pfj.1 for <>; Tue, 23 May 2017 11:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/iClSoiWg+TCXPNhPsJbOAA7A2cXHaNghv+vIWl+sXU=; b=hsFyvupQwFiwxr1Kynb2kqA9wARueAs+Y8PIFmeulq9y3NzVDX64aW1G7h3tgRoqvx Ck1HGlLZdC5eurlgxNtQL0qfMtGYeeN0jh3gPQ27r6H6fcIrlt0/J6ejDZ6cApfKAFhP O7Bag71eD7FztEXSnuNMTmJiGBxamKoNE6NJY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/iClSoiWg+TCXPNhPsJbOAA7A2cXHaNghv+vIWl+sXU=; b=SAbo8nhOOwuJHq9Wu0Uei2PmxrtHB9kzaLOLCbrh2F5ctNTZw7YYmr3+fFs64lU2pC LR3qqOrRs/kawq45E/+rZqG1JaL6f02Damv/7PVq/pB6km43gCRIJs/w2ZMcZzjbTjVd hp4TNCFw0Ji/uzGyS6iXGLXyiLERT/L1l+Ak3z/xYJemN6P0hmeqxB47ZpC5xERCAI3B KXRFKgE1uq0kDRR0Xh/XS8N6q6u/sqGmZdGRWrABroM2XrE6AId+InvCJeBzueRWJdp3 zfTWW2LyvTglX2ACMD8BnWR2XCwg++dClbveXSGyw7enYXs/jnhCPANNAuSTuSmjcNlM 7Zjw==
X-Gm-Message-State: AODbwcCo3IkXY6EelpdCwEkLe3ya8ew+nqpDgCcUXIGvdqTT+JrozVO1 XYH2gWXGbLycjN/H+heRpPdqBhZDyIrHWd0=
X-Received: by with SMTP id y2mr9541491pgc.10.1495564605286; Tue, 23 May 2017 11:36:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 23 May 2017 18:36:33 +0000
Message-ID: <>
To: Benjamin Kaduk <>, Markulf Kohlweiss <>, "" <>
Cc: Antoine Delignat-Lavaud <>, Samin Ishtiaq <>, Britta Hale <>
Content-Type: multipart/alternative; boundary="f403045db81009fd5805503545e7"
Archived-At: <>
Subject: Re: [TLS] Comments on EndOfEarlyData
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 May 2017 18:36:48 -0000

On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk <> wrote:

> My initial thoughts...
> On 05/23/2017 06:50 AM, Markulf Kohlweiss wrote:
> I am paraphrasing a long thread on the issue that we had within
> the miTLS development team, and I am primarily commenting on the
> analysis aspects. I also hope that it will clarify any remaining
> problems of understanding that I have on the issue.
> If we see EOED as a stream termination signal, then there seems
> to be a difference in performance for conservative servers that
> want to wait until receiving all 0RTT data before responding to
> the client's request in 0.5RTT communication.
> Said otherwise, we want servers to be able to respond with application
> data based on application data from the client and know that that
> that data was not truncated.
> Thanks, the keyword of "truncated" caused me to understand the intended
> point.
> I think this question ends up tying into the more philosophical one of
> whether early data and 1-rtt data are considered "separate streams" or not
> -- if they are separate streams with distinct end/start, then of course one
> wants to detect possible truncation as it happens.  But, if they are
> conceptually the same stream and the boundary between them is "just" a
> bookkeeping operation of key change, then there is no need to be concerned
> about detecting truncation; the application just continues reading in data
> and replying when complete application protocol requests are received.

Truncation detection is meaningful in both cases. We rely on KeyUpdate
being protected and tied to the immediately preceding record (by way of
sequence number). Otherwise an attacker could toss out chunks in the middle
of the stream immediately before a KeyUpdate.