Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging

"Lubashev, Igor" <> Wed, 16 October 2019 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56F47120989 for <>; Wed, 16 Oct 2019 12:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 JHURvWfly-sg for <>; Wed, 16 Oct 2019 12:01:41 -0700 (PDT)
Received: from ( [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 565E112098D for <>; Wed, 16 Oct 2019 12:01:41 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x9GIqQ5r025472; Wed, 16 Oct 2019 20:01:32 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=znEVxbt5UtG9lLFPI8EMLodjnVL717hGL49l884PcrA=; b=gKxkRuVFxv76y4hAxCFCDyNDUuXP0GyxIo3ohwFgGyij8HGrxr2syZf1BijTyTKw5vY1 /SMiK7zM8U/0QKJVuaFpntJb5Aq/VVhUtvgSpGlL1SHXqUMzOhh7s7i46zQpvleptxAH rnAowVra9ZYEfLlH0vdvjdIiwe1UOUzfEEfbPaLJPnLWyLggB6JYqEjeBgymYqdLFpyN UYZM+k9qwVPtyrP7ievEMRvH668NFk05wIL2Twpzr42EFwRqeLw5SxMILUoUl8Bn5nAA OK5nA3NiNZgQxlsQNSQY/SAoJ3A9YoUGCHt+A6cU2+SKR6PiDDe3YhYkLFBSq2pleWsa YA==
Received: from prod-mail-ppoint8 ( [] (may be forged)) by with ESMTP id 2vnp4rcm0e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Oct 2019 20:01:32 +0100
Received: from pps.filterd ( []) by ( with SMTP id x9GIlPOt014570; Wed, 16 Oct 2019 15:01:31 -0400
Received: from ([]) by with ESMTP id 2vka5x31wr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 16 Oct 2019 15:01:29 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 14:01:28 -0500
Received: from ([]) by ([]) with mapi id 15.00.1473.005; Wed, 16 Oct 2019 12:01:28 -0700
From: "Lubashev, Igor" <>
To: Tom Herbert <>
CC: Joe Touch <>, "" <>, Christian Huitema <>, "" <>
Thread-Topic: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging
Thread-Index: AQHVgNGd1G79uAZ3RkSVWxP1abPriadYaQ2AgAOut+CAANi+AIAAqODQ
Date: Wed, 16 Oct 2019 19:01:28 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-16_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=976 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910160153
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-16_07:2019-10-16,2019-10-16 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 adultscore=0 impostorscore=0 clxscore=1015 spamscore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 bulkscore=0 mlxlogscore=966 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910160154
Archived-At: <>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Oct 2019 19:01:56 -0000

> On Tue, Oct 15, 2019 at 9:10 PM Tom Herbert <> wrote:
> On Tue, Oct 15, 2019 at 2:11 PM Lubashev, Igor <>
> wrote:
> >
> > Most users would likely say that they want Internet that is as fast as
> possible (low latency/high throughput), very reliable, secure (passwords and
> emails are safe from peeping toms) and reasonably private. Different people
> will make different trade-offs between the above, especially about the
> degree of privacy vs performance and reliability.
> >
> Sure, but who are the "people" making the tradeoff? If the tradeoff of what
> information to expose is left up to the user then that is reasonable. But if
> network operators or IETF are arbitrarily making this tradeoff for the user
> that's a problem.

I completely agree with this.

What trade-off operators do when they block QUIC, rate limit QUIC, etc. is a different discussion.
This draft is about what trade-offs IETF is doing, when it is removing existing signals that network can use and not providing a substitute at the same time.

> As Joe stated, the only viewpoint that really matters is that
> of the user; their needs and wishes come first. So if a user wants strong
> security and privacy, then that's their prerogative-- in no way should they be
> penalized for that.

Yes.  And if the user believes that signals to the network are not desirable for their preferred level of privacy, they should be able to instruct their client to not send those signals. Moreover, IETF should ensure that their choice is harder for the network to discriminate against; hence the requirement that endpoints that do send these signals send them for no more than 80% of the connections.


> So the open question still seems to be what is the path
> forward to allow strong user privacy and yet give the network the necessary
> visibility above the network layer in a secure and robust fashion.

I think you have a preferred approach, and I completely agree with it -- encrypt transport header and send explicit network signals.  I see this draft to be about the consequences of doing the former without the latter.  And the tussle is about an argument that any extra signal might weaken privacy.


> > I think it is unfortunate that security is even mentioned in this draft. Header
> encryption is not about security; it is about privacy and protocol ossification
> resistance.
> >
> From draft-ietf-quic-transport-23:
> "QUIC authenticates all of its headers and encrypts most of the data it
> exchanges, including its signaling, to avoid incurring a dependency on
> middleboxes."
> In other words to prevent middleboxes from ossifying the QUIC protocol.

Right, a trade-off between protocol ossification and network performance/reliability is an IETF concern in its entirety, and it should be a subject for IETF debate what the trade-off should be.

Privacy is also mentioned often here, since some signals may help correlate connections. This would be a user concern (as we discussed above).

- Igor