Re: [quicwg/base-drafts] Handling of corrupt Retry packets (#3014)

Martin Thomson <notifications@github.com> Mon, 18 November 2019 00:03 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 0703F120232 for <quic-issues@ietfa.amsl.com>; Sun, 17 Nov 2019 16:03:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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_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] 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 2cCuGhDhsaUq for <quic-issues@ietfa.amsl.com>; Sun, 17 Nov 2019 16:03:46 -0800 (PST)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF48B12022A for <quic-issues@ietf.org>; Sun, 17 Nov 2019 16:03:46 -0800 (PST)
Received: from github-lowworker-25680bd.va3-iad.github.net (github-lowworker-25680bd.va3-iad.github.net [10.48.17.61]) by smtp.github.com (Postfix) with ESMTP id BE4C02C33DA for <quic-issues@ietf.org>; Sun, 17 Nov 2019 16:03:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1574035425; bh=NV5x7JROvjJs2D72KxPdSH8musFU2xOnbpRlkM2GtRw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gdZ7u7CGxajjQQTEyl8Iiqz7jnouFSMKYbFvYPLe8UyNjJUZMCFHEgI6mIDbUOCvg xrlOpEKFC6hOfbERLO++aQ2PwlIxdpo9j1j/fV6eMoMsVnRbeOqX2NQ8abf00B24rE c11LBLAkRTQUs5ihQvUzOLcSspq7+hyvghKm5ugA=
Date: Sun, 17 Nov 2019 16:03:45 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK546X2KEWO2FAXJCMV334JGDEVBNHHB2TYBKQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3014/554803356@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3014@github.com>
References: <quicwg/base-drafts/issues/3014@github.com>
Subject: Re: [quicwg/base-drafts] Handling of corrupt Retry packets (#3014)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dd1dfe1af7cb_b7e3f9c68acd96c110372"; 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/2WusbyrolVyQCwi3A5876E3Ydwo>
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 Nov 2019 00:03:48 -0000

Moving discussion back here to address @ekr's [request](https://github.com/quicwg/base-drafts/pull/3120#issuecomment-554271932) to encrypt the token.

Discussion thus far identified a very minor performance/value trade-off. Running AES might cost some.  This is minor, as the key is fixed and so the AES key preparation costs are erased; you might even pregenerate the fixed key stream and just run XOR.  With that realization, we observed that the value provided by encryption was equivalent to the difficulty of applying that XOR.

There is a step higher, which is to use a key derived from the connection ID, but that depends on running a KDF and setting up AES, which I think we all agreed was prohibitive.

I think that the idea of moving from a 0 key to a fixed key is easy, so we should definitely do that even if we do nothing else.

-- 
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/3014#issuecomment-554803356