IETF Logo Mail Archive

Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)

Kazuho Oku <kazuhooku@gmail.com> Thu, 05 April 2018 17:18 UTC

Return-Path: <kazuhooku@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F2212DA28 for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 10:18:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Lfvr9TYcpnVF for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 10:18:55 -0700 (PDT)
Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0D11271DF for <quic@ietf.org>; Thu, 5 Apr 2018 10:18:55 -0700 (PDT)
Received: by mail-pl0-x234.google.com with SMTP id a39-v6so748953pla.10 for <quic@ietf.org>; Thu, 05 Apr 2018 10:18:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t3Ivv2paA3FtJoxmsHqRGxz+T4wYg+UjZhvsBIth0Wo=; b=ODX3K/CbLMD7r4Uhubvr5t4kNqiCvNyP2xp3/c8pEtcmufFLWrQAwzILCMrIiIkJuz hVQZWDvKAuX8BEQj41monOEpbR8+DIPQ4icbwIGbrbr05DTIEVfoOt1sqCTIkWcWQJeh L+64NyVow+cw2bKUrwKXPCkb8Eu4NFiWKp+BOkcfR8rlakYI/gIG8BXMEfOIREP+U0v1 +VpGTjF8wZHtB7IGFIUOAcgESpJdQGa7ZSpSHQGri96aevtnb3jv3b2Q+/8K8Pi1OyTt bygeTfJB6nUhMoNuOEK/RKs49Wufqe/1vhlWlPPI2Zla/mKsQRzC2psE4QH30Jytxo4n I8Jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t3Ivv2paA3FtJoxmsHqRGxz+T4wYg+UjZhvsBIth0Wo=; b=rUuEuqpR9/2orHEcHv229mbq+0o9I/PaP+ZarEr5DlLDivBDlpXw176WuBy156ixrt CHJ+FzDcMno5CbtrlXMpjoGqwzG53bneu+TKNnQOUehfxJYWzBtpYe/PmuNJmERimK3d 7p9FwgjbMt+F+EGA175XLLUDtGUf6GUdJEJlYwova3pDFauDtMLISXVvzkLbmhOXcAnI dN7VevjPS1RL/FCpk72mRSJCVf32v45AStd/0AntPi/ZZUt0AVThDH9g+iL51ndcjdMm 7XqX4FtHoi3hzupM4QpS0M4tnPWir9MZC6leXOuI3NVkn21zrCEGMfUnnmdXBxw5Bn0k rsVg==
X-Gm-Message-State: AElRT7GXod8+3UfKKAtJ3PpOfU+IlCMZdHRquFOADsP6MnrR/9A61O6W kxeKEJBynBrBwI25ImJV3POicvAFbX76UhATLL6C8Q==
X-Google-Smtp-Source: AIpwx48n+JDZz2nU4b/z55dVhXYYlpCyJFQmn0uB/yMH8kuxSGvLyUgDQz8Y2bdUPhsc/S6xIf6i1lZUuHQwaI/TpnM=
X-Received: by 2002:a17:902:8ec8:: with SMTP id x8-v6mr24262722plo.179.1522948735353; Thu, 05 Apr 2018 10:18:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 10:18:54 -0700 (PDT)
In-Reply-To: <F395D018-FFCA-405F-BBD5-1313C6F6DAF9@huitema.net>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <BBB8D1DE-25F8-4F3D-B274-C317848DE872@akamai.com> <CAN1APdd=47b2eXkvMg+Q_+P254xo4vo-Tu-YQu6XoUGMByO_eQ@mail.gmail.com> <CAKcm_gMpz4MpdmrHLtC8MvTf5uO9LjD915jM-i2LfpKY384O2w@mail.gmail.com> <HE1PR0702MB3611A67E764EE1C7D1644FAD84AD0@HE1PR0702MB3611.eurprd07.prod.outlook.com> <d8e35569-e939-4064-9ec4-2cccfba2f341@huitema.net> <CACpbDccqKoF-Y1poHMN2cLOK9GOuvtMTPsF-QEen3b30kUo9bg@mail.gmail.com> <CAKcm_gNffwpraF-H2LQBF33vUhYFx0bi_UXJ3N14k4Xj4NmWUw@mail.gmail.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <B176FC07-887D-4135-B01E-FE8B4986A5EE@mnot.net> <CAKcm_gOCeocLyrYpOS7Ud332xdz3xHSH0psPN8T6BGRjoL9ptQ@mail.gmail.com> <CY4PR21MB0630FA0EDD343396AD414641B6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <CAN1APde13JTzCvKFFvMd183Fka6QGD1kGBjsa9fcoLrYeA2hsA@mail.gmail.com> <CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <CAJGwveB=qs+J2iBQRs3d5jdGuP9yBWoAgv0t3mwD=Wrf6Q5g8g@mail.gmail.com> <F395D018-FFCA-405F-BBD5-1313C6F6DAF9@huitema.net>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 06 Apr 2018 02:18:54 +0900
Message-ID: <CANatvzy8zTFKs-c-rR0jMSHdh2HJMvZrRmcR5A+b6qNpNPzkrw@mail.gmail.com>
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)
To: Christian Huitema <huitema@huitema.net>
Cc: Frederick Kautz <fkautz@alumni.cmu.edu>, IETF QUIC WG <quic@ietf.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/H30nhLSY19aGvRMiigoJGSsHa9Y>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2018 17:18:57 -0000

2018-04-06 1:08 GMT+09:00 Christian Huitema <huitema@huitema.net>:
>
>
>> On Apr 5, 2018, at 8:58 AM, Frederick Kautz <fkautz@alumni.cmu.edu> wrote:
>>
>> Are you concerned that middleware boxes may be trained to reject migrations, thereby forcing a new connection with a visible negotiation?
>
> Yes. Hence the need to grease. For example, have clients do some gratuitous migration to a new source port number rather frequently.

I agree that it might be a good idea to grease.

OTOH I do not think that gratuitous migration would be a good solution
due to performance issues. We would be required to start from INITCWND
every time the client switches to a new address. The fact that we
cannot run two paths simultaneously in QUIC v1 makes the performance
drawback big.

Rather, I'd prefer making handshake packets indistinguishable from
short header packets. In essence, you move the flags of the long
header inside the AEAD-protected area. An endpoint that receives a
packet carrying a CID that does not belong to any known connection
trial-decrypts the packet as a initial packet and handles it as a
connection initiation, or sends a stateful reset if the
trial-decryption fails.

> -- Christian Huitema



-- 
Kazuho Oku

v2.23.0 | Report a Bug | By Email