[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [50.45.239.150]) (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 (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) 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, 01 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: [73.180.8.170]
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. Jim