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

Martin Thomson <mt@lowentropy.net> Wed, 07 October 2020 00:24 UTC

Return-Path: <mt@lowentropy.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 246A73A1578 for <tls@ietfa.amsl.com>; Tue, 6 Oct 2020 17:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAD_CREDIT=0.1, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (2048-bit key) header.d=lowentropy.net header.b=FoPbu8wu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IH1HpXop
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 0yMOAQRhJcGm for <tls@ietfa.amsl.com>; Tue, 6 Oct 2020 17:24:10 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0FC3A1576 for <tls@ietf.org>; Tue, 6 Oct 2020 17:24:10 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A9B58A22 for <tls@ietf.org>; Tue, 6 Oct 2020 20:24:09 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 06 Oct 2020 20:24:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=KvPRIbiaDpmvKoOdfPA00j28zfpWUXZ FiYmiUCy41Vw=; b=FoPbu8wuRxVnJ30p4X17sNaPvDCTR78k4JTl7psDHI2Twg5 y7xfnrARow+V0rJa34h5TV3AcB/YPNFITm9HV0au6AV+3Pk5JKjAAkVia5JclyMm dmVP4n1s6TwK8DFpIieoBCl/yoBAguaYZeotnM3foFWw8iuYrMChhv783aFqeYOU xvHYHc6PIg9soniyN98xxAy9BwDGq/56rSQE+t4aFkM4uH5xCDesWiBnfdhG0qbJ i5oF/3pidFn4BFoM3DgGi/nB0PXdiIcCXOUjY8+8+m9Ubb66wDd50DNmSK9VbvXM m6O38N7Dk9YEGcZi5x74se0D7sHj3GHbGva1XyQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=KvPRIb iaDpmvKoOdfPA00j28zfpWUXZFiYmiUCy41Vw=; b=IH1HpXopvQYUmDlGiX8a4Q m6EutSs4uAjx5oiUKdrazcAm6IJwKRGH+1l46HBTP+Guy0cyjJ6d5h6IFxDAiOoP Qsl2FrMAan+5lmF9Qr7FNcLQiwvcV9DnAQlNIwsH8NkZlgn+CsS8hAQha2ZFNqSb MLwgQHdT380uqHY7MnvwbHxU6WGB9ilkCck91UblOmm1O5k32jpwo2eLqC6FXN2H Rk0m7nBwfpMcWb32VRVgF4dbG4IXUfGBNMI4Be0Y7YgN6rmhcJifqGgJER++9A0J uj2H3oEAr7HCYhhLw/V/CyDNKNCW/cB7AnyXtfrGREhs5YYrnq/njuK3tygW9spw ==
X-ME-Sender: <xms:qAp9X6SOX1iF_GhlmNc7fpqFUF5C6sTStFzpAA8P_K2q9cARKLRMHw> <xme:qAp9X_wv_XmAAFNp8K234iOC6RirvjgamtFYAia1JR9cySEzqLd0cCnhLyqhk33ud CjxN6HTMZ53RwpQwwQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgeehgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:qAp9X30umiWy9ecVYp9nMGAQko0vsFG9yvgY2_xm4NuekCK_MaWbIw> <xmx:qAp9X2CFiQ5rLSFgOBMkhnaDWJuI3HUftK3_bssFBeSylOMswV5aHA> <xmx:qAp9XzjOJS9vgP7vRPl0UBtn_sP6Pb6GzqQFD-uwkiBdvcvMmf1miA> <xmx:qQp9X-up7cMQwLZYY9E1qF156Ce_Q24S4eboWQd4Y6jeUCyHbgpXCg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 75A1C20066; Tue, 6 Oct 2020 20:24:08 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-407-g461656c-fm-20201004.001-g461656c6
Mime-Version: 1.0
Message-Id: <4227b57b-8d9e-4b20-b17d-4d03730ef0bf@www.fastmail.com>
In-Reply-To: <b8f4597c-37de-0092-6179-c6bf275c20f9@huitema.net>
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>
Date: Wed, 07 Oct 2020 11:23:48 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hUffOSCPHr8DL-MXSAvP1Z4qskY>
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:24:12 -0000

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

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