[quicwg/base-drafts] Forgery attacks and updated keys (#3662)

Martin Thomson <notifications@github.com> Mon, 18 May 2020 02:15 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 84ACE3A07D6 for <quic-issues@ietfa.amsl.com>; Sun, 17 May 2020 19:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.475
X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=0.726, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OGQxjHAtyJvQ for <quic-issues@ietfa.amsl.com>; Sun, 17 May 2020 19:15:57 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.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 1CB1F3A07D5 for <quic-issues@ietf.org>; Sun, 17 May 2020 19:15:56 -0700 (PDT)
Received: from github-lowworker-1dbcc59.ash1-iad.github.net (github-lowworker-1dbcc59.ash1-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id CB2F552041C for <quic-issues@ietf.org>; Sun, 17 May 2020 19:15:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1589768155; bh=wsRwDVT0063DzIEuUIXufHiCS2asWHriuUi6FazBuGs=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=ajXRgoIAO4xJy8Y5t0tNKiOPYRiukRgZHwhmQirT9Cs51NtVX3arfkqePwkjIQ4lD OApSWRi27tYTge8I8EYc0gt4rg1fXUMDo+onAn9heT8BL89N3CFqSLnZ+GKCuh4c+k l8LX0368gIh5//UcHMgvd7ysguJZm64Lj8iI8Jis=
Date: Sun, 17 May 2020 19:15:55 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZIIJ7FISJ3TFVGPT54ZXINXEVBNHHCJ4SOLY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3662@github.com>
Subject: [quicwg/base-drafts] Forgery attacks and updated keys (#3662)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ec1efdbb95f5_52083feba92cd95c7251f5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/OwepeLZIJ8YKRfnW0n4jaGx7u0I>
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: Mon, 18 May 2020 02:15:59 -0000

@chris-wood pointed out to me that when you receive junk (i.e., unauthenticated) packets, the odds are that these will be distributed evenly between the "current" packet protection keys and the "next" packet protection keys, as the key phase bit will be nearly random if they are true forgeries.

The result is that an endpoint that approaches the integrity limit on key usage will update to the next packet protection keys and find that those keys will have similar amounts of authentication failures.  That might lead to needing two updates in quick succession.  That isn't fatal, but if the timing is tight, then more time might be needed for an update.

We might say that endpoints shouldn't be calculating the forgery rate and trying to delay updates as late as possible, nor should they be allowing that many forgeries without doing anything but react with key updates.  However, as a matter of good hygiene, it's worth saying something about this.

Taking this as an editorial follow-on to #3620.

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