Is anyone from AWS active on the WG? When I left AWS a few years back,
they had a very active group entirely dedicated to this kind of work, and
any version of TLS is obviously relevant to AWS. Might be worth reaching
out to them.
On Jun 1, 2024 at 1:32:20 PM, Eric Rescorla wrote:
> Thanks for posting this.
>
> It's great to see the triage panel coming together. This is very
> thorough and helpful.
>
> My take-home from this report is that the security properties of
> 8773-bis are not immediately obvious and therefore that prior to
> advancing it we should actually have some sort of more formal analysis
> using a tool like Tamarin/Proverif, etc.
>
>
> I did want to address one point from Russ's response:
>
> > 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?
>
> Fundamentally, the IETF is a volunteer organization and it's up to
> the WG members who are interested in a document to bring it any time
> we have a requirement for a document to advance, the authors and the
> WG need to find a way to fulfill it. This is true both for subjective
> requirements (i.e., document has to be of high quality) and objective
> ones. For example, RFC 6410 requires
>
>There are at least two independent interoperating implementations
>with widespread deployment and successful operational experience.
>
> The IETF doesn't have a mechanism for producing these implementations;
> that's the responsibility of the WG and the community at large, and
> if there is insufficient interest to produced these implementations,
> then the specification doesn't advance. I would note that the
> TLS WG has already held some documents from advancing to PS
> until there was sufficient implementation experience, so it's not
> just about 6410.
>
> Similarly here, if the WG feels that a change is sufficiently large to
> require formal analysis then the WG -- and more specifically those who
> want the work to move forward -- need to figure out how to get that
> analysis done, though of course the triage panel or the broader
> community might help facilitate if there is enough demand or interest
> in the work.
>
>
>
> Some more detailed thoughts on the panel review below.
>
> I did have one question about the format of the report. I see a
> lot of "I statements". I assume these are (potentially) different
> people's comments aggregated together, not all the same person?
> I know it's more work but it might be more helpful if future reports
> were structured in a slightly more narrative fashion.
>
>
> 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 this is the heart of the question: should I be inferring
> anything about the counterparty's identity based on them knowing
> the PSK and if so, what?
>
>
> > 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.
>
> My sense is that because the resumed keys are all derived from the
> original PSK, that they would also be CRQC-resistant.
>
>
> With that said, I don't understand how resumption is supposed to work
> in practice S 5.1 says.
>
> > The "pre_shared_key" extension is defined in Section 4.2.11 of
> > [RFC8446]. The syntax is repeated below for convenience. All of the
> > listed PSKs MUST be external PSKs. 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.
>
> One of the basic assumptions of TLS 1.3 is that the server can choose
> whether to resume or not and the handshake completes either way.
> However, this restriction makes that impossible because the client
> must offer *either* the external or resumption PSK. If it offers
> the external PSK resumption is not possible and if it offers the
> resumption PSK and the server is not willing to resume then
> the external PSK is not used.
>
> -Ekr
>
>
>
>
>
>
> On Mon, May 20, 2024 at 3:06 PM Dei
