IETF Logo Mail Archive

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

Martin Thomson <mt@lowentropy.net> Tue, 06 October 2020 01:38 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 06D123A0E0B for <tls@ietfa.amsl.com>; Mon, 5 Oct 2020 18:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[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_H4=0.001, RCVD_IN_MSPIKE_WL=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=e+8PbhF9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y2e7gy+l
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 MO4vVLjppXC7 for <tls@ietfa.amsl.com>; Mon, 5 Oct 2020 18:38:25 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3D33A0E06 for <tls@ietf.org>; Mon, 5 Oct 2020 18:38:25 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 5F50F90F for <tls@ietf.org>; Mon, 5 Oct 2020 21:38:24 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Mon, 05 Oct 2020 21:38:24 -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:content-transfer-encoding; s=fm3; bh=M1QYp Cv0iLqaugIQLHx/sHiWtBlcmxG6yDfIiW1vbHo=; b=e+8PbhF9cADaHHUswWjBT FgiXMh/mrlVmKAM3vJBc41z6VNdZqHPsI18AqZ/3CULQzvYR+LcosnFwLxmdlFLx L3CN/0182C8mj2PbB9LCX4ef3kqIffz97nEQrQqYaTxCTnq3yJp/ovujhAtw1yGH wwQsR9oMaFLV0ayW6jsqVBW+SIM7OO5hol50h6pFruK5Qgc/DGgaVzLHGPmQ1JWU 4T3l5SiRiGwh1WjtjxAceAIkPUn+K+HLCCGTw6ttNwZKImSL2uFzoxBeRE0wSE9n ASMnvAk8ebXI500Tr0fiRx3L2oInR2zXZH133mxaa1rMQsF3mcJM7YCWzLq5+gT9 Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=M1QYpCv0iLqaugIQLHx/sHiWtBlcmxG6yDfIiW1vb Ho=; b=Y2e7gy+l07QjC2kTKdNiw7pLC/dWbGyeC5Y9l+kKFl1NCdnx3ThnJTYl3 CHSbj77z+gW/D+uOFrHxvGFAWEqSnLa15B31cDddAecHMJsbPuNgoxvueT+unGQM AsH8uoh2Bl3bPFthd6DTmbfF7MYYHhgWt2LnjWd9/5+WmZzJLJPw67CMVo1qaRl+ q1xFXRRtDix2WYSMUIKGkG8akmiSVx9NKaH5b1NziSYziYR9x6sV0BZNlyKZuVvN +QMS2I3TIKfCZdAZPdesj6Ws2PYuqPpRhArpllWrOUT2DMEjDPSsx5O1q2T6NMXf nq0djnmRdojN/UljEPBabqk1Unhyw==
X-ME-Sender: <xms:j8p7X-baEuZ5-5K_8XUEUHiyA-s_QUwlE1f-ifX8gsjX-It0LBi5nQ> <xme:j8p7Xxb0r245vhIsyaIICBWc-N0AmM0Qloyd_0Gu4lZe5AI_7NrkC178Yy4TdXlyx -roPMHNvnFxCAqkYYE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgeefgdeglecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeehhedvhfehvefggeejtd egjeduveetleejvdekjeejhfekieekudelffdvudefffenucffohhmrghinhepghhithhh uhgsrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:j8p7X48J30V4hDdkxaCErwq4Dl_dhwA-qubfGhgT59YxVca7uAMJcw> <xmx:j8p7Xwr4RDnEZPNvsZSUjxLHUbTxImK_qyiTMDDOqfjryCBuVarsZg> <xmx:j8p7X5pcsuq9HRVxrgpt4HCvQkz6BKCZhOoQh1nxp_7Hx8V-0CjaBQ> <xmx:kMp7X2188WepITuP2LGrsM7Ni6yTEqH_YXvz6GHIm4Z6pWNty02RZQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 84F3B20090; Mon, 5 Oct 2020 21:38:23 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-382-ge235179-fm-20200928.002-ge2351794
Mime-Version: 1.0
Message-Id: <6285bb83-747b-471a-9970-be15dbd8618e@www.fastmail.com>
In-Reply-To: <CAOYVs2rEDtgJFVpiQkcaaYG2LAyW1hB5Cou4kUoG2_dkxMFTww@mail.gmail.com>
References: <CABcZeBPNFhGoLhgqeR9ObwyU68BYq=hXG1PhXcqNsNDNFGGyaw@mail.gmail.com> <CAOYVs2rEDtgJFVpiQkcaaYG2LAyW1hB5Cou4kUoG2_dkxMFTww@mail.gmail.com>
Date: Tue, 06 Oct 2020 12:38:04 +1100
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JYdLNWGrG4cnyYvROiPCkZXXM8U>
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 01:38:27 -0000

Oh, I consider that to be a feature.  One that I exploit.  It's sometimes awkward to build a structure then prepend a length that has a variable-length encoding.  If you know the maximum length, the varint encoding allows you to avoid having to move memory.

That said, cTLS won't authenticate both the value and the specific encoding of numeric values as the varint encoding is erased.  I don't consider that to be a serious problem, but it means that cTLS transcripts can't be directly compared.  I would note that in the draft: people shouldn't be processing cTLS messages that way, but they might be surprised to learn of this.

On Tue, Oct 6, 2020, at 12:31, Marten Seemann wrote:
> One thing that’s a bit annoying about QUIC’s variant format is that 
> there are multiple ways to encode a number. This has led to some 
> complications in the specification (e.g. QUIC requires you to use the 
> minimal encoding for frame types, but allows all encodings everywhere 
> else).
> It would be nice to have an unambiguous way to encode a number.
> 
> On Tue, Oct 6, 2020 at 07:35 Eric Rescorla <ekr@rtfm.com> wrote:
> > Hi folks,
> > 
> > cTLS uses a bespoke varint format. Now that QUIC is nearly done, I propose adopting their varint format.
> > 
> > https://github.com/tlswg/draft-ietf-tls-ctls/pull/28
> > 
> > Any objections?
> > -Ekr
> > 
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email