Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
Hannes Tschofenig <Hannes.Tschofenig@arm.com> Mon, 16 November 2020 15:09 UTC
Return-Path: <Hannes.Tschofenig@arm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031733A113C for <tls@ietfa.amsl.com>; Mon, 16 Nov 2020 07:09:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=kRWvl1uI; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=kRWvl1uI
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 BxcjgvxvhYUU for <tls@ietfa.amsl.com>; Mon, 16 Nov 2020 07:09:46 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150082.outbound.protection.outlook.com [40.107.15.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30CDD3A113D for <tls@ietf.org>; Mon, 16 Nov 2020 07:09:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vBeNbzNcTPGYKUffZv8Dv9FE2kQ4TEavnUgS9H7BQ40=; b=kRWvl1uItBPIXyBHmBQngsGYmBTiu5pYOdST0tKUohdaA+6nIQMmjkXI9ebO2DfI5tqyKZElfs82ZqU91a4K2PDEyEFtJLiA4irVVLuURYdGeJW6fL3GBL/saX2qzlx4xZyocJoP9pnNJ+LFOKKsl5IeUXzqFZ98X4tYOfi8aQI=
Received: from DB6P18901CA0016.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::26) by VI1PR0801MB1696.eurprd08.prod.outlook.com (2603:10a6:800:51::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Mon, 16 Nov 2020 15:09:42 +0000
Received: from DB5EUR03FT027.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:16:cafe::bf) by DB6P18901CA0016.outlook.office365.com (2603:10a6:4:16::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25 via Frontend Transport; Mon, 16 Nov 2020 15:09:42 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT027.mail.protection.outlook.com (10.152.20.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.22 via Frontend Transport; Mon, 16 Nov 2020 15:09:42 +0000
Received: ("Tessian outbound 082214a64d39:v71"); Mon, 16 Nov 2020 15:09:42 +0000
X-CR-MTA-TID: 64aa7808
Received: from 70d2f0b65e00.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8E3E5E37-795B-4ECD-B211-8A13618B5F51.1; Mon, 16 Nov 2020 15:09:37 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 70d2f0b65e00.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 16 Nov 2020 15:09:37 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZhKoym8aaiW2riBOLHPoNHTWtqbSY4cIkF0/w0dK3tnYoNsjLKmL9xQIy/TiNQF8KWLaBma9bOsLhOVnVf2ww0Xy/Hn3xMKI/1xKIlHSKFYBC6bRTd6NFf+4flXLkEiYhsB6ND8/LqUa5uRf+shc3kzamWxouxEjvxOSj3wHJxT8ZXoeiaFJtcGZnJPRzD206qpC/th6E0DrkeoXdGoupJlhqxBwQQav3xMJTlVbD7tk+InHKjOGvPMnc1z0att2DKTCVyCZJqcDhMdlpAJ8BZuIhauv79sl96rOU3i9d/p18HEcueifgiCODtH3m9DuXyTCh5bCu2/Cza4PlGp6+Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vBeNbzNcTPGYKUffZv8Dv9FE2kQ4TEavnUgS9H7BQ40=; b=jHG3S0wKnuynZG8tvVev3A5Yp0JQdXW2OyE8SmOaFLvNytQBe7i2XidZ27h0xKdxR39bIkGc0/PxF2QPvjEv8nsIDVvYDHaHLhzvCAngLG7DD6sw7KhyoNDd/P/gR5DVaismlZIxeq3yGsi/ozThdzdQUtHEOxbivUmuRge77jWDNz//UvspInEea9VRTutO++CAFN2dAHy70bglVfeyp5SUgkaxxuDGiolwFBJVbqGsgC+pLw+dXnfcKq+Fq0DzQ/s9hbxmKbIRTsuiFVxAFeFQa4Kb/NLlX28IhJCcsWEw6PqA3tAPJoGQZrBEyFuB8JiUI4J15WBVhLOCMN/96Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vBeNbzNcTPGYKUffZv8Dv9FE2kQ4TEavnUgS9H7BQ40=; b=kRWvl1uItBPIXyBHmBQngsGYmBTiu5pYOdST0tKUohdaA+6nIQMmjkXI9ebO2DfI5tqyKZElfs82ZqU91a4K2PDEyEFtJLiA4irVVLuURYdGeJW6fL3GBL/saX2qzlx4xZyocJoP9pnNJ+LFOKKsl5IeUXzqFZ98X4tYOfi8aQI=
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB5524.eurprd08.prod.outlook.com (2603:10a6:208:181::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Mon, 16 Nov 2020 15:09:35 +0000
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48%7]) with mapi id 15.20.3564.028; Mon, 16 Nov 2020 15:09:35 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Eric Rescorla <ekr@rtfm.com>, Nick Harper <nharper@google.com>
CC: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] PR#28: Converting cTLS to QUIC-style varints
Thread-Index: AQHWm3iWO7+I4T966kCFF8Wkz9tC26mJydSAgAAB6gCAAAx8gIAAAnyAgAAKZACAAWbsAIA+lI4AgAEg/eA=
Date: Mon, 16 Nov 2020 15:09:35 +0000
Message-ID: <AM0PR08MB37161638A7E0B8723F783C76FAE30@AM0PR08MB3716.eurprd08.prod.outlook.com>
References: <CABcZeBPNFhGoLhgqeR9ObwyU68BYq=hXG1PhXcqNsNDNFGGyaw@mail.gmail.com> <CAOYVs2rEDtgJFVpiQkcaaYG2LAyW1hB5Cou4kUoG2_dkxMFTww@mail.gmail.com> <CABcZeBP3BUDEeiV2T-kxYTmC841XE_BrXhPHSoRqfdH0hHd-6w@mail.gmail.com> <BBA456AB-EC42-47DD-A3E3-5FC0E9E7A534@akamai.com> <CAOYVs2r+AiEs0q6sybqT2CbtLtj4KE4onr-3qjr5vZ5RFPiKOQ@mail.gmail.com> <CABcZeBNQ3tk-rGpdJ88q0oaUXXq4B7NQWKp8P8uQOyxA7Lwstg@mail.gmail.com> <CACdeXi+xOTA7m9fAQzbrDRXA+B3iwB3-0dc7K1+QVbyvaueMQg@mail.gmail.com> <CABcZeBPrtt5CNQrJfZD-3uCqG8uUe8bzzQJjwZvnz5yHh8MMDQ@mail.gmail.com>
In-Reply-To: <CABcZeBPrtt5CNQrJfZD-3uCqG8uUe8bzzQJjwZvnz5yHh8MMDQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ts-tracking-id: 2A4A1692BCC1804B99BEC11BC2454CB6.0
x-checkrecipientchecked: true
Authentication-Results-Original: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=arm.com;
x-originating-ip: [213.208.157.39]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 5bdd7e76-65d3-4ea9-cbd2-08d88a41a562
x-ms-traffictypediagnostic: AM0PR08MB5524:|VI1PR0801MB1696:
X-Microsoft-Antispam-PRVS: <VI1PR0801MB16963ED1D10D5916769B4BA6FAE30@VI1PR0801MB1696.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: ZfshJp2E++OH6nqO5R8FF3PZmLvF2iGoSER0zF9E8PBmjguTU9eJIBSf7nZa3WJGrbIr3jcTyGZDr4SPCUZCt0SvXlzfXmgyJEOy8siIGxT8S5mtmGLdIi5Pq7xdKbrmSm7XqbRNAnijK4ZWs0mOAVuPSvo0COcYF2nprNLppokm8+YTqkAonKEIdrMxKOHmFXacHU4p2O32RgOwHYubJ7oQJn55nc9kHXBdAUrMV+Olx3mFO8uT7ZS5LkRwDGaQkJI8ygYFiH0xlSWXZ1+NWW5JSQQGcuD0nfxEUDtK/uG7g5znEcZl7+a9COBKSjt+JmJTUB3DX8RfL7pZgXOe0G4Jxa2FSnta+zbBJh9su7Uy2tcTChSgxqkAHeuGhbEmQQXvGR22exU+RuMG3cIrhA==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(376002)(366004)(39860400002)(136003)(4326008)(86362001)(166002)(478600001)(53546011)(966005)(2906002)(8936002)(6506007)(5660300002)(316002)(33656002)(76116006)(66556008)(66476007)(8676002)(55016002)(186003)(7696005)(110136005)(66446008)(64756008)(52536014)(66946007)(26005)(71200400001)(83380400001)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 3fbKibYD5JKWU2fX7QOwUX1RrnH7c6jAKqGF1E+8XkmAcXy0UMYAKnCCpFocFQgAt+2tThPqhploZUenKDcb6ovdJ0rCj0BL5fA9erZpXAseEA2UQmT4HXxpdN1WkozN5QLCmFZcrNkm3lhQyLj35jCGIklbCpfm2xkUFA8NtQyxiGyO+bm2wTLCjyvhryDaO3Qicao/hxHHWeMFTXOc8j4ZUCiLI7u/fUYsb9C//D+JHaRq9NdFPK6W56dFVn2CECGxP6z5xbrHssW/U07i4qS2ozCHSvt0nwQ3+tM0XLYTRch7DGNWTNK+0dUGIoQVYuzQxdt3O4XHoJhZdzoa8794W74t/2qtbkbdi1Ba0zl/j2KzHlwlNSIsv8LzmblzltZhQq1qgFSdihyDyOk+HxP1zRaK3gIgG7S79wZoIrglbInVgNFdtfhR101FK4ln/VKm76ZJyQ+FI7C5F2mad7YrBSwNlEGhACwmVIfllGF7mGD3+/AUcl3XS2kLL+4u7/i1Dyqf2LoMBCu0NgQ+glZg0lQQsGNHO1Idt3hcgvXSdxl2e823ZjDZUSOdqpEfg0r6AU2cnw9ZcJcckUfyO0bkmdFHE1R8CLkA0xDzLe7Cdszm/FliUdW3P3cu8/ZKSdZrOnYHXkq/mtF9ZdhtOA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR08MB37161638A7E0B8723F783C76FAE30AM0PR08MB3716eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5524
Original-Authentication-Results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT027.eop-EUR03.prod.protection.outlook.com
X-MS-Office365-Filtering-Correlation-Id-Prvs: 6ee0e4a0-f058-4b2a-258e-08d88a41a110
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: fjI5RI/gHesvF+zJPQ5KBZMmRVdbxE68l2q9jjQBs5LaBJ7NkPU9n2DODHINsdlWyyB0+Y7F1jQcqqgjhxcuOTUmUXkBlhVOcskuvVmW+hfcUh997qSZpFqQ+RuQebfwb1kWpruq2zFJeID0bKIRBixRvjSMSni51gDHmf3MLk3NI7B7exMokQWCxp5exdno3/xk5fbNmcX4hr6/4X2w2b2oBDR4SSs1bn9E1sdYIwwG8zd6jI3MurOs4x7R9MLcCWnjHz7wSX+NtZE0GQcxy/XVYWyAX86qG1xBL+d7wJw/sGV3cK2z1C1ujrTlteugceoHwZyir//OC72b5hc1kWN81zwKGW+47wHuWs5gRpTaAGonsC4UkPmtzNphcFiI7rKmqC2e/hjnwrjHHd9oEJSs4NGzdZXSuC9Q+3McFeoAZwRz0giDKcEefv3AfL8nIoIGt0JVwJgcQWzLVNNt7SEORJHsIzfh5adVl6DJL8s=
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(376002)(346002)(136003)(39860400002)(46966005)(9686003)(8936002)(47076004)(52536014)(55016002)(86362001)(82740400003)(8676002)(5660300002)(356005)(316002)(4326008)(70586007)(81166007)(70206006)(83380400001)(7696005)(33964004)(110136005)(2906002)(6506007)(53546011)(166002)(33656002)(966005)(336012)(478600001)(26005)(82310400003)(186003); DIR:OUT; SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2020 15:09:42.5083 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5bdd7e76-65d3-4ea9-cbd2-08d88a41a562
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT027.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1696
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/C0sV9ySpF5TtlSV8g92_eoXJPk4>
Subject: Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 15:09:49 -0000
FWIW the current scheme described in https://tools.ietf.org/html/draft-ietf-tls-ctls-01 only offers variable length encoded integers of one to three bytes. We need more than that. I am in favor of the “deterministic” version, if deterministic means no overlaps in the encoded number ranges. Hence, I am in favor of 2 but would leave the details of how we encode it open to work in the group. There are various possible designs and none of them is rocket science. Ciao Hannes From: TLS <tls-bounces@ietf.org> On Behalf Of Eric Rescorla Sent: Sunday, November 15, 2020 9:13 PM To: Nick Harper <nharper@google.com> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] PR#28: Converting cTLS to QUIC-style varints Trying to close out this discussion, it seems to me like there are three major options: 1. The current scheme 2. The current scheme with a deterministic minimal encoding (e.g., the two byte version is offset by 127) 3. The QUIC scheme I don't think that the QUIC scheme with deterministic encoding makes sense, because the virtue of the QUIC scheme is commonality with something already defined. I'm hearing that people are not as excited about moving to QUIC as I had expected and to the best of my knowledge, there is no valid reason to encode to > 2^32-1 in TLS. I also don't think using encoding (1) but mandating minimal length makes sense, as it's just as easy to do a deterministic minimal encoding. As Christian observes it *is* significantly more painful to do (2): the conventional way to encode vectors in TLS with minimal copying is: - Mark your current place --> X - Skip forward the length of the length field --> L - Encode the value - Encode (current position - (X + L)) at X But this won't be possible in (2). As MT observes, if you think of this as a two-pass system, there is not as much of a problem here [though not necessarily no problem]. Also, if you use a separate buffer, there is no problem. As noted above by MT and others, cTLS expands the transcript and so having a deterministic compression scheme is perhaps not as important, given that decompression is deterministic, but it still seems nice to have. Given the above, I think my preference would be (1) or (2), with, I think, a slight preference for (2). -Ekr On Tue, Oct 6, 2020 at 5:33 PM Nick Harper <nharper@google.com<mailto:nharper@google.com>> wrote: I have no strong opinion on how this is formatted. I'd base my decision on what the maximum value cTLS needs to encode: If 2^22-1 is sufficient, let's keep it as is, otherwise let's change it to the QUIC format (or some other change to increase the max value). I do like that the existing scheme, compared to QUIC varints, is more efficient for values 64-127 and just as efficient for the rest. On Mon, Oct 5, 2020 at 8:09 PM Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote: I don't have a strong opinion on whether to require a minimal encoding, but if we're not going to use QUIC's encoding as-is, then I would rather stick with the existing scheme, which has twice as large a range for the 1 byte encoding and is thus more compact for a range of common cases. -Ekr On Mon, Oct 5, 2020 at 7:31 PM Marten Seemann <martenseemann@gmail.com<mailto:martenseemann@gmail.com>> wrote: In that case, why use QUIC's encoding at all? It would just put the burden on the receiver to check that the minimal encoding was used. Would it instead make more sense to modify QUIC's encoding, such that the 2-byte encoding doesn't encode the numbers from 0 to 16383, but the numbers from 64 to (16383 + 64), and equivalently for 4 and 8-byte encodings? On Tue, Oct 6, 2020 at 9:22 AM Salz, Rich <rsalz@akamai.com<mailto:rsalz@akamai.com>> wrote: Can you just say “QUIC rules but use the minimum possible length”? _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
- [TLS] PR#28: Converting cTLS to QUIC-style varints Eric Rescorla
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Marten Seemann
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Martin Thomson
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Eric Rescorla
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Eric Rescorla
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Salz, Rich
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Marten Seemann
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Eric Rescorla
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Christian Huitema
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Rob Sayre
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Hannes Tschofenig
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Martin Thomson
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Salz, Rich
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Michael D'Errico
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Michael D'Errico
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Salz, Rich
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Michael D'Errico
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Salz, Rich
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Michael D'Errico
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Christian Huitema
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Michael D'Errico
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Nick Harper
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Martin Thomson
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Nick Harper
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Christian Huitema
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Peter Gutmann
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Watson Ladd
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Michael D'Errico
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Mohit Sethi M
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Anders Rundgren
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Mohit Sethi M
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Michael D'Errico
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Eric Rescorla
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Salz, Rich
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Hannes Tschofenig
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Eric Rescorla
- Re: [TLS] PR#28: Converting cTLS to QUIC-style va… Mohit Sethi M