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

Eric Rescorla <ekr@rtfm.com> Tue, 29 December 2015 00:00 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F401ACDFD for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 16:00:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YOrVWq8N4gm for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 16:00:28 -0800 (PST)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CA71ACDFB for <tls@ietf.org>; Mon, 28 Dec 2015 16:00:28 -0800 (PST)
Received: by mail-yk0-x236.google.com with SMTP id k129so94438969yke.0 for <tls@ietf.org>; Mon, 28 Dec 2015 16:00:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.129.148.3 with SMTP id l3mr42451962ywg.155.1451347227657; Mon, 28 Dec 2015 16:00:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Mon, 28 Dec 2015 15:59:48 -0800 (PST)
In-Reply-To: <20151228214915.GB5798@LK-Perkele-V2.elisa-laajakaista.fi>
References: <DM2PR0301MB06555FC15830293E0C4E381AA8E50@DM2PR0301MB0655.namprd03.prod.outlook.com> <201512241748.25385.davemgarrett@gmail.com> <CABcZeBMDXrCxjp+RtHGsxsZRGjEUJOy8BCxRLu4pMbFXkNcnEA@mail.gmail.com> <201512270208.11253.davemgarrett@gmail.com> <DM2PR0301MB06557834035ECF047BC3F88AA8FB0@DM2PR0301MB0655.namprd03.prod.outlook.com> <CABcZeBNNGn1uGRShCnNtowrieaXM6rUTky+=wq=bRGtjm660Jg@mail.gmail.com> <20151228214915.GB5798@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 28 Dec 2015 18:59:48 -0500
Message-ID: <CABcZeBNDeBteWOpqyYH=CVrOWqQ-j1=3X5p-wzd=ZBj+JAAnng@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary=94eb2c07c8bcf379e00527fe1b30
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ZnakgtIFAiTJPS6aAM96pASqFQ0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
X-BeenThere: tls@ietf.org
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." <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, 29 Dec 2015 00:00:30 -0000

On Mon, Dec 28, 2015 at 4:49 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Mon, Dec 28, 2015 at 06:46:02AM -0500, Eric Rescorla wrote:
> > On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema <
> huitema@microsoft.com>
> > 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
config.

Best,
-Ekr