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

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
> >