Thanks, Martin! I agree with your point about the external PSK. I filed this 
issue to track its resolution:

   https://github.com/tlswg/external-psk-design-team/issues/76

I'll discuss the larger redundancy concern with the authors and see if there 
are some quick fixes to be made.

Best,
Chris

On Wed, Nov 3, 2021, at 5:27 PM, Martin Thomson via Datatracker wrote:
> Reviewer: Martin Thomson
> Review result: Ready with Issues
>
> This document addresses some of the less obvious aspects of how pre-shared 
> keys
> can be used in TLS.  A lot of this advice isn't specific to TLS, but it is a
> helpful document.  For someone who might be deploying a protocol that relies 
> on
> TLS - or might rely on it - the document is a useful resource.
>
> My only concern overall, and it is a vague concern, so I don't think action is
> needed, is that the document could probably use a little trimming.  There are
> some parts of the document that are less useful than other parts.  For 
> example,
> the bit about who has the PSKs is great (one server, one client, don't swap
> roles); but it is repeated a little across multiple sections.  The same 
> applies
> to a few of the other points.  It is probably not worth trying to edit the
> document down so that each point is made just once, because it isn't that bad,
> but a shorter document would be more impactful.
>
> A specific concern is the somewhat offhand way that early data is treated.  
> The
> only mention is in a throwaway: "primarily for the purposes of supporting TLS
> connections with early data" buried in a bullet in Section 6.  This is a 
> pretty
> big topic and having absolutely no mention seems odd.  I do think that it 
> needs
> some treatment in the document.  When early data is used with an external PSK,
> the only additional source of entropy that provides key diversity is the
> client's random value, which puts a lot of weight on that value containing
> sufficient entropy.  In this case, even if the PSK is good enough, the entropy
> in the random is significant as it is what ensures traffic key diversity if 
> the
> PSK is reused.  Reusing a PSK for early data also likely leads to poor
> anti-replay performance if the random is not good enough.
>
> I have to apologize to the authors for missing this when it went through the
> working group.  Fresh eyes and all that.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to