Re: [TLS] Application layer interactions and API guidance

Kyle Rose <> Wed, 12 October 2016 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A695129466 for <>; Wed, 12 Oct 2016 10:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 KLaU4uhTtDLo for <>; Wed, 12 Oct 2016 10:51:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2254F1279EB for <>; Wed, 12 Oct 2016 10:51:27 -0700 (PDT)
Received: by with SMTP id f128so43004175qkb.1 for <>; Wed, 12 Oct 2016 10:51:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lZbsAVRFNBpCApUEnkLNFRkWoTSIWfnoqlB/ESd2lA4=; b=kEZj6inOp3M1mwxsueGg5eDg8i5PozJ3GnrkR9JzSpzJZ1kekDCTIkGydqeQW9pR18 7WCF6Og1q1gC8By3ZX+fCtXCRRN4/rSQcihnxtC6lPMzE36y587Wlk00IqsJXVeLFgVy ot12f1NoXM5A0sHVMkhWZaXE30MxH8EqsAPNw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lZbsAVRFNBpCApUEnkLNFRkWoTSIWfnoqlB/ESd2lA4=; b=QRnKXovG9yzTkst7hSPjU6JWU2ocrsTmL7aHf+NzyZ2G8PXcEpD0M3PuQxXCXGgX43 WKGpNvcdEpvLhNsw2EWn46RwkJqvc6iCtXoXSlQ4dx1Z8Qi9Fhds+RA0BJLmTtiAfF8D APZMrzHaRt+ovw3AJ5rI4/S2NLrorNwX7jiyffSyCfHEwsA4gZMcGuy2YTxf716l4sKs Zs0zSWi6aNg9iFyxteOrixYxnZoCQTUdzHgi5qbsxBRrlg6JsdyotJdvpLRVMYD7vxbu nNr6jJQnapxbYch5kkgK4NOHLB+4msCZYsiVR0bqsSQGHVl8kE1AvACznJLydtU2UTtD bVHw==
X-Gm-Message-State: AA6/9RkYFc+IufRzoIUjhroBamOGK/uO78GSRXhMQw/XoLjZRG+LuqImTEJ91qTBeqwiz5urU7XDjqyar1XtFA==
X-Received: by with SMTP id b3mr2373257qkg.77.1476294686245; Wed, 12 Oct 2016 10:51:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 12 Oct 2016 10:51:25 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Kyle Rose <>
Date: Wed, 12 Oct 2016 13:51:25 -0400
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: multipart/alternative; boundary=94eb2c09743e5ba03f053eaea472
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 17:51:30 -0000

On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara <>

> > 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.)

> 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)?

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.

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.