Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

Mohit Sethi M <mohit.m.sethi@ericsson.com> Tue, 17 November 2020 05:14 UTC

Return-Path: <mohit.m.sethi@ericsson.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 833AD3A0DCE for <tls@ietfa.amsl.com>; Mon, 16 Nov 2020 21:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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=ericsson.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 CoBa2ErAbD-b for <tls@ietfa.amsl.com>; Mon, 16 Nov 2020 21:14:12 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70070.outbound.protection.outlook.com [40.107.7.70]) (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 52D113A0DCC for <tls@ietf.org>; Mon, 16 Nov 2020 21:14:12 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bKNijhRZuIKjhZYg3FKJJc0QuiFqWruBkSAlszzNxPmBJSDvWU3Xu6R8OVk7qyyoGOnuyA363Vki4juocTc4GaBmOn+bykskEWS5+rgzizD9noZZtQ8CrB8HaiL1fKLlXdqgnjWWYjbjWmszlsGB6CJcIITyguWoX56sbBy8L2zOYoHiLa+C8zcqaL9jrmLFV1pqY5Qd9jqqkFtaNGUSW3Lvu8nNOER2NT1rTSqZi3XID6EHV2zEW3B9EV+xEvqHqst+4oriDBbrFm9lSD72WGmPSn8QaTrxYr1wTsuZlKCTphPFwOEPZHSK2uV3MhuR/XtvXvapxfjeaAsOTapAOA==
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=/IB9R/h6UZgaMCNyNdMhRfmEaenyuN8zuJFCZrzt7hg=; b=D56hH0pwtbxgp10hJaXiTaOTUMSOm/V6qSmrzUv9VO/Venkgyna6Zmh3VlmpV5kTUEXw0bdv+0u7WS69oTq5dsWEROnQLbqexQvYsNIzKWWuIO8G4SdXty7pzDvNIyHAG+MFVhlsUdPEF0gqEWatpx+/+pZiH02jSh/p/alrO+6WAcrM1+taNNAvqxHCJbMO1W5CyYOLXDg2l2k1dwAhhMKp7xlNpQMaRfyW877e3XWlbbkeAm/nKckGlKrMzzUVAwduDELEE8lVklz7tewWqFDivhpA57w+jxKD2CI4WlU68xzH7Hkk8mI8v+x3zDH1jdeczftCew3RmmVFgaj7Ew==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/IB9R/h6UZgaMCNyNdMhRfmEaenyuN8zuJFCZrzt7hg=; b=O9XDmMgjMknpO1bucYVbvn90stWjW9PSSQ/wA1NJSq0JBOL6ADtuf+vpPcBtss+BSNLx664ItX5goGZB2KPIcw9HRQLBwqYZED76at5im/bjeu1dWji0FLUoS22avrM6394TnwEiIH6IIeLKx0izu21dQ34xyjoPxVP988rGJvM=
Received: from HE1PR07MB3209.eurprd07.prod.outlook.com (2603:10a6:7:32::14) by HE1PR0701MB2508.eurprd07.prod.outlook.com (2603:10a6:3:72::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.16; Tue, 17 Nov 2020 05:14:09 +0000
Received: from HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::b9e1:a01b:4cfb:d82e]) by HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::b9e1:a01b:4cfb:d82e%5]) with mapi id 15.20.3589.017; Tue, 17 Nov 2020 05:14:09 +0000
From: Mohit Sethi M <mohit.m.sethi@ericsson.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: AQHWvKB5aVI1NS22a0OA6GEJUmjn9A==
Date: Tue, 17 Nov 2020 05:14:09 +0000
Message-ID: <abd0d806-805c-9828-5131-2bdf0042666e@ericsson.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:
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [2001:14bb:150:569:3e8c:ae9:d0ae:34c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5ddb33c2-51da-4a52-331c-08d88ab79d51
x-ms-traffictypediagnostic: HE1PR0701MB2508:
x-microsoft-antispam-prvs: <HE1PR0701MB2508F571824A258B272FD2C3D0E20@HE1PR0701MB2508.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /pCva3w7+qXyunROLoZzan9SCzu4T/pwkEtJQaEMHHw5INsrq+VDof6jTHz182iW1o4+DVHL02QMtqIoSixFv/ETWgQqh4mLxW8FsmqqAldqf2gKdYB4pVIh1ZxeeBbaNs2vgsmz5mwBLynYf7ADafZpUrMZNaPBOfSjpHCzrBvqujRlfzTAmK0xxDqGVklzXd1Hyo6IK5huxBUw5bPqz4tC2Yf8xPUJ3URmsb0r6k28IIb3/XP7kowtzvxNKn/2MavLKl/wM4sL2ssYDVPGLt9Tkk2Tjs1gQlN47VUESBAN7JZMZ6sr10BCuM04IHRD/7NFX5XP5by+RCXQYFIKucDMK2Ld3TLBMxcSGPhkzie+In8TfFkmlbzouPS3nYPasKxVb86L+XJraNEAnSD5YlUuVyucGJzCUzbykbShEgboaBgAQsjcUFB3ShTXJRvILQKSgHsqGC8qhACM1bJeYw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3209.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(396003)(346002)(136003)(366004)(8676002)(186003)(2616005)(8936002)(66556008)(6512007)(4326008)(76116006)(110136005)(5660300002)(316002)(31696002)(36756003)(166002)(66946007)(66446008)(66476007)(86362001)(64756008)(2906002)(71200400001)(966005)(6506007)(478600001)(83380400001)(31686004)(53546011)(6486002)(43740500002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?cms0QWdrS0MxQmxqLzBjUllvVzc5aHNDYjV5L2RIdGVRenBUMmF3TEZ4NitD?= =?utf-8?B?YlNtaTA2RWxvYnQxV0VmcXJjNEhZY1pFMGpYNHJyK05jcmRRNDh4VW1od0wy?= =?utf-8?B?SUFRclduV3g5dTd1T1owSFlUYm5sTjdDWGdEck9mekJkdTlaUXJDaTV5RVRQ?= =?utf-8?B?dncrWG1uenZndXFsM0NCOHlVTGxibVFkVkFMODVwZXZ6d3J2azBTUGthbE5Y?= =?utf-8?B?eDFUOWdhbkZ1Nk5HSDRvdFEwWUlGdURsaDZkWlVNcGx1bytrQXdXY2p0TDRq?= =?utf-8?B?TUphcWp1b0lSdmt5ekN1SXUxNlpiMm1nckU2SjlrTDA4WC9nRjRMckdvRVhl?= =?utf-8?B?eDFNWkZONmRiSXd6MlNQbnlXekpkQitpRW5Zc2UrUm1SMHdkMHNnR2ZiTkp3?= =?utf-8?B?U1BtczJCWDZkNEZ6c3FlZ1dqQXVWYytjUkkvRXo3UzVWR0JsRTdCS0lzVkpH?= =?utf-8?B?d1pUdG05UVdheGErZGRFMWEzdFZnZTFVVjJYUzZvNEZrR3VnRnV5NWd1SDk3?= =?utf-8?B?ZzRaQjZkV2EwZGlPYk1TbUhYNEptMXZ2aW9TOUQ1Z09IRk1zYjF5S0EzVnlP?= =?utf-8?B?WHpZMS9zOWV0elpqR3hMcEp5YzhWN1MyRGRjaTRMdFZTZm05V1ZsdFY4dDdJ?= =?utf-8?B?aHJDYlRvRUFZeFNTQng5Y3hkaUYxRS9sR1h0azlqUW15SWJMdXBodEZzOW9K?= =?utf-8?B?U3oxTTBYeU1QcmkwUDA1R1YzbTBKdmxBdTlUY1JZdjVWQk9iUnpWR0ltTUl1?= =?utf-8?B?YmpuVVNCU2NyN3AvYlpzRmtLb3hmMUY2TEZjazZnblpBSWxiT1FxMDcwYXBt?= =?utf-8?B?WEZrQWtsK3hPRUpyOW5PL2RQQk8vNk1qdGxwMGZiaVo2cFI3K3U3ejNMRU9T?= =?utf-8?B?a09hT0pFZHB6OHZkUytBQ1NVNnViWFo4c0VOTTc1L1RzTUllMWFLZ0NjUGhq?= =?utf-8?B?emJ6NFM5d3hmOGJyaXg2YTV0SDNETEhSbW1jRFQ0c01KZ2tRZlJSOTNMM2Vh?= =?utf-8?B?U05yRENlRDdVdUxwNVNkVUM5UldRbjRybjRRbVFKSk44SnFRQUtSUDNCKzB2?= =?utf-8?B?NlNrVkx2bmIrVUhhQWkvM0NJT2E5d201bm93OHlleEo2b2RSVzYreW0xV0Zh?= =?utf-8?B?UEZ6U094Nlp6YllCVTNrb3kxcythUnhVcVhsTDFUQXgvR2pPeUFhMWVkRVVw?= =?utf-8?B?ZW1DYUNZWUdheUxkdUQzbXkxYU42RkZ3NGpUS3ZsbDBPaGhrVVI3SkthL01r?= =?utf-8?B?Y0F0U01vU2dGMVFVRlBOWC9SY1lXTUV4TUl4eDl2VENNQnRwQT09?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_abd0d806805c982851312bdf0042666eericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3209.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ddb33c2-51da-4a52-331c-08d88ab79d51
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2020 05:14:09.4318 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: BClT2yknuC8HqhTaFr5QKcyVgW3VXeTX3QmYqoevp3WD5SAVYUyJK5BdLWWh7vDqMz6FQ+zjp92lXgB2qtfDEjJEQjz2CUaungjrTPN2sXY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2508
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yQdx8EbU5nDvMtOuWtdH5wHXL-s>
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: Tue, 17 Nov 2020 05:14:15 -0000

+1 for a deterministic (minimal) encoding.

--Mohit

On 11/15/20 10:13 PM, Eric Rescorla wrote:
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



_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls