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

MikkelFJ <> Fri, 14 June 2019 10:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F2B91201F0 for <>; Fri, 14 Jun 2019 03:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.605
X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cJ30We44IKBV for <>; Fri, 14 Jun 2019 03:13:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBFD8120180 for <>; Fri, 14 Jun 2019 03:13:03 -0700 (PDT)
Date: Fri, 14 Jun 2019 03:13:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560507182; bh=NdZYh+02TD976qnowRmNENwJ+5h01alEJsnbF+xnCU0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PlSw8JNGWoJDYbQ9B64eGRHqPz923nxJpbznRB8ky8/MIToUgn0eLZpVCGmx3POdR 8KWUzw1Cz5NY1k2Nvj/754INw32Nsq1goa227miCMTiTmnbf5EBzct2Il78L249fQC zAludbpMrNpWqJagy1ygubigwRA1sSiP7CWug+98=
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2792/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Timing side-channel on key updates (#2792)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d03732e7a5ea_e473f9042acd96c2481d7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Jun 2019 10:13:05 -0000

> I agree, there's not really a need to do key updates that frequently. However, I like the fact that we're currently defining a clear rule: An endpoint is allowed to update to N+1 as soon as it has received an acknowledgement for a packet sent at key phase N.

Perhaps we should state that an endpoint should precompute the key early but not update keys too frequently to prevent timing attacks and overhead.

> An endpoint that wants to ensure that no packets are dropped due to the unavailability of keys would have no choice but to wait >> 3 PTO. 

That is not necessarily a bad thing, but it is unfortunate that there is no clear definition. We could also say the idle timeout period.

As long as we compute keys using SHA256 it might not be a concern, but computing keys too frequently could exhaust safety parameters on other potentially faster algorithms.

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