> -----Original Message-----
> From: Mohit Sethi M <mohit.m.se...@ericsson.com>
> Sent: Monday, July 6, 2020 3:10 AM
> To: Jim Schaad <i...@augustcellars.com>; draft-ietf-tls-external-psk-
> guida...@ietf.org
> Cc: tls@ietf.org
> Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00
>
> Hi Jim,
>
> Thanks for the review. A clarifying question in-line.
>
> On 7/2/20 12:02 AM, 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.
>
> I think you are referring to the PSK identity and not to the PSK.
>
> As you know, the Network Access Identifiers (NAIs) used in EAP typically need
> the domain name suffix for roaming, federation, etc.
This is true, it is also true that EAP is very strong on saying that if you
have a choice, always send an anonymous version of the NAI if you have to do it
in the clear. This means that the domain can be used for correlation, but you
do not have the full identity for that purpose.
I think that the EMU group is going to need to look at what level of privacy
protection it is going to desire when using a PSK, but in that case there is no
need for having a domain suffix as that information is provided elsewhere.
This might require keeping the TLS tunneling as an option to deal with passive
attacks.
>
> I would like to understand the nature of the resulting privacy loss. Is it
> that a
> passive attacker can now easily determine the server which issued the PSK
> identity (and the server where it will eventually be used)?
While it I true that at least some of the privacy information has already been
leaked in the PSK case, you know the address that is being talked to and the
PSK identity that is passed. If you look at using thigs like ESNI, doing this
would appear to potentially give away the very information that is being hidden
in that case.
The other problem with having domain based KIDs is that you could easily get
some amount of correlation between the KIDs that are assigned in different
domains. You could end up with mohit.ietf and mohit.amazon and it would be
quite reasonable to assume that both of those identities are going to be for
the same entity, just in different domains.
Jim
>
> --Mohit
>
> >
> > * 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
> >
> >
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
