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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
