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 66321130FAE
 for <quic-issues@ietfa.amsl.com>; Thu,  3 Jan 2019 23:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level: 
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001,
 MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 h6-edA07IQwa for <quic-issues@ietfa.amsl.com>;
 Thu,  3 Jan 2019 23:49:09 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 5EA77130FA6
 for <quic-issues@ietf.org>; Thu,  3 Jan 2019 23:49:09 -0800 (PST)
Date: Thu, 03 Jan 2019 23:49:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
 s=pf2014; t=1546588146;
 bh=mFEu9cHLos0f42wJQPNOtPvq5P17BsKS0gHxsUN9o/c=;
 h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
 List-Archive:List-Post:List-Unsubscribe:From;
 b=IpHSXT9u6X5MqwSNgUekjREZnH973WJY8uKpHFKp6eibErGberH6VgAvSL2JthNIW
 eXC9zea9I4jHR/RU9dRy53YZHNgvfmNx48fi8YOIDHE2PNsoqEkY0G/m2+ocNtmOwo
 t6uff8gKzyTyTeob8+ovoykiXfRpFu4U6wauzfMA=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab697e8a68669fd1442b211da2c34ae01b7d14def592cf000000011846d1f292a169ce17792cde@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2253/451373046@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2253@github.com>
References: <quicwg/base-drafts/issues/2253@github.com>
Subject: Re: [quicwg/base-drafts] Consider making h3 frame types varint (#2253)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c2f0ff268b69_5ea93f9c106d45c06938be";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/CdKTRnbkRmh35kzuBasWK0ZceW4>
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: Fri, 04 Jan 2019 07:49:11 -0000


----==_mimepart_5c2f0ff268b69_5ea93f9c106d45c06938be
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

> I agree with @kazuho that exchanging H3 settings in transport parameters has appealing benefits, there is however the downside that client transport parameters are not encrypted, and this could therefore be used for fingerprinting.

I am not sure if we need to care about the downside, considering the fact that we are sending other parameters (including the transport-level transport parameters) in clear. If we do care, we should try protecting all of them.

> That said we may be somewhat off topic, as this issue is about 8-bit vs varint for h3 frame types. Without going into the details discussed in this thread, there seems to be interest in allowing uncoordinated extensions, and varints allow those at a very small implementation cost.

Yeah my point was that people interested in doing private experiments can always negotiate the use of the extensions for all the cases the WG decided to care about, and therefore that there is not a benefit in having varint frame types, especially assuming that sending private experimental extensions to the wild without coordination is likely to be just waste of bandwidth.

-- 
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/2253#issuecomment-451373046
----==_mimepart_5c2f0ff268b69_5ea93f9c106d45c06938be
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<blockquote>
<p>I agree with <a class=3D"user-mention" data-hovercard-type=3D"user" da=
ta-hovercard-url=3D"/hovercards?user_id=3D41567" data-octo-click=3D"hover=
card-link-click" data-octo-dimensions=3D"link_type:self" href=3D"https://=
github.com/kazuho">@kazuho</a> that exchanging H3 settings in transport p=
arameters has appealing benefits, there is however the downside that clie=
nt transport parameters are not encrypted, and this could therefore be us=
ed for fingerprinting.</p>
</blockquote>
<p>I am not sure if we need to care about the downside, considering the f=
act that we are sending other parameters (including the transport-level t=
ransport parameters) in clear. If we do care, we should try protecting al=
l of them.</p>
<blockquote>
<p>That said we may be somewhat off topic, as this issue is about 8-bit v=
s varint for h3 frame types. Without going into the details discussed in =
this thread, there seems to be interest in allowing uncoordinated extensi=
ons, and varints allow those at a very small implementation cost.</p>
</blockquote>
<p>Yeah my point was that people interested in doing private experiments =
can always negotiate the use of the extensions for all the cases the WG d=
ecided to care about, and therefore that there is not a benefit in having=
 varint frame types, especially assuming that sending private experimenta=
l extensions to the wild without coordination is likely to be just waste =
of bandwidth.</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/issues/2253#issuecomment-451373046">view it on GitHub</a>,=
 or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq2i2=
55YwWQZVqu-9OCPKyHnnhbiWks5u_wdygaJpZM4ZgKQr">mute the thread</a>.<img sr=
c=3D"https://github.com/notifications/beacon/AWbkq-jOIGE5StLkwfGV7ALFeG4k=
tbIhks5u_wdygaJpZM4ZgKQr.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name"=
:"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"=
quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"http=
s://github.githubassets.com/images/email/message_cards/header.png","avata=
r_image_url":"https://github.githubassets.com/images/email/message_cards/=
avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/q=
uicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@=
kazuho in #2253: \u003e I agree with @kazuho that exchanging H3 settings =
in transport parameters has appealing benefits, there is however the down=
side that client transport parameters are not encrypted, and this could t=
herefore be used for fingerprinting.\r\n\r\nI am not sure if we need to c=
are about the downside, considering the fact that we are sending other pa=
rameters (including the transport-level transport parameters) in clear. I=
f we do care, we should try protecting all of them.\r\n\r\n\u003e That sa=
id we may be somewhat off topic, as this issue is about 8-bit vs varint f=
or h3 frame types. Without going into the details discussed in this threa=
d, there seems to be interest in allowing uncoordinated extensions, and v=
arints allow those at a very small implementation cost.\r\n\r\nYeah my po=
int was that people interested in doing private experiments can always ne=
gotiate the use of the extensions for all the cases the WG decided to car=
e about, and therefore that there is not a benefit in having varint frame=
 types, especially assuming that sending private experimental extensions =
to the wild without coordination is likely to be just waste of bandwidth.=
"}],"action":{"name":"View Issue","url":"https://github.com/quicwg/base-d=
rafts/issues/2253#issuecomment-451373046"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/2253#issuecomment=
-451373046",
"url": "https://github.com/quicwg/base-drafts/issues/2253#issuecomment-45=
1373046",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5c2f0ff268b69_5ea93f9c106d45c06938be--

