I have changed the tags on this draft to "WG Consenus: Waiting For Write-Up”. I will complete the Shepherd Write-Up, review it with the authors, and forward the I-D to our AD.
spt > On Feb 20, 2021, at 20:27, Russ Housley <[email protected]> wrote: > > 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 <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/tls
