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

Christian Huitema <huitema@huitema.net> Wed, 07 October 2020 00:59 UTC

Return-Path: <huitema@huitema.net>
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 B37033A1590 for <tls@ietfa.amsl.com>; Tue, 6 Oct 2020 17:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.712
X-Spam-Level:
X-Spam-Status: No, score=-2.712 tagged_above=-999 required=5 tests=[BAD_CREDIT=0.1, BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 SEp9BvJrEkGM for <tls@ietfa.amsl.com>; Tue, 6 Oct 2020 17:59:04 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 21BAE3A1428 for <tls@ietf.org>; Tue, 6 Oct 2020 17:59:03 -0700 (PDT)
Received: from xse289.mail2web.com ([66.113.197.35] helo=xse.mail2web.com) by mx166.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kPxnE-000MM9-Fn for tls@ietf.org; Wed, 07 Oct 2020 02:59:02 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4C5bHg0fHqz4gDG for <tls@ietf.org>; Tue, 6 Oct 2020 17:46:23 -0700 (PDT)
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kPxb4-0001KJ-VD for tls@ietf.org; Tue, 06 Oct 2020 17:46:22 -0700
Received: (qmail 16581 invoked from network); 7 Oct 2020 00:46:22 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.46.239]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 7 Oct 2020 00:46:22 -0000
To: Martin Thomson <mt@lowentropy.net>, tls@ietf.org
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> <53DD7D0D-D325-4246-86F2-C409875134FB@ll.mit.edu> <8e8ca76e-37ce-ce10-ae42-ea26d87c35fc@pobox.com> <9CED80DA-FAE7-4C7F-9687-3B61B63587E9@akamai.com> <a49d4b8c-cf49-51df-0c6b-332a4459f318@pobox.com> <b8f4597c-37de-0092-6179-c6bf275c20f9@huitema.net> <4227b57b-8d9e-4b20-b17d-4d03730ef0bf@www.fastmail.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <a9a0de11-04ea-b5fa-cf28-3604b5523883@huitema.net>
Date: Tue, 6 Oct 2020 17:46:22 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <4227b57b-8d9e-4b20-b17d-4d03730ef0bf@www.fastmail.com>
Content-Type: multipart/alternative; boundary="------------6E58F3EBFBA1D2DC4F362972"
Content-Language: en-US
X-Originating-IP: 66.113.197.35
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4ZpfhSxT1ZkWVx6vnl9ysRPgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cAdwcW/8Ox85Le8wqlbs5XX2XX9bIsGDSYq5OAASmskY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm65NdfLN8K9b ke08A4pcSPt80MNNHH1/DoFvdAmK1rSvHhCbhUIcQHXe8fL0JDeGnJzr3jDdNh0sd8x3mL5+BAN8 g2fGU86cSswil+kDetUfttbLHdNhiUq2jBEvMVLlZ4GThCScvU0cCIiHSQbmcVIWDcfBfBCTJ130 fnOVpiJKlioSJ70+pnzmGIXaCrDBl/E2+CIWVHfGh6efO1IfZjQUSg39QVoXH67+z2nJxxsOXPWl FdaGOH191uXjgjQN/bk/tOvsMDZmQNfeGxdXg4G3kWmecw3RlBbdjdisBFiW83g9ueTJOU6a76yp yxjdeg8YhWenlMfuvb1mNY5/IPiuedK/Z3MvnAyDmuOaA5CGZRWsGw8ac2InzcAP/gmxwNpms+rB 6wJM+NNhN3aT35NSU/fjw6KbqLw80r1gDO3m6U0LjBzYuQztdAThgtWSU3qCINKqlAdh+ePAcEwD s/8=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8BKPzpj3UeuX-mNgFrbYeLzSxgQ>
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: Wed, 07 Oct 2020 00:59:06 -0000

On 10/6/2020 5:23 PM, Martin Thomson wrote:
> On Wed, Oct 7, 2020, at 04:12, Christian Huitema wrote:
>> * Receiver side: receive the message, save it, parse and process, and
>> when it is time to verify the signature go back to the original message
>> and check the signature.
> I think that you mean:
>
> receive the message, check the signature, then parse and process if that passes
You would think that, but the X.509 design meant that the application
would received all its data in parsed form, and then re-serialize the
parts that it needed to check, such as for example certificates. And if
you do that, you must absolutely guarantee that parse and serialize are
bijections between the application representation and the byte
sequences. Which leads to requiring "distinguished encoding rules",
including not just the coding of integers but also ordering of elements
in sets or representations of character strings. And yes, this turned
out to be a really bad idea.
>> If we do that, then there is no reason to mandate minimal length
>> encoding. And TLS already does that. For example, we do not reorder
>> extensions according to some canonical rules before placing them in the
>> transcript.
> This I agree with.  But cTLS doesn't work that way because the signature - such as it is - applies at the next layer, which appears after the encoding is erased.  And that is important here.  The encoding we're talking about is a compression function only.  Not having a canonical form means adding an inefficiency, but it has little bearing on the process you describe, which would be modified to:
>
> receive the message, decompress the message, check the signature, then parse and process if that passes
>
> In TLS we don't follow that ordering either because we all routinely process tons of stuff before we get to the Finished/CertificateVerify.  Having those at the end makes a ton of sense, for a variety of reasons, but it does mean that we build a protocol on credit.  And we have plenty of experience, I hope, in dealing with bad credit in TLS.

Yes. And I do also agree with your statement that *not* requiring
minimal length encoding makes some of the code paths much simpler. I use
that for example to encode the length field of Quic packets.

-- Christian Huitema