[TLS] Comments on draft-dt-tls-external-psk-guidance-01
"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 20 April 2020 14:27 UTC
Return-Path: <shollenbeck@verisign.com>
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 187E33A0787 for <tls@ietfa.amsl.com>; Mon, 20 Apr 2020 07:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=verisign.com
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 oHloQrWCK49W for <tls@ietfa.amsl.com>; Mon, 20 Apr 2020 07:26:57 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E7F3A0784 for <TLS@ietf.org>; Mon, 20 Apr 2020 07:26:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=5065; q=dns/txt; s=VRSN; t=1587392817; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=lYAxEYrNPPvJrvXGl062I7EZpkgHFu4I8d/mykNefWQ=; b=hf/pHQmHYjvZqy8GmEryU10VXJlhp5V5t3gozXFbQaKg0t5tS01t5X7R fh9m/rLm64IP9nB8UoVTjsDJPi+aNV8M2dXgPngzIcWdTm9MzAG68+RmU CzvlNWbFrdnSRP42/xiORqJNmybQybrjvvvKrTANjsVUaJqSJd3MPFFF6 m+aOeQRIFSAvwuSm97Q1Aw4jk40q2+U/DJWKCfGBN3spU9tlvivl4aDiG VllU3lzwMVtEFdyPnqEplip2tjPMb1Tn4gz8mGUDPEuP/9RAqRXM73OEA XArTRRDyaaa6SYBok+lRQ9YYk6EkHJWtNbSfJlJ3FDa51SebZtmuzxRdT g==;
IronPort-SDR: KQ6ETag6ibMzoN7h0eR3qkCHJ/tgT7otWPvPFdJ+kYjCpj2PGHpwU8CbfN4GzfLYFFeqPvY8YU cGXYFTQn9VTvLc/tj72h8warxXBiQGniAS7peqRz7gocJeL5Y1xj/106rOXTCvJlsFm2L5piHT GORDI45yAgsXb5/qh2gu7MqG2o/CS1YyK7CBPfSF/YToSiDc3IhdKqpXG/dKDHbC7FvCegCMSu 9f+m6c1LGTi4nXiLASNsPDRUtln8I9FRvkH4RWctk1E0XwaMdmpRcrmKW4fk8pRQpfVBLxmN9/ jao=
X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="1168029"
IronPort-PHdr: 9a23:PxjWohURQD97QcEdbs9mavDUMZrV8LGtZVwlr6E/grcLSJyIuqrYbB2Dt8tkgFKBZ4jH8fUM07OQ7/m9HzBbqsnd+DBaKdoQDkND0Z1X1yUbQ+e7SmTDZMbwaCI7GMkQHHRExFqcdXZvJcDlelfJqWez5zNBUj/2NA5yO/inUtWK15f/2O+94YDcbBtVjzShf7xyMA+2rQLMvcUKnIduMKk8xgbJr3dSdOlby2xkKFCckh3h4su84INv/z5ftv48+MNMS7n2c7g9QbdFEDkoLmc56dHkuhXEUQaB/GYXXH8MkhpPDQjF7RX6UYn0vyDnqOdz2zSUMNPvQ7wsVjus86lkSBnziCcaLDE5633YitZxjK1Avh2soQF0zpPOb4GUMPp+eb7dfc8fSGFcUMtdSzBND4WhZIYJEuEPP/tXr5PlqlUOsxWwGBWsCu3sxD9JmnD40qI13v89EQHf3gwsA84CvGjKoNjzKawcUfq1zK7NzTjbYf9Y2zD96IzMch8/p/GDRqx/ftbSyUU3CgjLk0mfqYv5PzOJ2OgGrm+W7/FgVeKoj24nrx9+oj60ycgylobJhZkYyk7a+iVjwYY1Pty4SEF9YdK+DJRQsCSaOpJwT8g/QG9ooD43xqAatZKhYSQHypoqywTCZ/GHfYWE+B3uWeKJLTtlmH5pYq+zihSu/US61+HxWcq53ExXoidGitXMuG4C2h/P5sWCT/Zw/Fuu1SqV2A3W9+1LPVw7mK/bJpE83LEwmJ8evEDeESDrhkr7irKdeF8+9eiy8evnZ63rppqbN4BplA7zKr8umsmjAeQgNQgOQnSb9fy81LL9+U35R61Hg+AqnKfBrZzVJdwVqKG4DANJzIov8Qi/ACuh0NQChXkLNkhKdw+dg4j3IVHOO/b4Ae2jjFSrlTdn3/HGPrv/DZXRNnXPjavtcaxg50Nexgc/181T6pJaB70bL//+Xlf9tNnCAR84Nwy0zfznCNJ41o4GQmKPAqiZMKfWsVCW4OIgOPeDa5MWuDvmNfgq+eTujX4imV8ccqmp24EbZ2y/HvRjO0mZe2bjgs8dEWcWuQozVPLkhlufXzNIZna9Qb485j8hBIKhF4fDSdPlvLvUlhufJbVXa3xITFeWHj2gI7mgYN8NZT6cZMh7nWpXe6KmTtpr9RaqsAL8wbdsLa6cwSYfqY6pnIxu5+rXkRw0/zF/DOyD3nuMVGB7mCUDQDpgj/M3mlB01lrWifswuPdfD9EGv/4=
X-IPAS-Result: A2GBBABfsJ1e/zGZrQpmgkGBeIJZsG8KAQEBAQEBAQEBBwETHAQBAYZ6NwYOAgMBAQsBAQEFAQEBAQEFAwEBAQKGEwglC4I7IoQqGjcBGh4GQhcPAQQbtyGFT4UYgTiJbYJmgUI+gRGIBGeFIgSOUYkLmiUDB4JEBJdfJZxSj22cawIEAgQFAhWBaIF6cIM6TxgNjj2RY44pgQ+BEAEB
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Apr 2020 10:26:25 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1913.005; Mon, 20 Apr 2020 10:26:25 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "TLS@ietf.org" <TLS@ietf.org>
Thread-Topic: Comments on draft-dt-tls-external-psk-guidance-01
Thread-Index: AdYXH6KSBS1BAI8XTwWXm/Rvqwo8MQ==
Date: Mon, 20 Apr 2020 14:26:25 +0000
Message-ID: <5baf193953c94e3093fda66c8e3baa4d@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bzLaqkObq5p-KYHb4m7y263Z_aA>
Subject: [TLS] Comments on draft-dt-tls-external-psk-guidance-01
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: Mon, 20 Apr 2020 14:27:04 -0000
Here are a few comments gathered from Verisign Labs on draft-dt-tls-external-psk-guidance-01: 1. Sec. 6, requirement 1 states "Low entropy keys are only secure against active attack if a Password Authenticated Key Exchange (PAKE) is used with TLS." "only secure ... if" may be too strong a statement, because there could be other mechanisms for increasing the entropy of a pre-shared key that do not meet the formal definition of a PAKE. Moreover, as defined in draft-barnes-tls-pake, a PAKE repurposes the DH key share to carry a transformed version of the EPSK, so it involves a different architecture than the ordinary process for incorporating EPSKs into the TLS key schedule that is assumed in most of the present draft. If the goal of the present draft is to encompass PAKEs as well as the ordinary process, then the scope of the draft should be broadened to something like "handshakes based on EPSKs, whether through the ordinary process of incorporating them into the key schedule, or through alternate mechanisms such as PAKE where the DH key share is based on the EPSK." Alternatively, the statement in requirement 1 could be rephrased as follows: "If only low-entropy keys are available, then key establishment mechanisms such as Password Authenticated Key Exchange (PAKE) that mitigate the risk of offline dictionary attacks MUST be employed. Note that these mechanisms do not necessarily follow the same architecture as the ordinary process for incorporating EPSKs described in this draft." 2. Sec. 6, requirement 2 states, "Each PSK MUST NOT be shared between with more than two logical nodes." This "MUST NOT" is stronger than the "NOT RECOMMENDED to share the same PSK between more than one client and server" In Sec. 7 and would exclude group PSK use cases that are acknowledged in that section. The requirement is also inconsistent with this statement in Appendix B of draft-ietf-tls-external-psk-importer: "Applications which require authenticating finer-grained roles while still configuring a single shared PSK across all nodes can resolve this mismatch either by exchanging roles over the TLS connection after the handshake or by incorporating the roles of both the client and server into the IPSK context string." If the intent is to restrict use to at most two nodes, then requirement 2 should go even further and restrict use to one node in a TLS client role, and one in a TLS server role. We would therefore suggest that requirement 2 be changed to something like the following: "Unless other accommodations are made, each PSK MUST be restricted in its use to at most two logical nodes: one logical node in a TLS client role and one logical node in a TLS server role. (The two logical nodes MAY be the same, in different roles.) Two acceptable accommodations are described in [draft-ietf-tls-external-psk-importer]: exchanging client and server identifiers over the TLS connection after the handshake; and incorporating identifiers for both the client and the server into the context string for an EPSK importer." (Note that we've changed "roles" to "identifiers" to align with Sec. 7) Related to this, "logical node" should be defined somewhere, e.g., "For purposes of this document, a logical node is a computing presence that other parties can interact with via the TLS protocol. A logical node could potentially be realized with multiple physical instances operating under common administrative control, e.g., a server farm." Alternatively, the term "endpoint," which is used elsewhere in this document, could be used here as well (perhaps also avoiding the single use of "agent"). 3. Sec. 7 recommends that that each node selects one globally unique identifier for all PSK handshakes, but without giving rationale why this approach is preferred for mitigating the attacks mentioned earlier in the section. This may be limiting, because a logical node may legitimately be known to different endpoints by different identifiers: a domain name in some cases, an IPv4 address in other cases, and an IPv6 address in still other cases. We would therefore recommend relaxing this recommendation. 4. General. The draft makes no mention of certificate-based authentication in connection with EPSKs, for instance as described in in RFC 8773, "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key." We understand that use of external PSKs with certificates is out of scope for the design team. Certificate-based authentication, potentially in combination with a DH exchange, can improve the security properties of TLS handshakes based on EPSKs and help protect against both rerouting attacks and impersonation attacks. Is there any interest in adding some guiding text to the document before it's adopted by the WG? We're willing to provide text for consideration. Scott
- [TLS] Comments on draft-dt-tls-external-psk-guida… Hollenbeck, Scott
- Re: [TLS] Comments on draft-dt-tls-external-psk-g… Christopher Wood
- Re: [TLS] Comments on draft-dt-tls-external-psk-g… Hollenbeck, Scott