[Cfrg] Review of draft-ietf-tls-external-psk-guidance-00

Jim Schaad <ietf@augustcellars.com> Wed, 01 July 2020 21:02 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E5B523A0D76 for <cfrg@ietfa.amsl.com>; Wed, 1 Jul 2020 14:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bS90fEzDG1LR for <cfrg@ietfa.amsl.com>; Wed, 1 Jul 2020 14:02:22 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A71C33A0D7D for <cfrg@irtf.org>; Wed, 1 Jul 2020 14:02:16 -0700 (PDT)
Received: from Jude ( by mail2.augustcellars.com ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 Jul 2020 14:02:05 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <draft-ietf-tls-external-psk-guidance@ietf.org>
CC: 'CFRG' <cfrg@irtf.org>
Date: Wed, 1 Jul 2020 14:02:03 -0700
Message-ID: <045601d64fea$e0d7f800$a287e800$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
thread-index: AdZP43f5hr+DX2jvQY+xHC7BSOEB0g==
X-Originating-IP: []
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/R9zaZUdzmD4MLngCJEArdQMiUmk>
Subject: [Cfrg] Review of draft-ietf-tls-external-psk-guidance-00
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2020 21:02:24 -0000

* In section 4 there is a statement that switching the roles of servers
which use PSKs will lead to weakening of security properties.  As this is a
common scenario today in situations where you are doing server-to-server
communication, it would be useful to discuss just how and how much this
weakening occurs.  This was a complete surprise to me and I don't know if it
was supposed to be one.  Are there mitigations that can be made?

* In section 7, The first sentence does not read, also It seems a bit
difficult to have a MUST in there when most of the items below are SHOULDs.
That seems to be a dissonance.

* Section 7.1.1 - The idea of having domain name suffixes on PSKs seems to
me to be a bad idea as this would seem to lower privacy levels.

* Section 7.1.2 - There seem to me to be three different places where
collisions will occur.  The importer function could get a collision, there
could be collisions with pre-TLS 1.2 external identifiers and there could be
collision with resumption keys.  There has been a huge discussion about this
in the EMU group and I don't find the text here to be sensible in term of
whether this is or is not a problem.

* Section 7.1.2 - One of the things that I kept meaning to get to and just
haven't done so yet, is dealing with the question of can the TLS Key binders
in the handshake to distinguish between multiple keys that happen to have
the same identity.  Perhaps you should look to see if this does work and if
it is safe.