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

Christopher Wood <notifications@github.com> Wed, 31 July 2019 02:54 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB3F12008A for <quic-issues@ietfa.amsl.com>; Tue, 30 Jul 2019 19:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROOYSf_xIIEz for <quic-issues@ietfa.amsl.com>; Tue, 30 Jul 2019 19:54:38 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC89912004A for <quic-issues@ietf.org>; Tue, 30 Jul 2019 19:54:38 -0700 (PDT)
Date: Tue, 30 Jul 2019 19:54:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1564541677; bh=I5yH3IoG5yn+gXxNXTCfXbYHHrvYL2x36OcmJ6/OeuE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=BgC73Tu4G0OHRY65XAWXmrta2Jo2MgdcJ3kzZjn0eIMsglPOpnOEDfiNrSKpvrFlf bI64MeH4w1ZTljV5oehu3tA7KSJfNUblmKyerPJkiXRl/k9F4wzRZpz2P0JLImmd49 f3uUPNgcpmVIJiDRqWxZLH6Wfc1yQ61x/rg+jo+k=
From: Christopher Wood <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK64XRBQK2K4TMZZUJ53JY2W3EVBNHHBWL37RY@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/516673024@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2792@github.com>
References: <quicwg/base-drafts/issues/2792@github.com>
Subject: Re: [quicwg/base-drafts] Timing side-channel on key updates (#2792)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d4102ed9c622_7e43fb9d1ccd95c21091a"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: chris-wood
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/ak0rdjODw6Cvkm21So498_IUfxY>
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: Wed, 31 Jul 2019 02:54:41 -0000

I'd like to second @ekr's comment at the mic. I don’t think this is an issue for which we need text. Without loss of generality, let’s assume that in the worst case an attacker learns the entire unprotected header bytes for every packet. (That is, that header protection does nothing overwhelmingly helpful.) Revisiting the header protection algorithm, it basically works as follows:

~~~
H’ = H XOR mask
     = H XOR PRP(hp_key, sample)
~~~

where H’ and H are the protected and unprotected header bytes, respectively, and sample is known to the adversary. If we assume mask is the output of a PRP, and therefore both IND-CPA secure and KPA secure, an adversary learns nothing from known plaintext and ciphertext pairs. (The typical game-based IND-CPA security definition says that an adversary with access to an oracle for encrypting any message M_i of its choice has negligible probability in selecting b, upon giving the challenger M_0 and M_1 and receiving an encryption of M_b. Recovering the header protection key would break this assumption, as it would let the adversary encrypt M_0 and M_1 -- without the oracle -- and trivially match against M_b.)

All that said, adding text describing that endpoints should precompute keys is probably fine. I’m just not sure it’s needed here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2792#issuecomment-516673024