IETF Logo Mail Archive

Re: [radext] I-D Action: draft-ietf-radext-tls-psk-01.txt

Alexander Clouter <alex+ietf@coremem.com> Thu, 10 August 2023 13:38 UTC

Return-Path: <alex+ietf@coremem.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71031C15108F for <radext@ietfa.amsl.com>; Thu, 10 Aug 2023 06:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coremem.com header.b="saXC+vkQ"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="PSzdTr5i"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGiArvgXHg3d for <radext@ietfa.amsl.com>; Thu, 10 Aug 2023 06:38:18 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DF2C14CF1E for <radext@ietf.org>; Thu, 10 Aug 2023 06:38:18 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D800D5C0069; Thu, 10 Aug 2023 09:38:15 -0400 (EDT)
Received: from imap46 ([10.202.2.96]) by compute5.internal (MEProxy); Thu, 10 Aug 2023 09:38:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1691674695; x=1691761095; bh=Ju zBSRzCqy3Ery2cPlA0Y5JHO804roU+7aiWfzLDNVQ=; b=saXC+vkQbKLg7JL1Xl rfXM+jWM2L7kzUFIW8oT2TH7HHDasQwigZI2puGp3UBacCwO0vMjYcH/1iPa4fdm OhOcpcJ199MLwUIRDnjqS4IOF7WPeUVKyRvFMtXrGn1kdBipAsNVulsg01xsPNLB tk2iXaZJIC1DBLMI2E+mYqsiH7ZCLyTcSs8kcDpN3TTnVVeFhtsodjlTsHPciOJ6 t0t64PKFxPnXkc2BXcH7Nezc2TEfa+LJJS69T5p265ao4BTdz4SXo7x774xXCghJ EQJAWhkDwAdSxP7IZ9z/cCU96bSpIkQLZkR9PpyotHVxBn6Y2/OMQGoNFCAf2ZO7 UL8w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1691674695; x=1691761095; bh=JuzBSRzCqy3Er y2cPlA0Y5JHO804roU+7aiWfzLDNVQ=; b=PSzdTr5iwQKXr0GdPWTpRu7xaosT/ PKLnLBGbsBeikIkjSuYlcY33QLJX3MI9ZGKntdmgsVm2v6p7SLvsEQp6MJY6t4wB 9g3tCfcU0QNaYcHm241vRb4m6Q1sTumNidOPLWrdhfPiNJJblPP0biXRVp4BHP7C +9cc+yYJeakp/khyTyLAPjoj+ZX+UJx55BhcWwcN7eVTXADDjMDzP4C0q8Haxiz4 9BzXZr1r0A8ha1Rb54FllzGKDrGzjQoQKFAIen08xJXpj4DdNMb8kvxEaeOr5wU5 fxwvrcYl8UgNDDwvyJaSF6IRRagYv5vmiXTcfGdyi2MaDcP0FG5IoKJag==
X-ME-Sender: <xms:R-jUZIwoffZvsqrWQVkKhhsGT1y8MYCH0Hoi7NlmDAwoEA9jNMLlsg> <xme:R-jUZMQnvnZEIcQrgR7lyfllR4F0FFRS6yBgPoKw1iKm6UUeQK6HtrT9xj2p0tUeN b-Zf5HbSfZSPDcZrg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleeigdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetlhgv gigrnhguvghrucevlhhouhhtvghrfdcuoegrlhgvgidoihgvthhfsegtohhrvghmvghmrd gtohhmqeenucggtffrrghtthgvrhhnpeevgeehjeeuveekvedvhfehuedufeehgeduuedt leelieetheegffeitedtudfgudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrlhgvgidoihgvthhfsegtohhrvghmvghmrdgtohhm
X-ME-Proxy: <xmx:R-jUZKVewf4plmte-x0-BjJ4f_9xCG3vHed80RXALxfUKZ8P_RzjOA> <xmx:R-jUZGj2XM5srpOsYkXOLOQOEf6bLzUieykab5IANBrYcuNEENpO4Q> <xmx:R-jUZKAeGvdtGzRm72XEfs5E_mwxoOnTXSQIN3dYz0GjXELrxIqjhg> <xmx:R-jUZB8PTlQXj3PTtzVKhnwHNwGo39Xm-DHqI83n_mSMTt8Mzse2Bw>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7184B2A20085; Thu, 10 Aug 2023 09:38:15 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-624-g7714e4406d-fm-20230801.001-g7714e440
Mime-Version: 1.0
Message-Id: <6c317e5b-114b-4859-bfe8-956492cbcd41@app.fastmail.com>
In-Reply-To: <75FBCB67-52AF-417C-ADED-ABCA46D77408@deployingradius.com>
References: <169151650874.8889.17786705009619055833@ietfa.amsl.com> <77dac3b2-73be-4170-8a6e-17a70361e750@app.fastmail.com> <75FBCB67-52AF-417C-ADED-ABCA46D77408@deployingradius.com>
Date: Thu, 10 Aug 2023 14:37:55 +0100
From: Alexander Clouter <alex+ietf@coremem.com>
To: Alan DeKok <aland@deployingradius.com>
Cc: radext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/kVUaKLGPqttOp63e7eNmhd2_fSE>
Subject: Re: [radext] I-D Action: draft-ietf-radext-tls-psk-01.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Aug 2023 13:38:23 -0000

On Thu, 10 Aug 2023, at 12:41, Alan DeKok wrote:
>   The design of TLS 1.2 has issues.  If you use the same PSK for TLS 
> 1.2 and TLS 1.3, then it's possible to attack TLS 1.2, get the PSK, and 
> then use that to attack the TLS 1.3 connection.
>
>   The solution is some hand-waving requirement to not use the same PSK 
> across the TLS 1.3, and TLS <1.3 boundary.  How does that work in 
> practice?  I'm unsure.

What about demanding the *server* implementation has two fields "TLS PSK pre-1.3" and "TLS PSK"?

This means existing clients can do whatever they want but the effect is that they will be forced to handle partitioning this once its implementation includes TLS 1.3 support.

Cheers

v2.23.0 | Report a Bug | By Email