Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

Dennis Jackson <ietf@dennis-jackson.uk> Thu, 28 March 2024 18:27 UTC

Return-Path: <ietf@dennis-jackson.uk>
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 3ADDCC169430 for <tls@ietfa.amsl.com>; Thu, 28 Mar 2024 11:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=dennis-jackson.uk
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 6cLs7mCkXfVe for <tls@ietfa.amsl.com>; Thu, 28 Mar 2024 11:27:47 -0700 (PDT)
Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [IPv6:2001:67c:2050:0:465::202]) (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 41985C16942E for <tls@ietf.org>; Thu, 28 Mar 2024 11:27:44 -0700 (PDT)
Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4V5Bpz0gjgz9t0p for <tls@ietf.org>; Thu, 28 Mar 2024 19:27:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dennis-jackson.uk; s=MBO0001; t=1711650459; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CLsDzM5VUTaBI8VbEzupMtoTie7jWFI2ka77aPJurw0=; b=uw2xTYpkI3pejPurOtzdr8dcOaux0QvKjbs2V0BGTYDLSIIo7fT4vzpCxrk/SEJ23WH0Tn nMzlPQ4fnfD2wy20ftnGWzj7cnAmnkp6NxOT1ek3QEqPi9HeXTG3RuYCSR7rnAA3xf3lO+ PAVgoMa5y4dRctUib8P9qTyEZD2gTlxBvhX/YZAI1Xe7fr1Go17hNpT1yeVL0x3dourBmE NvuTc+u/e1oN7HZ1lotVkYl90giYWKLUig+drUoWcGt3zE9/26CWLmJbyyWioDNuiGZbij kWoQ3iOsjG7W4naMhTfWDsZw1HoCJNDvJiycp9wdvEyODnEBho9OAUOMGN3aoA==
Content-Type: multipart/alternative; boundary="------------9KFYenB0ho00CIquV67KwA0t"
Message-ID: <da24e8f7-64d9-473d-855b-fd0fbf3fb67d@dennis-jackson.uk>
Date: Thu, 28 Mar 2024 14:27:36 -0400
MIME-Version: 1.0
Content-Language: en-US
To: tls@ietf.org
References: <GVXPR07MB9678DFD1EED3971606FB3DE6893B2@GVXPR07MB9678.eurprd07.prod.outlook.com>
From: Dennis Jackson <ietf@dennis-jackson.uk>
In-Reply-To: <GVXPR07MB9678DFD1EED3971606FB3DE6893B2@GVXPR07MB9678.eurprd07.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/h4ALaNeXMUNLhziQiGJwsSykknk>
Subject: Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 28 Mar 2024 18:27:52 -0000

Hi John,

It depends what you mean by an identity. TLS1.3 ensures the peers agree 
on the used RPKs and it doesn't rely on any external proof of possession 
to achieve that property.

How the peers come to trust the RPKs or their corresponding identity is 
of necessity left to the application - not dissimilar to how the 
application has to decide which root certificates to trust and whether 
the leaf certificate is appropriate for the intended connection (e.g. 
browsers extract the valid identities from the SAN).

Best,
Dennis

On 28/03/2024 15:22, John Mattsson wrote:
>
> Hi,
>
> I looked into what RFC 8446(bis) says about Raw Public Keys. As 
> correctly stated in RFC 8446, TLS 1.3 with signatures and certificates 
> is an implementation of SIGMA-I:
>
> SIGMA does however require that the identities of the endpoints 
> (called A and B in [SIGMA]) are included in the messages. This is not 
> true for TLS 1.3 with RPKs and TLS 1.3 with RPKs is therefore not 
> SIGMA. TLS 1.3 with RPKs is vulnerable to what Krawczyk’s SIGMA paper 
> calls misbinding attacks:
>
> “This attack, to which we refer as an “identity misbinding attack”, 
> applies to many seemingly natural and intuitive protocols. Avoiding 
> this form of attack and guaranteeing a consistent binding between a 
> session key and the peers to the session is a central element in the 
> design of SIGMA.”
>
> “Even more significantly we show here that the misbinding attack 
> applies to this protocol in any scenario where parties can register 
> public keys without proving knowledge of the corresponding signature key.”
>
> As stated in Appendix E.1, at the completion of the handshake, each 
> side outputs its view of the identities of the communicating parties. 
> On of the TLS 1.3 security properties are “Peer Authentication”, which 
> says that the client’s and server’s view of the identities match. TLS 
> 1.3 with PRKs does not fulfill this unless the out-of-band mechanism 
> to register public keys proved knowledge of the private key. RFC 7250 
> does not say anything about this either.
>
> I think this needs to be clarified in RFC8446bis. The only reason to 
> ever use an RPK is in constrained IoT environments. Otherwise a 
> self-signed certificate is a much better choice. TLS 1.3 with 
> self-signed certificates is SIGMA-I.
>
> It is worrying to find comments like this:
>
> “I'd like to be able to use wireguard/ssh-style authentication for my 
> app. This is possible currently with self-signed certificates, but the 
> proper solution is RFC 7250, which is also part of TLS 1.3.”
>
> https://github.com/openssl/openssl/issues/6929
>
> RPKs are not the proper solution.
>
> (Talking about misbinding, does RFC 8446 say anything about how to 
> avoid selfie attacks where an entity using PSK authentication ends up 
> talking to itself?)
>
> Cheers,
>
> John Preuß Mattsson
>
> [SIGMA] https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls