IETF Logo Mail Archive

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

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 29 December 2015 07:15 UTC

Return-Path: <ilariliusvaara@welho.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 3EBFE1A1B95 for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 23:15:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, T_RP_MATCHES_RCVD=-0.01] 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 BrCNegk-si-V for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 23:15:09 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 10D9E1A1B92 for <tls@ietf.org>; Mon, 28 Dec 2015 23:15:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 367D8D2; Tue, 29 Dec 2015 09:15:08 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id dnGKyiT68hpt; Tue, 29 Dec 2015 09:15:08 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id E7FBD138; Tue, 29 Dec 2015 09:15:07 +0200 (EET)
Date: Tue, 29 Dec 2015 09:15:07 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20151229071507.GA21772@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> <CABcZeBNDeBteWOpqyYH=CVrOWqQ-j1=3X5p-wzd=ZBj+JAAnng@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBNDeBteWOpqyYH=CVrOWqQ-j1=3X5p-wzd=ZBj+JAAnng@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/7oTp7kY7oma5ytumehM5F6OjlQk>
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 07:15:10 -0000

On Mon, Dec 28, 2015 at 06:59:48PM -0500, Eric Rescorla wrote:
> On Mon, Dec 28, 2015 at 4:49 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> >
> > 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.

Basically, the server should avoid keeping any state for what it is
going to reject (because keeping such state would be pretty major
DoS vector).

And no state means no fragment reassembly and only first fragment being
parseable. And it is not only Cookie that can generate rejects, but
also KeyShare.


-Ilari

v2.23.0 | Report a Bug | By Email