[quicwg/base-drafts] Timing side-channel on key updates (#2792)

Marten Seemann <notifications@github.com> Fri, 14 June 2019 07:18 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3CEC71201AF for <quic-issues@ietfa.amsl.com>; Fri, 14 Jun 2019 00:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zb9fReG3ku2G for <quic-issues@ietfa.amsl.com>; Fri, 14 Jun 2019 00:18:37 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 802D0120071 for <quic-issues@ietf.org>; Fri, 14 Jun 2019 00:18:37 -0700 (PDT)
Date: Fri, 14 Jun 2019 00:18:35 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1560496715; bh=4IU7kx0w9sIQ2raasCjXEUrbU0mK8cB28g4n1QxZ5Wg=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=168cqzCT0u7j/yK+pzEtje72TEp7R8VUEegv+kOIS511bMCSBzUpj7vOVs8UqJUAq CkyPhWh6x1lKuMMBKPReSZix8Oh/551K6Qt1KTSV4wxA/WkeO3odaWqgLrZ40VnQBs HzAcnzXtJrTG2kqS7c6getu3xOEPhvuzMKxHXb54=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2QWMMHSRNTTKIJ3EV3CB6MXEVBNHHBWL37RY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2792@github.com>
Subject: [quicwg/base-drafts] Timing side-channel on key updates (#2792)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d034a4badefe_2c3a3fde58ecd9684804d9"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/86UbrOYFwjW72GfggMMllE8n1t0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jun 2019 07:18:40 -0000

When receiving a packet with an unexpected key phase, an implementation should compute the new keys:
> A receiving endpoint detects an update when the KEY_PHASE bit does not match what it is expecting. It creates a new secret [...] and the corresponding read key and IV using the KDF function provided by TLS.

This creates a timing side-channel, since an attacker can modify the KEY_PHASE bit, thereby making a peer compute the next key generation. The packet will be discarded, since the header is protected by the AEAD, but the fact that the key is computed on receipt of that packet is a side-channel that might be used to recover the header protection key.

The way to avoid this side-channel is to pre-compute the N+1 key when rolling over keys from key phase N-1 to N. An implementation would then use the N+1 keys when receiving a packet with an unexpected KEY_PHASE, in exactly the same way it would do decryption on a packet sent at key phase N.

This however contradicts the text that claims that an implementation may choose to only keep two read keys at any given moment:
> Endpoints MAY limit the number of keys they retain to two sets for removing packet protection and one set for protecting packets. Older keys can be discarded.

Directly after a key update, an implementation would have to store (at least) 3 key generations: N-1 for a duration of 3 PTO, in order to be able to decrypt delayed / reordered packets, N, as well as the precomputed N+1 to avoid the timing side-channel described above.

I don't think that storing 3 keys is a problem (I think @kazuho disagrees, I'll let him explain his reasoning himself), but the spec shouldn't pretend that it's possible to create an implementation that both isn't vulnerable to the timing side-channel and at the same time gracefully handles moderate amounts of reordering around a key update.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: