Deirdre: I can figure out what to do with some on this input, but most of it seems to be aimed at an audience other than the document author.
I can add text related to the authentication and confidentiality goals: - For confidentiality: The session keys remains secure if either the external PSK is not compromised or (EC)DH is unbroken. The assumption is that (EC)DH will be broken if a CRQC is invented. - For authentication: The public key certificate authentication works as in TLS 1.3, and this extension add the condition that the party has possession of the external PSK. The details of external PSK distribution are outside the scope of this extension. Responses to other points in line... > On May 20, 2024, at 6:04 PM, Deirdre Connolly <durumcrustu...@gmail.com> > wrote: > > Hello! We're back with some feedback from our triage panel on 8773bis. > <https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis/> We had > participation from all members of the panel this time around (🎉). > > Some high-level takeaways: > > - agreement that more clarity in the document about the intended security > goals is needed > - support for a proper security analysis to shore up the security arguments: > for authentication properties, a Tamarin analysis may do > > ------------------------------------------------------- > > Here is a summary across all participants: > > On changes made by the 8773bis draft to TLS 1.3 and on the draft itself: > > The draft adds an extension to negotiate a handshake using both a PSK and > certificates for authentication. The draft makes specific claims around PQ > confidentiality if the PSK is secret and forward secrecy when the PSK is > destroyed. The claims the draft makes around authentication based on the PSK > aren't clear to me on the first reading and would likely need some refinement > prior to analysis. > > I think the draft could be a little more precise in what it's trying to > achieve, which would also help the security arguments. > > I agree that the draft could be clearer on what the security goals it's > trying to achieve are. > > The language in Section 7 about the assumptions on the PRF is not quite right: > > > This extension provides the desired protection for the session secrets, as > > long as HMAC with the selected hash function is a pseudorandom function > > (PRF) [GGM1986]. > > It should actually be assuming the dual PRF security of HMAC, since the TLS > key schedule uses the PSK and other chaining inputs sometimes in the first > input of HMAC, sometimes in the second. I would appreciate some help getting the wording correct. > the informal security arguments in some related documents (eg > https://datatracker.ietf.org/doc/html/rfc9257, > https://www.rfc-editor.org/rfc/rfc9258.html ) seem much better worked out. I am co-author of one of the referenced documents, and I have no idea what changes to the document are desired. > More clarity about the exact claimed additional security is required. > > I found the RFC unclear on how the extension should be used in subsequent > sessions. They wrote: "Since the "tls_cert_with_extern_psk" extension is > intended to be used only with initial handshakes,…”. So let’s say you use the > extension in a first session with an external PSK + cert. Must the PSK > generated from that session ticket be used in subsequent sessions with their > extension , i.e. cert + psk, or can it go back to “normal mode”, i.e. psk > only without cert? I’m not sure how this behaves specially w.r.t. to their > goal of being safe against CRQC. I am confused by this one. The resumption_master_secret is computed as part of the initial handshake, and the external PSK is an input to that key schedule computation. So, all session tickets depend on the external PSK. That is, the external PSK imapcts all of the resumption PSKs that are computed after the initial handshake. > Does the draft invalidate the previous security analyses? > > Yes. Although the draft has an informal sketch that it doesn't make the key > derivation in a particular handshake 'worse', this doesn't immediately rule > out any awkward cross-handshake interactions. RFC 8664 uses a constant value for the initial handshake. When this extension is present, that constant is replaced by an external PSK. What cross-handshake interaction? Please explain. > This is a reasonable extension to TLS 1.3 and can be done in a way that does > not affect the existing security guarantees of the protocol. I am curious > whether using such a PSK breaks the privacy guarantees of ECH, and whether > those two extensions are compatible. ECH did not exist when RFC 8773 was written, so that was never explored. However, I cannot immediately think of anything beyond the privacy considerations in Section 8. > The extension's "security argument" in the extension's text is invalid: it is > not obvious that this extension only improves security. I don't immediately > see how it would degrade base TLS security, though a proper analysis would > make me more confident; I'd be wondering how the "context" of this particular > mode is clearly separate from (preventing message confusion), and carried > through (transcript/state towards e.g. resumption/post-handshake > authentication), w.r.t. other modes. It could well be that in the presence of > an active attacker, the new mode doesn't offer *additional* security because > of its interaction with similar modes. In such a case, the extension would > offer little benefit. Invalid? I understand you want to explore these other items further, but where is the informal analysis flawed? > Does the change merit an updated analysis? > > I think so. Although I like to think the TLS1.3 key derivation is pretty > robust, it's hard to think through the various types of handshake and how > they could be composed by an attacker - especially when the PSK might be used > in multiple modes by multiple parties. > > The main question to ask, other than whether this extension breaks prior > analyses, is what are the new guarantees it provides: that will indeed > require new analysis. > > I see much more need for analysis when it comes to the authentication > properties of the PSK (psk/cert combination), whereas the secrecy (assuming > authentication is a non-goal) is much more straightforward. Who will perform this analysis? I asked a researcher to perform such an analysis, and the response was that it is too simple to get a paper. Now waht? > I agree with the above. > > I'd delineate between confidentiality and authentication, and then be clear > about to what extent hybrid security is being expected: > > - For confidentiality: I guess hybrid confidentiality is desired, meaning > that session keys are secure if either the external PSK is unbroken, or ECDH > is unbroken (and if the ephemeral key exchange is actually hybrid > traditional+PQ, then it's actually a 3-way hybrid) > > - For authentication: Is there a desire for a hybrid authentication property > based on the external PSK? Or is one only relying on the public key > certificate for authentication? > > As for the confidentiality analysis: the fixed key schedule already provides > locations for putting all the relevant inputs in and that's part of the > existing analyses of TLS, so I don't think you'd get any surprises there. I understand this part. I responded to this at the top of this message. > The current security argument is insufficient and there should be a > meaningful security analysis. Who will perform this analysis? See my comment above, > If so, what type / scope / effort is required? > > Symbolic analysis (Tamarin, ProVerif) would be suitable for identifying / > eliminating cross-protocol attacks. Extending the existing models seems > feasible. I am unclear what you mean by cross-protocol attacks? Are you talking about different TLS sessions associate with different applications using the same PSK? Are you talking about the same PSK being used with TLS and some other security protocol? Or, are you talking about something else? > For the authentication analysis, I think here a Tamarin-like analysis might > be useful for checking undesirable interactions; for example, could anything > go wrong if a single PSK is used both as a traditional PSK but also as an > external PSK? In RFC 8446, the resumption PSK is computed as follows: HKDF-Expand-Label(resumption_master_secret, "resumption", ticket_nonce, Hash.length) And, the associated identity is the ticket field in the NewSessionTicket message. I am not seeing how this could happen, especially since the specification says: If a resumption PSK is listed along with the "tls_cert_with_extern_psk" extension, the server MUST abort the handshake with an "illegal_parameter" alert. Russ
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
