Re: Connection IDs

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Fri, 09 March 2018 08:17 UTC

Return-Path: <mikkelfj@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 30D96129C53 for <quic@ietfa.amsl.com>; Fri, 9 Mar 2018 00:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.997 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 4JDQ53X7Bfd0 for <quic@ietfa.amsl.com>; Fri, 9 Mar 2018 00:17:31 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 4E5521201FA for <quic@ietf.org>; Fri, 9 Mar 2018 00:17:31 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id b34so2691025ioj.6 for <quic@ietf.org>; Fri, 09 Mar 2018 00:17:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=hkPlMOQ3VOMO6WAY3QmMdpV0hy1fWRWHO3sl2EvSRks=; b=i0EBQzbAPwtLJd35nPLF/j3GrDxnnX7hqU+IsfbN/E5QmLo4uQaHyL+Zj04aiLl1BE Trnp+uzzJ7A+n1F9fLLnOnr7kzrgaAk14m8tGvpuQUfUG4XdwEKk1CeKRytKAPTdYjkX d/rWdwneOTblNuB79nufHld1ppQ0SmR8I0eksIzKxp60H33pzszHyBQSYcC8qVXYEbJS 5v7eBl7vsKysTQ24Lxf787GIUIcLhY9Xhgv7XRM/XqObuqlLwCCSHbj38lCV0bkH6Pvl UDb4p15P69vTbLMkQUCsM1xrhJvvYUqt3Su0geyvleJH0dleTmmLfAAuVXnsdJF+Jl7D Y7BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=hkPlMOQ3VOMO6WAY3QmMdpV0hy1fWRWHO3sl2EvSRks=; b=GWRw3DfbckcvOriUPgp6xSN3I0u5NWE/wBu1f5P6Ml4p6ywyT9MgFQEjR9uvbQhfGW Xmfd98dyGKnfCJys/0p+YbNCGsc++BsxgRx/kc2v2xlXi9BqIh3EIW9oqDqQ3G3pFrg0 ES80NEks642Y9WzhFW+E6Ckuu+Xswt7FPYbepjnJqKwrNWtojQkqcCyofnx/5Ew85d9Z ONOBROS4yUB3JY2ZyJ9996WSWCGQZUcAnY5zMwduCYz85D9FIwPni0KJBcqcwBA2WTZK /6Sx6Vn3gnvF4JWhJeVyw2UEAypNzva6KRQKQyzefgyQ+CRulM8yMhMpV2LlktK1MFR7 Ph4w==
X-Gm-Message-State: AElRT7GVMb7yM6nSkReU+1f0p6Oufu5WOuoimzPbqBbMApJrI2llLnXr NaNwuMXpAYNu38BXW5CI/CvZT7DfwONWkqr8cJ8=
X-Google-Smtp-Source: AG47ELtzFR9ze+0lHwI3whVBNr7IuBEg/Nh1IDv15dbap5hR/Oh1DAI5Vnp66IB9bAlkyelafHYyOwg8Y+vnuOhH3E4=
X-Received: by 10.107.50.130 with SMTP id y124mr7632813ioy.165.1520583450650; Fri, 09 Mar 2018 00:17:30 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Mar 2018 00:17:29 -0800
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
In-Reply-To: <CACpbDcca3OAC2irOhLhgwHxm8hHKKg3yyn5EhsvOA0iRZc3z2w@mail.gmail.com>
References: <CABkgnnVSCnmzjWOZwQM+ctTxFXVzsVYe6Q3Zzk4yj3LNTYUtHw@mail.gmail.com> <CAOdDvNo9qmZqmEXBGM4bM6q3EO1FGuUxLSSWsVhNEYsn5u9puQ@mail.gmail.com> <CAKcm_gMR070JUegQbDw--RNr+0XYiBMwaTM3MBmqUo21u922TQ@mail.gmail.com> <CACpbDccpuNWnX=Y+gKaPxLEjUOnvu+hr9FqH+R6ZspwOfUq-qg@mail.gmail.com> <CABkgnnUPJYG-QE4qxfOd-6AoHHgxVq4K=EyRfoxkcvdDF=oaZA@mail.gmail.com> <2894BA64-BB3C-446C-91D2-6BF4A042AB44@apple.com> <CAN1APdf=+6HzfTXAjiaY1ry+6A0THB_JP+4Gc+OLQLXciVtAdg@mail.gmail.com> <CAOdDvNqXP+G-jPFJbxWDeaoKnoXck-tt6sz_n9g_EfpttvLtPQ@mail.gmail.com> <CAKcm_gOf79R-DxiG5N9Pmji8aKWoEqcek0D--yj8FJzuWYVyEg@mail.gmail.com> <29FB4FF3-54C7-47F4-B5D9-C329A5DA7902@fb.com> <CACpbDcca3OAC2irOhLhgwHxm8hHKKg3yyn5EhsvOA0iRZc3z2w@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 9 Mar 2018 00:17:29 -0800
Message-ID: <CAN1APdfk4tXjj07HObpQBZ4mtsvgKhNZgGfxoAgGXxBQHvhgog@mail.gmail.com>
Subject: Re: Connection IDs
To: Jana Iyengar <jri.ietf@gmail.com>, Subodh Iyengar <subodh@fb.com>
Cc: IETF QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>, Rui Paulo <rpaulo@apple.com>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Patrick McManus <pmcmanus@mozilla.com>
Content-Type: multipart/alternative; boundary="001a113df3526d6d4e0566f66ca3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/QqJEujWPPfeBlfFx2LC8RSOJHrY>
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: Fri, 09 Mar 2018 08:17:33 -0000

I did not mean to start a long discussion on resets here, but I created an
issue as suggested. I will note though, that asymmetric Connection ID's do
make stateless reset more vulnerable to off-path attacks, unless I am
mistaken.

https://github.com/quicwg/base-drafts/issues/1177

Mikkel

On 9 March 2018 at 03.01.12, Jana Iyengar (jri.ietf@gmail.com) wrote:

Removing stateless reset has the downside that clients will take longer to
retry potentially failed requests. However, that's not the question in this
PR, and I'd suggest opening an issue if anyone wants to discuss it.

On Thu, Mar 8, 2018 at 11:55 AM, Subodh Iyengar <subodh@fb.com>; wrote:

> I agree about keeping the conversations separate and I’m in favor of
> keeping stateless reset or some form of fast error mechanism.
>
> Subodh
>
> On Mar 8, 2018, at 10:25 AM, Ian Swett <ianswett=40google.com@dmarc.
> ietf.org> wrote:
>
> GQUIC inadvertently broke public reset(the predecessor to stateless reset)
> for a period of time and it had a very visible effect on average latency,
> so I would like to keep it.
>
> More importantly, I think we should separate the conversation about
> stateless reset from the this Connection ID one.  Those that want to keep
> stateless reset are ok with the potential reduction in effectiveness this
> change can cause and those that want to get rid of it don't care.
>
>
> On Thu, Mar 8, 2018 at 1:17 PM Patrick McManus <pmcmanus@mozilla.com>;
> wrote:
>
>>
>>
>> On Thu, Mar 8, 2018 at 1:11 PM, Mikkel Fahnøe Jørgensen <
>> mikkelfj@gmail.com>; wrote:
>>
>>>
>>> The only thing is that I am little uneasy about Stateless Reset - is it
>>> really needed?
>>>
>>>
>> I feel the same way.. let it timeout.
>>
>>