Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2Requirements to IETF QUIC Working Group"

Lars Eggert <lars@eggert.org> Wed, 30 September 2020 11:43 UTC

Return-Path: <lars@eggert.org>
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 AA99A3A0CA9 for <quic@ietfa.amsl.com>; Wed, 30 Sep 2020 04:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 Lgo0iq67ms1z for <quic@ietfa.amsl.com>; Wed, 30 Sep 2020 04:43:38 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 83B503A0CA2 for <quic@ietf.org>; Wed, 30 Sep 2020 04:43:38 -0700 (PDT)
Received: from [IPv6:2a00:ac00:4000:400:64e8:8d4c:6d6a:9695] (unknown [IPv6:2a00:ac00:4000:400:64e8:8d4c:6d6a:9695]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 79EA6616F56; Wed, 30 Sep 2020 14:43:21 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1601466201; bh=B/eKIC0p0JPldetKC6S2/e+WMKI9Y+V3buGLtLfKIGM=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=kYmZOG2xU2ewPEQ0gThHoY2uMAezgnDzVqc3mG/mdsadfT1NGxMMBxV7Kj1UbovcC YlQZJ6zvddTuneumwDfzBMt5Vqe5/BP31AWNftpfBbdakB3OYMjR/uIEGiS50TdeKO 7y859d0eC/NTv/v5T2RpKXXHfSbmAFLEixwpHCAY=
From: Lars Eggert <lars@eggert.org>
Message-Id: <93FE3EEB-E6DB-4505-B815-83E235D11444@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_47D5D71D-BF75-44FE-9505-1B759E7C95E6"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2Requirements to IETF QUIC Working Group"
Date: Wed, 30 Sep 2020 14:43:19 +0300
In-Reply-To: <HE1PR07MB3386DE73EC3FB7D555A81A6F9B330@HE1PR07MB3386.eurprd07.prod.outlook.com>
Cc: QUIC WG <quic@ietf.org>
To: "Flinck, Hannu (Nokia - FI/Espoo)" <hannu.flinck@nokia-bell-labs.com>
References: <5530E619-F6A8-4ECA-A9E9-3DE4B5DECA97@eggert.org> <HE1PR07MB3386DE73EC3FB7D555A81A6F9B330@HE1PR07MB3386.eurprd07.prod.outlook.com>
X-MailScanner-ID: 79EA6616F56.A07F4
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/YNf-YPJBdcKNIYGrgzFHJIMU9EY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 30 Sep 2020 11:43:40 -0000

Hi,

On 2020-9-30, at 14:27, Flinck, Hannu (Nokia - FI/Espoo) <hannu.flinck@nokia-bell-labs.com> wrote:
> It seems to me that the response to Qn-2 is a too categorial.

how so? An unencrypted QUIC variant is obviously out-of-charter.

> Also the question Qn-2 in LS is not well formulated either. What they really ask is about avoidance of avoid multiple encryption layers that occur in QUIC in QUIC tunneling. The motivation for their question is also mentioned in the ATSSS-draft. And maybe the question should be answered by MASQUE WG instead.

Well, they asked us, so we are answering. And even when QUIC is tunneled in QUIC, we are not chartered to standardize a method to disable encryption for one of those QUICs.

Thanks,
Lars