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

Martin Thomson <martin.thomson@gmail.com> Thu, 17 December 2015 23:39 UTC

Return-Path: <martin.thomson@gmail.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 ADF611B312D for <tls@ietfa.amsl.com>; Thu, 17 Dec 2015 15:39:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 u0MUzV1UQ30n for <tls@ietfa.amsl.com>; Thu, 17 Dec 2015 15:39:22 -0800 (PST)
Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 8D85F1B3113 for <tls@ietf.org>; Thu, 17 Dec 2015 15:39:22 -0800 (PST)
Received: by mail-io0-x241.google.com with SMTP id f127so2878124ioa.0 for <tls@ietf.org>; Thu, 17 Dec 2015 15:39:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vkDCm74rPrl35gFsUMwb/U46bowlI8WbhMVZoUSraoE=; b=ThbMNQt2xdVrbIwvENz/Qp9sVZb1QqOHNcAgFbiWYFydyWYIlhLNSm7E6Rql7p8kv4 NVGb6KG0U6aOobkVAC9O+N48KsIUIJDzF0BX5qIGw3ZYXW66RFqWnPMsXCcl6bbo9cFL ZpWfyMIRs1RjUXz+Wg78F5F4e1MBC0r6HDhCw2RrJMY9WVAS6LDTXl/3BG1wQ3MCMR2p GYeOv3gU8QeWeg7UsVzNz1pwckbUyhWDzxfF+gM4Ck9pyaVd381FCFHtRhbBgIqAGaAu TJqV9LUZY6AYBf3JJoFAiXFpaCBbflYoK8AXJvbLchNf9QIYYXKvQm+wimgaHhjf45Wg +Q4Q==
MIME-Version: 1.0
X-Received: by 10.107.33.203 with SMTP id h194mr1124755ioh.108.1450395562024; Thu, 17 Dec 2015 15:39:22 -0800 (PST)
Received: by 10.36.149.130 with HTTP; Thu, 17 Dec 2015 15:39:21 -0800 (PST)
In-Reply-To: <5e85e3b1a1914ea8bbd5d985c321c119@AM3PR30MB049.064d.mgd.msft.net>
References: <5e85e3b1a1914ea8bbd5d985c321c119@AM3PR30MB049.064d.mgd.msft.net>
Date: Fri, 18 Dec 2015 10:39:21 +1100
Message-ID: <CABkgnnW4xWKZZKh-3-Qqat6zVKTveLW1ZGP47bHZioJ2j-eLYg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Cedric Fournet <fournet@microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/6jrhnqzUdxdk-RwhzZSa8Lr44ko>
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: Thu, 17 Dec 2015 23:39:23 -0000

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.