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

Christian Huitema <huitema@huitema.net> Tue, 06 October 2020 17:13 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 3DFAA3A0DC8 for <tls@ietfa.amsl.com>; Tue, 6 Oct 2020 10:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.113
X-Spam-Level:
X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 MEFf0AagHg4H for <tls@ietfa.amsl.com>; Tue, 6 Oct 2020 10:13:07 -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 D73E83A0DA6 for <tls@ietf.org>; Tue, 6 Oct 2020 10:13:06 -0700 (PDT)
Received: from xse263.mail2web.com ([66.113.197.9] helo=xse.mail2web.com) by mx18.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kPqWE-0006Sb-Gm for tls@ietf.org; Tue, 06 Oct 2020 19:13:01 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4C5PD867gMz1QLV for <tls@ietf.org>; Tue, 6 Oct 2020 10:12:40 -0700 (PDT)
Received: from [10.5.2.49] (helo=xmail11.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 1kPqW0-0008EX-Nj for tls@ietf.org; Tue, 06 Oct 2020 10:12:40 -0700
Received: (qmail 9770 invoked from network); 6 Oct 2020 17:12:40 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.46.239]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 6 Oct 2020 17:12:40 -0000
To: Michael D'Errico <mike-list@pobox.com>, "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <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>
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: <b8f4597c-37de-0092-6179-c6bf275c20f9@huitema.net>
Date: Tue, 6 Oct 2020 10:12:39 -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: <a49d4b8c-cf49-51df-0c6b-332a4459f318@pobox.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.197.9
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.12)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVBnFpbE4O9Jxx wI3dgH1RrkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4bxAgr7iJ0rrXWkRPlc9fwdgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cISFy11mIgiZeuFtj1P36GmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdLn4jABaJqtNDIuGYj2WGeveXgFMyx0sD4hRS2uyMFprER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnFWB11dhDcan IFpyAO2lFVtkDzKvWpEIBa7bNXOyv8skIA8H0qAu9L3HksvcddNSq//v7mc5aMPEc8PJCtBGmSXv 5pWb82qAoDl3ILGSF0vmDvI0DEihOd7XzCAIcFZdY11677oPXF7r5zsW33ZNlioeEsGOJOKU/kLG nxJMOi7dXcOwx5W3lrJDYYePTFZjwRqf27VeHOkXe82afzWlDItH8W+ndM7Oj+Ks33EJUvhnHHAS JNUmoOHSoqgqxfHmWT9DhgeN1eWlT4ORFssHQcwOsdWZzOpiLfCkJaHUoEfK83g9ueTJOU6a76yp 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/996IdhF-JkdctOsderv8F0JN59Y>
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, 06 Oct 2020 17:13:08 -0000

On 10/6/2020 10:00 AM, Michael D'Errico wrote:

> It matters in X.509 certificates because the basic
> encoding rules (BER) allow you to specify the same
> thing in different ways.  With DER, there is only
> one way to encode every element, so everybody will
> come up with the same string of bytes and hashes of
> those strings will be the same, signatures will
> verify, etc. 


Well, we have learned a few things since 1994. The DER rules are defined
to allow a "re-encoding" workflow:

* Sender side: prepare the message, encode with DER, sign the result

* Receiver side: receive the message, parser with generic ASN.1 decoder,
process the message using the "parsed" representation, re-encode with
DER, check the signature.

Experience showed that this workflow is very problematic, because the
parse/reencode process may introduce subtle changes and the signature
will fail.  One may argue that these changes are due to implementation
bugs, but fact it that this is a rich environment for growing bugs.
Based on experience, the receiver side is better done as:

* 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.

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.

-- Christian Huitema