Sean and Joe: The revision to address Ben' comments has now been posted.
I believe that all WGLC comments have been addressed. I think this document is ready to go to the IESG. Russ > On Jan 22, 2021, at 3:27 PM, Russ Housley <hous...@vigilsec.com> wrote: > > Ben: > > Thanks for you review and comments. > >> We've only had one review in response to the last call so far, I'd like to >> see a few more reviews of this document before moving it forward. Are there >> any volunteers who can commit to a review in the near future? >> >> I've reviewed and have only a handful of minor comments. >> >> Section 1, opening: Password and key comparison seems rather weak, unless >> low-entropy PSKs are used. If low-entropy PSKs are a focus, then perhaps >> make this clearer, which will simultaneously strengthen the comparison. > > There is guidance on many other aspects of security as well. Maybe this > comparison is setting inappropriate expectations. Maybe the first paragraph > should avoid the comparison altogether. I suggest: > > This document provides guidance on the use of external Pre-Shared > Keys (PSKs) in Transport Layer Security (TLS) version 1.3 [RFC8446]. > This document lists TLS security properties provided by PSKs under > certain assumptions and demonstrates how violations of these > assumptions lead to attacks. This document also discusses PSK use > cases, provisioning processes, and TLS stack implementation support > in the context of these assumptions. It provides advice for > applications in various use cases to help meet these assumptions. > >> Section 4, "These keys do not provide protection of endpoint identities (see >> Section 5), nor do they provide non-repudiation (one endpoint in a >> connection can deny the conversation)": Perhaps relate to other modes of TLS >> which do provide such protection. > > I suggest adding: > > Protection of endpoint identities and protection against an endpoint > denying > the conversation are possible when a fresh TLS handshake is performed. > >> Section 4, "If this assumption is violated": The assumption has two aspects, >> namely, "each PSK is known to exactly one client and one server" and "these >> never switch roles." The following paragraph explains what happens if each >> PSK is known to more than one client, server, or both. But what if roles are >> switched? Whilst maintaining the former aspect of the assumption. > > The only cases where that I have come up with where it is possible for the > client and server to swap roles (like TLS between to mail servers) do not > actually cause any trouble. If a browser and a web server got confused about > their roles, it could be a problem, but that does not seem likely to happen > either. Does anyone have a suggestion here? > >> Section 4, "then the security properties of TLS are severely weakened": >> Perhaps add "as explained below" or similar. > > Good idea. Added. > > Russ >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
