Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379)

Eric Rescorla <ekr@rtfm.com> Sat, 19 December 2015 00:50 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 E69051A0178 for <tls@ietfa.amsl.com>; Fri, 18 Dec 2015 16:50:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 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] 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 QmA0IVraTE_N for <tls@ietfa.amsl.com>; Fri, 18 Dec 2015 16:50:24 -0800 (PST)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 2D41F1A0174 for <tls@ietf.org>; Fri, 18 Dec 2015 16:50:24 -0800 (PST)
Received: by mail-yk0-x235.google.com with SMTP id v6so77427710ykc.2 for <tls@ietf.org>; Fri, 18 Dec 2015 16:50:24 -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=NRU9zWaiQ9EoCJTvuopq8XCiIptgNsUC4B/51l5ESCU=; b=aeHLzAeBALvi6Wt5rwLmJHDBVQ7YzcT2wnuGSibkcd/aJKh1/HGbYqne+J1zL2OO37 Mk/id9CqxGjwUi+IIvNKtwqRCBwkMa3YhETSTlWme5gJczLtH5uu1T0OJZGoeVZmuGvm yMq0w3eqSzh7NiKaka2eH66TpwLEUt0hXns9eoJQFvGTDGsyi2OCtcEayC0OpKVPIaC1 CiqXAr6prI22aAYu4FtTO9DjmgeoefpKuhbqZDXeI0huCLpOPJFPYd6HGnotegZzDppJ 8g/KYCu9xhcmmHnK8D+B4SRSKvPMDhsAsFXZaWISenVH2mQLDeAGkFgPSN4xwrBgFSQo u8Dg==
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=NRU9zWaiQ9EoCJTvuopq8XCiIptgNsUC4B/51l5ESCU=; b=mj+f66j5kqU8Lu+opfYbOFF4RqnRPkEzs5F9dLvpxVzpi80pRTW1NHBi6IwO1ZimF0 3TOb+4JSu4wLoRVpGjPkn+1IJrxDMyPa7Y04ht8GjVM9ATmMPZdF8YP+Ik63XC8by29X 2hMjXQnlr+73oFFI0lPfHYxjJywEBlQC+Sfp3MDSVUXayLfH4ErdgWUgNw+bx56XV3tC XiRH59TpqGylq97+IQHNX5nGStgSQlecrdOBlD19KYRUMzaKstbGICjCmykLww7IASqk l1ly4PTt0JlaYptwiZ0kyhwBhVjXHBBpsUA0TevKJT1JiHRAOVcR3GvC9Nkly4u+mjJp k8uA==
X-Gm-Message-State: ALoCoQmc2oTcZ0X1yDzBm98uUQ7hsLKUGamrVD9eCAXmAEclgUIWuO6HZf4wubw01g1IaNYw1NkiEdOkdco4FGAR6LzRhJgQMQ==
X-Received: by 10.129.153.3 with SMTP id q3mr6210227ywg.231.1450486223504; Fri, 18 Dec 2015 16:50:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Fri, 18 Dec 2015 16:49:44 -0800 (PST)
In-Reply-To: <7327a9142c2c41f39028d8882be8ae45@AM3PR30MB049.064d.mgd.msft.net>
References: <5e85e3b1a1914ea8bbd5d985c321c119@AM3PR30MB049.064d.mgd.msft.net> <CABkgnnW4xWKZZKh-3-Qqat6zVKTveLW1ZGP47bHZioJ2j-eLYg@mail.gmail.com> <7327a9142c2c41f39028d8882be8ae45@AM3PR30MB049.064d.mgd.msft.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 18 Dec 2015 16:49:44 -0800
Message-ID: <CABcZeBMnbvGPHF7AEwUdtrb89_7iPk3-hQKh99jM08=fcFhD4g@mail.gmail.com>
To: Cedric Fournet <fournet@microsoft.com>
Content-Type: multipart/alternative; boundary="94eb2c0bbfae1abaed052735a4f5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/fbFNn-723NBGrdTsV00JUx3ZdJE>
Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379)
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: Sat, 19 Dec 2015 00:50:26 -0000

Does anyone object to this change? If not, I intend to merge it in this
weekend.

-Ekr


On Fri, Dec 18, 2015 at 7:47 AM, Cedric Fournet <fournet@microsoft.com>
wrote:

> The surprise is that breaking one key also yields the ability to truncate
> traffic protected with another key. We agree that we don't have any
> particularly scary way to exploit it against the current draft, but we'd
> much prefer handshake encryption not to depend on 0RTT, and application
> data protection not to depend on handshake encryption.
>
> With our proposed change, the main point to keep in mind is that, by
> design, the TLS 1.3 record layer does not prevent suffix truncations.
> Instead, TLS prevents prefix truncations at the protocol layer, by sending
> an unambiguous final message with each record key:  end_of_early_data;
> finished; and close_notify.
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: 17 December 2015 23:39
> To: Cedric Fournet <fournet@microsoft.com>
> Cc: tls@ietf.org; Antoine Delignat-Lavaud <antdl@microsoft.com>;
> Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
> Subject: Re: [TLS] [tls13-spec] resetting the sequence number to zero for
> each record key. (#379)
>
> So the actual impact here is that an attacker who has compromised a key
> can introduce a gap.  Aren't there other options available to such an
> attacker?  Scarier options?
>
> On 18 December 2015 at 07:01, Cedric Fournet <fournet@microsoft.com>
> wrote:
> >
> > We propose to revert this change (that is, to reset the sequence
> > number each time a new key is installed, as in TLS 1.2). If the
> > chaining is still required for some other reason, one could instead
> > include the old sequence number in the new key derivation (or the new
> > key's additional data, but we believe this is no longer an option).
>
> Even with my question above, this seems reasonable to me.  I'll note that
> chaining in the way you describe would require that the rekey message (the
> last message of the previous epoch) would need to be retransmitted in
> DTLS.  That seems more brittle, but we probably want to retransmit anyway,
> since that would let use remove the explicit epoch from DTLS packets.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>