Re: [TLS] Application layer interactions and API guidance

Ilari Liusvaara <> Wed, 12 October 2016 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB9E4129521 for <>; Wed, 12 Oct 2016 11:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ys2WoChpua8Y for <>; Wed, 12 Oct 2016 11:03:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DE96D12950C for <>; Wed, 12 Oct 2016 11:03:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6ED3413D33; Wed, 12 Oct 2016 21:03:44 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id OjMhzapkYr1r; Wed, 12 Oct 2016 21:03:44 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id EF1C02310; Wed, 12 Oct 2016 21:03:43 +0300 (EEST)
Date: Wed, 12 Oct 2016 21:03:37 +0300
From: Ilari Liusvaara <>
To: Kyle Rose <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Application layer interactions and API guidance
X-Mailman-Version: 2.1.17
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: Wed, 12 Oct 2016 18:03:50 -0000

On Wed, Oct 12, 2016 at 01:51:25PM -0400, Kyle Rose wrote:
> On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara <>
> wrote:
> > > By this point in the connection, there is proof that early_data has not
> > > been replayed. The application doesn't necessarily know this when the
> > early
> > > data is first delivered, but it can find out later, which may be all that
> > > some applications want. Clearly not all, as you point out:
> >
> > This is actually only useful if the application can cancel out effects
> > of 0-RTT if handshake fails... Which tends to be fraught with peril to
> > implement.
> >
> Absolutely, but it doesn't seem like it would be any more perilous than the
> danger of accepting 0-RTT data in the first place: at worst you process the
> same replayed data, and at best you process less replayed data. (Unless
> there's a perverse incentive problem created by providing a half-measure.)

If all 0-RTT data is idempotent (including after replay delay!), sure.

However, if it isn't idempotent, you could get issues...
> > The 0-RTT data is not part of ClientHello. It is sent in streaming
> > manner (with handshake blocking if it hans't been completely sent by
> > the time ServerFinished is received.
> >
> > ClientFinished does _not_ MAC 0-RTT data, even in case of successful
> > transport.
> >
> There's my confusion. I misinterpreted both the Zero-RTT diagram and the
> table of handshake contexts under "Authentication Messages", specifically
> "ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm
> guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is
> accepted, is the second Finished message from the client ("{Finished}") the
> same message encrypted differently (using the handshake traffic secret)?

No, there is no difference in ClientFinished in case of 0-RTT accept or
reject (other than the contents of the CH and EE hashed in).
> Is there a succinct explanation for the design choices around what is and
> is not included in the handshake context? Being spread out over a year and
> a half of mailing list messages makes it hard to track. :-) I'm concerned
> that an on-path adversary that can slice-and-dice connections along MAC
> context lines will be able to create mischief, so I'd like to be able to
> convince myself that this isn't the case.

The thing that protects the 0-RTT data from substitution is the record
protection MACs that are made using key derived from the PSK secret. So
if the PSK secret is unknown, the key for 0-RTT can't be derived, and
as consequence, 0-RTT data can't be altered (there's end-of-data marker
too, preventing truncation).

And basically, ServerFinished MAC covers everything up to that point,
and ClientFinished MAC covers the entiere handshake (0-RTT data not

> And also, receiving 1-RTT data does not imply that the 0-RTT data
> > itself was not replayed (just that any replay it is of didn't
> > complete, assuming PSK keys are secret).
> >
> Yeah, I get that now. It seems like a missed opportunity to detect mischief
> after the fact, and could make for some interesting vulnerabilities for
> stateful protocols. E.g., if your early data is "cd /tmp" and your 1-RTT
> data is "rm -rf *", but the adversary is able to swap out the early data
> for a replayed "cd ~". That one is probably too obvious of an example to
> happen in real life, but imagine some developer who maintains his or her
> own tlstunnel hearing about 0-RTT and implementing early data for arbitrary
> applications using that tunnel wrapper because "reduced latency!": if early
> data were later authenticated, it would limit the scope of vulnerability to
> only those things that could fit in that first flight. But because it can't
> catch every possible replay-based attack, maybe such a measure would
> provide only a false sense of security. Sigh. I have no desire to re-ignite
> arguments from a year ago.
You can't swap out 0-RTT data (without PSK keys). One can only create
new connection attempts (that fail!) with the same 0-RTT data (and the
same ClientHello) before or after the real connection (if any, it
could be supressed, in which case you would get only failed handshakes
with 0-RTT data).