[TLS] Re: Errata 4800
Martin Thomson <mt@lowentropy.net> Sat, 08 March 2025 08:48 UTC
Return-Path: <mt@lowentropy.net>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 0F215912F8C for <tls@mail2.ietf.org>; Sat, 8 Mar 2025 00:48:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b="CgMdVQIA"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="gdj6YJc5"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvU-pcLsgqMb for <tls@mail2.ietf.org>; Sat, 8 Mar 2025 00:48:38 -0800 (PST)
Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 4AB50912F87 for <tls@ietf.org>; Sat, 8 Mar 2025 00:48:38 -0800 (PST)
Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfhigh.phl.internal (Postfix) with ESMTP id 256E911400EC for <tls@ietf.org>; Sat, 8 Mar 2025 03:48:38 -0500 (EST)
Received: from phl-imap-01 ([10.202.2.91]) by phl-compute-07.internal (MEProxy); Sat, 08 Mar 2025 03:48:38 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1741423718; x=1741510118; bh=sk+CoLUbiHBfvgw7qxRwexF7BVz6s3zzaI4h/hrThlU=; b= CgMdVQIAUuPvczzv5SQwGVGQt3AYVPGqQzqGrwwlxdF/M2CaznytM72HwoC1rYej NtZwvvUedMd5Hsfen5aiEFtlNIo1F668tpttGigD2xcndhvsU6Fqomm7rs3riXoH WKIDDRmsf3joBZFkt6E/ncVw7xpAMIzUP4VykJPRoYCoDRjbSV3l+rGsOFHVsPMH peOHyFmumd+DLjaT8cOy4CoEW5HyZ5K2Vt9XKg307ywiBlZWbtbgxdY8Yy6ZfxxA /GX6sJJEbIurCkTrNZwKNiCLCUczw0JXWXLtr65xUvboeKj+fIPcpUMuKmxRDO86 qx8hstxyRtN75h7OiJ4peA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1741423718; x=1741510118; bh=s k+CoLUbiHBfvgw7qxRwexF7BVz6s3zzaI4h/hrThlU=; b=gdj6YJc5x5j/vqmim jroWO2vsBQWN0zNM1rs7B2uqKLuc8itK0mMbHTDQ0aCpu88S2ohkvqO9mrGazbxD SZdLUa0hIbqixkAcwyNwBRJKKQyFV+q5ID/023N6InSO3Hfab/WG9C/U3phP7UtP QXfVl1Z09OnHUw1QwcNMrpLoY/tOOY7zYy8fKZsvm0EZPjKD0VxEpe5YinqHehpn dAx8bRWhquDcYOe1ugXfzkFSCUl0o4QOura1BZ3PThQxajQ2rxkV3MoUl8Sdteua B/K8FSXv9xSjClULi1PixlzdxWehcbTl0YKNI7JUQ69LEs57DaTSKuN4JZ5/VecO TmECA==
X-ME-Sender: <xms:ZQTMZ0kYYJ6soAAOIIsrYLjeJJgY4G4rdK0QeSeZAbFYeTTQZEyc7g> <xme:ZQTMZz0J_r2fofvhiDY7ZUZbnZOZrjhegXD8ZgFEzF6JbLw1GfDa8LBkBhRikOmN9 FWK94aTdwXledJOfiI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduudefudduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg ffhffvkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedfofgrrhhtihhnucfvhhho mhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrh hnpeegudelvedtheelffekgeeuhfevjeduledvvdelgefhjeeutdevffelteduiedutden ucffohhmrghinheprhhftgdqvgguihhtohhrrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgv thdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepth hlshesihgvthhfrdhorhhg
X-ME-Proxy: <xmx:ZgTMZyoVE4OR8_S8gkssSppOH4ISaAasYJby0osT56blPZ4I4vnCqg> <xmx:ZgTMZwkrvye1MxZ08cuS-coH4UhbA5oRkP7f-yqdqTQoxYTRbICl2w> <xmx:ZgTMZy0tn2M7_hnem4hLyqbaW2m3EJH70kH20ZjTmpu_J9Pd0N2idw> <xmx:ZgTMZ3tGv5mwwZ-fRjlRpYhx9Kn4RzO5McrD9PlOJgf-gh-7JsRJ3A> <xmx:ZgTMZ3_t-QzCCUS-x_9fDTUzWERMXGWIL08tXmcSflyTwsvJdKXDM8S9>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id E11B63360079; Sat, 8 Mar 2025 03:48:37 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
Date: Sat, 08 Mar 2025 09:48:16 +0100
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Message-Id: <e7fb9468-8a9a-4e84-b5ac-35efcd226020@app.fastmail.com>
In-Reply-To: <6cf868f7-5761-4791-bca1-0ac8b763f473@nthpermutation.com>
References: <6cf868f7-5761-4791-bca1-0ac8b763f473@nthpermutation.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-ID-Hash: OYIQLL6D46O2KBHPAQJ66XTVV3ADY6Y6
X-Message-ID-Hash: OYIQLL6D46O2KBHPAQJ66XTVV3ADY6Y6
X-MailFrom: mt@lowentropy.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Errata 4800
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0Ig1wxAgKD-82G-k49l6PLZt4vY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>
I don't think that Verified is quite right. It's true that the maximum possible length of a ClientIdentity doesn't fit into the structure defined. But nor does it fit into handshake messages (though the overflow is potentially smaller). TLS is full of this sort of thing. The point being that the maximum values exist to define the size of the length field, not the practical limits. In this particular case, the suggested ticket formulation simply doesn't work if the ClientIdentity is too large. Good thing too, because I doubt that anyone would want a 16MB ticket. I'd put this down as HFDU instead. On Fri, Mar 7, 2025, at 20:21, Michael StJohns wrote: > https://www.rfc-editor.org/errata/eid4800 > > RFC 5077 <https://www.rfc-editor.org/rfc/rfc5077>, "Transport Layer > Security (TLS) Session Resumption without Server-Side State", January > 2008 > > I'm working through the list of errata and came across this one. > > This mechanism is obsolete in TLS1.3, but still exists in TLS1.2. > > The errata appears to be valid with respect to the wrapping length > issues of the indicated structures - (E.g. a 2^16-1 object can't > encode/wrap a 2^24-1 object). > > Someone should consider the structures defined here but carried to > TLS1.3 and verify length consistency and issue an errata if needed. > > > > If TLS1.2 is actually still live for development (and new RFCs), I'd > mark this errata as Verified. Otherwise, if TLS1.2 is obsolete (and > not just its documents), I'd mark this errata as "Rejected" as there's > nowhere to apply the errata. > > I'll leave it to the chairs of TLS to figure out which is more appropriate. > > Mike > > > > > > > > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-leave@ietf.org
- [TLS] Errata 4800 Michael StJohns
- [TLS] Re: Errata 4800 Martin Thomson
- [TLS] Re: Errata 4800 Michael StJohns
- [TLS] Re: Errata 4800 Salz, Rich