Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-external-psk-guidance-04: (with COMMENT)

Russ Housley <housley@vigilsec.com> Wed, 22 December 2021 05:32 UTC

Return-Path: <housley@vigilsec.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 E53143A0DD5 for <tls@ietfa.amsl.com>; Tue, 21 Dec 2021 21:32:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
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 jEXN6l0ZJi3Q for <tls@ietfa.amsl.com>; Tue, 21 Dec 2021 21:32:21 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71DED3A0DD7 for <tls@ietf.org>; Tue, 21 Dec 2021 21:32:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A4613300C5C for <tls@ietf.org>; Wed, 22 Dec 2021 00:27:07 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ULbsZiRDm7RF for <tls@ietf.org>; Wed, 22 Dec 2021 00:27:05 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 32E6E300AC4; Wed, 22 Dec 2021 00:27:05 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <163914043531.6150.11981858059091399999@ietfa.amsl.com>
Date: Wed, 22 Dec 2021 00:27:01 -0500
Cc: IESG <iesg@ietf.org>, draft-ietf-tls-external-psk-guidance@ietf.org, tls-chairs@ietf.org, IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DE7E15AE-BDFB-4C30-9222-2E29F6C6DDFE@vigilsec.com>
References: <163914043531.6150.11981858059091399999@ietfa.amsl.com>
To: Eric Vyncke <evyncke@cisco.com>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/64OFwK-vHUl7A6w68-S_a_ul6Q8>
Subject: Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-external-psk-guidance-04: (with COMMENT)
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: Wed, 22 Dec 2021 05:32:25 -0000

> == COMMENTS ==
> 
> -- Section 4.1 --
> A wild guess (as I do not know the details of TLS 1.3), but if a group member
> is compromised and no ephemeral keys were used, then isn't the attacker able to
> read even the past/recorded traffic ?

The document saysL

   3.  If PSK is not combined with fresh ephemeral key exchange, then
       compromise of any group member allows the attacker to passively
       read (and actively modify) all traffic.

Yes.  For clarity, we can add "..., including past traffic" to the end to make it clear the scope of "all traffic".

> -- Section 5.1 --
> Suggest to expand "PoP".

Okay; will change it to "point-of-presence (PoP)".

> Also wonder about the German eID use case... While the BSI specification allows
> for using PSK, it does not appear as the recommended mode by BSI. I.e., does
> this reference help the case for this I-D ? Suggest to remove it.

Since it is allowed, it could be used even if it is not the recommended approach.

> I also wonder why quantum resistance is not at the top ;-)

There was no attempt to prioritize the examples in any particular order.

> -- Section 5.2 --
> About the IoT "UI", I would assume that some USB ports could also be used. Or
> are USB/bluetooth/... considered as UI ?

We did not consider a USB port to be an user interface.  Even if it were,I think that would fall into TOFU, whihc is already discussed.

> -- Section 5.3 --
> "each pair of nodes has a unique key pair" is puzzling as PSK usually consist
> of a unique key and not a key pair. What am I missing ?

Your point is discussed in Section 4, which says:

   PSK authentication security implicitly assumes one fundamental
   property: each PSK is known to exactly one client and one server, and
   that these never switch roles.  If this assumption is violated, then
   the security properties of TLS are severely weakened as discussed
   below.

In Section 5.3, we try to reinforce this point, and admit that pairwise keys are not always possible.

> == NITS ==
> Section 5.2 "among several node is" (plural ?)
> Section 8 "extend beynond proper identification"

Fixed.

Russ