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

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

Return-Path: <ietf@augustcellars.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 272243A0E45 for <tls@ietfa.amsl.com>; Wed, 1 Jul 2020 15:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 A-ZuoFlyFgvL for <tls@ietfa.amsl.com>; Wed, 1 Jul 2020 15:07:37 -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 F2DA23A0E3D for <tls@ietf.org>; Wed, 1 Jul 2020 15:07:36 -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 15:07:29 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Christopher Wood' <caw@heapingbits.net>
CC: <tls@ietf.org>
References: <045601d64fea$e0d7f800$a287e800$@augustcellars.com> <da9dd455-c48e-41e0-86d9-46511e69f997@www.fastmail.com>
In-Reply-To: <da9dd455-c48e-41e0-86d9-46511e69f997@www.fastmail.com>
Date: Wed, 1 Jul 2020 15:07:27 -0700
Message-ID: <046301d64ff4$0398fa20$0acaee60$@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: AQJKcycXoPg67pLJAT3vSEDhcRD9xgIIH6r0p/rAmWA=
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/O7uBqFpD4m2Kqjg8il8-xupyz8w>
Subject: Re: [TLS] [Cfrg] Review of draft-ietf-tls-external-psk-guidance-00
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, 01 Jul 2020 22:07:42 -0000

Yes I did mean to send this to tls not cfrg - I had just sent mail there and
did not look hard.


> -----Original Message-----
> From: Christopher Wood <caw@heapingbits.net>
> Sent: Wednesday, July 1, 2020 2:09 PM
> To: Jim Schaad <ietf@augustcellars.com>
> Subject: Re: [Cfrg] Review of draft-ietf-tls-external-psk-guidance-00
> 
> (-lists)
> 
> Hi Jim,
> 
> Before replying, did you mean to cc tls@ instead of cfrg@?
> 
> Thanks!
> Chris
> 
> On Wed, Jul 1, 2020, at 2:02 PM, Jim Schaad wrote:
> > * 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
> >
> >
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
> >