Re: Consensus Calls for Transport/TLS issues, pre-Singapore

Mikkel Fahnøe Jørgensen <> Thu, 14 November 2019 10:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2974D120879 for <>; Thu, 14 Nov 2019 02:27:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nZe8cHN2xZCb for <>; Thu, 14 Nov 2019 02:27:34 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3AB9B120857 for <>; Thu, 14 Nov 2019 02:27:34 -0800 (PST)
Received: by with SMTP id k14so4551338eds.4 for <>; Thu, 14 Nov 2019 02:27:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=cy2Mbp7rFwj2ferR6ybafCQZLPyOT3uTbVaHJbh5A5g=; b=ZNtkZZ+gsli9NJgUUdqUCrjII12R3qeha7KtEsaRhCQimaD446qL3a62nHyKlPblUO 28An+/6UU0b/tEtYhEhcmrUJIdiTSnFv1TycNMzityc8Rm/O4WGvt3ZICyv80vEeE3nI 3sZ+9xbm1qKaxM8w/0AvDj5Gv9q2Fg2BfFND6czJKgrq80CV2f+9xcdZeM+G/d/wRuVe BVfHWN/FzMf+xXJlQ1xM0YNrilC2z3fizrSIV3Enccs2N5/m12QhBraDQ2yssfK0KjEl y2q2EpdzTlHSmojQXmePzMAZVNsW6RzqEhhT1E8eJr0K+f/Z0jl+nRSax5CHjJ2SI+YZ Mr7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=cy2Mbp7rFwj2ferR6ybafCQZLPyOT3uTbVaHJbh5A5g=; b=mQQxPfyi4gVhBteyScrGlqHwevAj/mXmB+eXcxmwn8Yj8f6wMeAOmOxljW/u0fMS8C TduFPm6VV72QpmwRohs3UM8O7cmrd2XTKoZg+P2Pq9DKjV2B9x85ikqlbAYyuBFmXYMl 0oMHym9QQGJRMozVjLDPQ7K9G6Qm3F25+yHS20lIhG9uu9vBAMq7I5h/0K8xmxNLWUff 0XQjSQtD6GPRvj8QLpH9zxzwwJwLZD+TjOOc+xBkM0feIwREDeZPpaw0lC2YI88Gj43o zKET7qXR777ZemRFnAsMdEZXDqWVfWG/MbobLjGaQ0LStxCQ+Jg4xa2ydJADTkFnmSxX 9l5w==
X-Gm-Message-State: APjAAAWEjrPk6OnAQuXfsX9A9FXT09LEmrmNVEp08JxuiomXjwUgrll7 XM9+Z42pULnOrLJ+yzraeIuYHWb/QisOn9udkoHGl7ue
X-Google-Smtp-Source: APXvYqxUcT7V7igy8kEx7gauvaMRVG+O/DAZ0ue/REGuYkIdPg8Hql5WEoA3TlEeAIDwoVsBh311o8dKESUI+a3OsMo=
X-Received: by 2002:a50:91f6:: with SMTP id h51mr273520eda.99.1573727252760; Thu, 14 Nov 2019 02:27:32 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 14 Nov 2019 11:27:32 +0100
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>
In-Reply-To: <>
References: <> <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 14 Nov 2019 11:27:32 +0100
Message-ID: <>
Subject: Re: Consensus Calls for Transport/TLS issues, pre-Singapore
To: Mark Nottingham <>, IETF QUIC WG <>
Cc: Lars Eggert <>
Content-Type: multipart/alternative; boundary="000000000000dfcf8705974bed2e"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Nov 2019 10:27:37 -0000

Kazuho pointed out that the MUST is a privacy concern for the client, so it
does make sense.

On 14 November 2019 at 09.51.12, Mikkel Fahnøe Jørgensen (

I added a comment to

 #3155: The method of identifying "the same server"

I’m not sure the MUST / SHOULD is correct in this case. Although I do agree
that server identify should not be limited to server certificates (I
proposed that myself).


On 14 November 2019 at 02.26.05, Mark Nottingham ( wrote:

The following issues have proposals for resolution, and discussion so far
seems to support consensus to accept them. If you object, please do so on
the issue or in response to this message (changing the Subject
appropriately!). Absent any pushback, we'll direct the editors to
incorporate them late next week. Note that by default we won't discuss
these issues in Singapore, unless something comes up.

See <> for the current
state of issues in the Late Stage process, itself defined at <>;.

* #3127: NEW_TOKEN and Retry tokens must be distinguishable

* #3158: Application close should be disallowed in Initial or Handshake

* #3155: The method of identifying "the same server"

* #2475: Invalid CONNECTION_CLOSE frames

* #3168: Allow servers to close connections immediately when the token is

* #3194: reordered NEW_CONNECTION_ID frames with retired sequence numbers
shouldn't be used

* #3014: Handling of corrupt Retry packets

* #3095: Backoff of CONNECTION_CLOSE needs to be a MUST

Mark Nottingham