[quicwg/base-drafts] Re-visit initial keys discard (#2741)

ekr <notifications@github.com> Wed, 22 May 2019 08:29 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 20E5E1200FE for <quic-issues@ietfa.amsl.com>; Wed, 22 May 2019 01:29:02 -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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 qB3ZI1_Z7opZ for <quic-issues@ietfa.amsl.com>; Wed, 22 May 2019 01:29:00 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.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 74898120092 for <quic-issues@ietf.org>; Wed, 22 May 2019 01:29:00 -0700 (PDT)
Date: Wed, 22 May 2019 01:28:59 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1558513739; bh=I/fYCJajccjx69K0L9xUjp7s5jHoIwVGJr9eqXEb4fw=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=nctbHa14gZ2168D40rvyIH7Qt+yayL6B/DA1hpRQhmS55HaVXqdIYPGXdQwyFfji1 A5QBNpAVsyB+xpdK1rgKWzKhFm+IyMJebom9/ayWFlpnCdTT8tqG93Jh0I0IiFqOJX MIumSDftmqPRhEje03FG9/YCDprhVCqYO5KumrV4=
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2XHMPCZA3L4PM36KV26I5MXEVBNHHBVJFPLM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2741@github.com>
Subject: [quicwg/base-drafts] Re-visit initial keys discard (#2741)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ce5084b4ba2_33773fc0ef8cd9681252635"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
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/2m4CLQhQ-ukyUxGhNFbRAluukE4>
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, 22 May 2019 08:29:02 -0000

This was prematurely closed and got kicked out of the design team.

Here's my proposal for how to handle this
I propose that we apply effectively the same algorithm as elsewhere: you discard initial keys when you get an ACK for a packet that was sent with the handshake key

On the server side, this will generally be at the same time, because the server will likely bundle Initial and Handshake packets, and therefore the clients' second flight will contain the ACK for the server's first handshake packet.

On the client side, it is 1-RTT later, but for the reasons I argued in the meeting, I don't think that this changes the situation: an attacker who occupies a position between the client and the server can forge a bogus partial first server flight to the client faster than the server responds. Then, as required by the current spec language, the client will discard the Initial key and be unable to receive anything from the true server, so there is already a DoS, which is not made significantly worse by the proposal above.

As Kazuho has pointed out you can do better than this by keeping multiple candidate server flights, but that's extratextual, and would be in violation of the language you quote above. I suppose if we wanted to do better, we could require:

1. The server to drop keys when it receives a handshake ACK.
2. The client to drop keys on handshake complete

But this seems more complicated.

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