Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?

Eric Rescorla <> Tue, 29 December 2015 00:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A7F401ACDFD for <>; Mon, 28 Dec 2015 16:00:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2YOrVWq8N4gm for <>; Mon, 28 Dec 2015 16:00:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70CA71ACDFB for <>; Mon, 28 Dec 2015 16:00:28 -0800 (PST)
Received: by with SMTP id k129so94438969yke.0 for <>; Mon, 28 Dec 2015 16:00:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jgOicE2WX/w+Me1lAPah/W3LmhQ9xbfoEoOJEH35kH8=; b=K3hsCXVywPeuCzBCHICTXhL6fvKOMnaiK3AG+FGPlyjm0H+7QBFcnSrPjJVMjcZuSi Ch55j10Fh0Vu8VafKFCMFZHzD+TA9RQkxeDwW34O25Nl3VhrP1DtZzUpDqwyyX4bX9Yx ksS4J7eMvOYAKHgxPPtTTp/fLR6F4E3joWZURB/NKZ4hRNA0Mw/BeQhnIwKv9J49A0L9 NQelpEOC7fkAKgY1YKEvzQEFMaChqmy6m4wUijT6GoM5tqJIvSUezCTChP4huR9ycyXg c8k9Rs5Nn4ObLbXayLSh7ur2N8Y9+Y8H1yxz+yrcbX0YkDvBGEOEKaZy5ZsRTanRrfYK iFSA==
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:content-type; bh=jgOicE2WX/w+Me1lAPah/W3LmhQ9xbfoEoOJEH35kH8=; b=L8kXholBl+wCUCsOnniPIr/phdjbBZPrgn5ruoenkLSxwUqKBLIZmJ2qhth9JBy30N FmMkP/hZ0/Ft35hH6PH9ORcy+yk3oOJD4xv0qAzr3SmpvOOwgCu1fTMP24wDDNR4l7h5 amcP9Ta6dpAUHzWcQDTUQDCOHsXjAUigKXgp/7wiZMcTmrfVjhyQjsmSY2EtyyfWObUA TKKXhm68+yPy1on6Z3U93lm+8bUgT7RNLsXe65fyhCSruOEFqHLwamsbD1iU/+eAFJvW t8P1WGM7f32Qv3naxGsus4bhT8ht9DSVNPCvoplGAx4AQbRXudL6Nnwr0yzXdrxEShwN mlig==
X-Gm-Message-State: ALoCoQntnICQlXnLtJmNCLZ7g6XOtdruNK4eMgQLRy7zuyiLAu2F7vRceM0XVA3JfL5mjOpTLdueujQEvrE8dWf1+8VTOt6k2g==
X-Received: by with SMTP id l3mr42451962ywg.155.1451347227657; Mon, 28 Dec 2015 16:00:27 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 28 Dec 2015 15:59:48 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 28 Dec 2015 18:59:48 -0500
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: multipart/alternative; boundary=94eb2c07c8bcf379e00527fe1b30
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
X-Mailman-Version: 2.1.15
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, 29 Dec 2015 00:00:30 -0000

On Mon, Dec 28, 2015 at 4:49 PM, Ilari Liusvaara <>

> On Mon, Dec 28, 2015 at 06:46:02AM -0500, Eric Rescorla wrote:
> > On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema <
> > wrote:
> >
> > > For DTLS, we have to consider the packet injection threat. It is fairly
> > > easy to send some random bytes with a fake source to a UDP destination.
> > > Such attacks should not cause the DTLS association to fail! The normal
> > > behavior ought to be to just ignore UDP packets that fail to decrypt.
> This
> > > would cause 0-RTT rejects to just result in dropped packets. Can we
> ensure
> > > that the handshake protocol is robust against that?
> > >
> >
> > We obviously need to distinguish here between handshake and application
> > data messages, because DTLS is intended to allow loss of application data
> > messages.
> >
> > WRT handshake messages, as I indicated before, I believe that there is
> > enough information in the handshake messages to prevent removal.
> > Namely:
> >
> > 1. The ClientHello contains an indication that 0-RTT handshake messages
> > are coming.
> > 2. The Client's 0-RTT Finished contains a MAC of all the Client's
> > 0-RTT messages.
> > 3. The Server's Finished contains a MAC of the ClientHello.
> >
> > Thus, provided that the client and server in fact share a configuration
> > (which, again, is in the ClientHello) then the server knows at the time
> > of receiving the first-flight Finished that he has (or has not) received
> > all the client's 0-RTT Handshake messages. [0].
> Also, maybe a stupid question:
> While the 0-RTT handshake parts are obviously reliably transmitted, is
> the same true for the 0-RTT data part?

No, nor for any DTLS data. The assumption is that this is handled at the
layer above.

That is, is the server allowed to ACK the flight after having received
> ClientHello/Certificate/CertificateVerify/Finished; and deal with any
> 0-RTT data messages should they arrive (these are not necressarily
> retransmitted if lost)?

I would anticipate that this is the correct behavior and in fact this seems
like the right behavior for TLS as well, since part of the point of 0-RTT
data is to stream it ASAP. Note that there is no explicit ACK, though.

Or if the context does not support early auth, just ACK immediately
> after ClientHello.

Yes, this is currently technicaly possible.

It occurs to me that data messages in DTLS 1.2 lack the fields needed
> for automatic retransmission.
> > The more interesting question, however, is what drives the DTLS state
> > machine forward to ensure progress in the face of innocuous loss.
> > The basic DTLS design is that the receipt of the first message of the
> > peer's next flight indicates receipt of the entire flight. In this case,
> > then, the receipt of the ServerHello would indicate receipt of the
> > Client's 0-RTT Finished. However, this would place a requirement
> > that the server not *send* the ServerHello until that point, which we've
> > left open in WIP-11 by not hashing in the 0-RTT plaintext.
> I think that would be fairly easy way to deal with it (not saying that
> simpler ways don't exist).
> Also, on topic of DTLS 1.3... It occurs to me that naively doing it
> would leave it open to "fragementation attacks" a'la IPv6.
> Basically, it occurs to me that ClientHello messages SHOULD NOT be
> fragmented (at TLS level, SCTP(?) or IP level fragmentation is another
> kettle of fish) and if it is fragmented, the Cookie extension MUST be
> in the first fragment.

Sorry, I'm not sure I am processing this. Can you explain in more detail.

Also, there's question of how to handle HelloVerifyReqest (one can't
> just downgrade to DTLS 1.2!). One way:
> - If it was in reply to ClientHello with EarlyData extension (at least
>   with early auth?), treat it as fatal protocol_version Alert. TLS 1.2
>   can't handle early data.
> - If it was in reply to ClientHello without EarlyData extension, write
>   the cookie into the header cookie field (not extension cookie field)
>   and resend. This counts as a retry.

Yes, this seems like the right answer. I.e., You only do HVR in TLS 1.2
and as we have discussed previously, once you have sent a ServerConfig,
you have to continue to be able to do TLS 1.3, even if you forget the