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 <c...@heapingbits.net> > Sent: Wednesday, July 1, 2020 2:09 PM > To: Jim Schaad <i...@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 > > c...@irtf.org > > https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
