Tuesday, March 19, 2024
Tuesday Session I, 9:30 - 11:30
Chairs - Deirdre Connolly, Sean Turner, Joe Salowey
Minute taker: Rich Salz, Hannes Tschofenig
The document is currently waiting on Sean to process errata. We have to
process them before going forward. Deirdre has to act as a chair of
these documents.
Some people use the errata process for commenting on the draft.
Is in last call till the end of the month. Discussion has been "robust".
Ekr: I have not seen anything on the list that is a problem to handle.
(Sean: It is not clear which AD will be reponsible for the TLS group.)
Status update: No registration requests have been rejected.
If it is standardized in the IETF, the TLS group should know about.
Martin: It is still OK for other WGs to request a code point.
8447bis authors have a bit of wordsmithing to do to clear up the
misunderstanding.
Rich: Short update on extensions
Sean: RRC extension registration has been pending till two interoperable
implementations have been written. That has happened and now we can move
it forward.
Rich: short update on ALPN
Mostly unchanged - reduced the groups down to two.
Two issues:
Deirdre: Could you confirm whether the drafts have updated the new
terms? It does not matter whehter the TLS key schedule is beautiful. We
can basically get away with the concat in TLS because it is already
hashing in public information exchanged.
Martin: If the FIPS certification comes in, we can ship the document.
Ekr: Agree with Martin. I would like to hear about the deployment. If
people are using the code point already, then get this out of the door.
Scott: If NIST makes a final change then we have to make changes.
Denis: Chrome announced today they are going to release an experimental
version. Firefox is shipping in nightly currently.
WGLC completed. Stalled on chair actions and align with RFC 8447bis (and
"D" value for discouraged).
Joe goes through a proposal for classifying key exchanges (with
recommended, not recommended and discouraged).
Martin: I would put "N" to FFDHE. ECDH should be "D" because it is not
good practice.
Rich: I would change FFDHE to "D" with a 8446-bis rather than in this
document.
Quynh: I think "D" for FFDHE is a bit strong. It depends on the group
size.
Martin: FFDHE in 1.2 is busted. In 1.3 it is (probably) OK to use. -->
In 1.2 we should discourage it.
Joe: Currently we discourage according to 1.2/1.3
Dvid: FFDHE groups in 1.3 are OK with the FFDHE ciphersuites in 1.2 are
NOT OK.
Ekr: Agree. That solves the issue.
Static DH Client Certificates: Currently the draft does not mention
anything. Should we discouraging these or leave them out of the draft? I
think we should discourage them.
Sean: I see a +1.
Proposal to formalize to get a triage for formal analysis of TLS 1.3.
There have been concerns about missing formal analysis for RFC 8773bis.
If there is something new, we run it by a group of expert and ask them
whether the spec needs a formal analysis. Including their feedback as
part of the "adoption call".
If the document changed significantly between adoption and pre-WGLC, a
second look by this group of expert may be requested.
The panel members could be "refreshed" on a regular schedule.
This analysis may not just be Tamarin (for formal method tools) It could
be involve other techniques, depending what is most
appropriate/favorable.
Scott: It may not be sufficient to check whether the extension breaks
something. There may be new security goals. Exanple: Extended Key
Update. Is this on the table?
Deirdre: Yes.
Ekr: This is a good idea. I also agree with Scott. We shouldn't do
things we do not have confidence in.
Jonathan: Disagree with Scott, the extended key update, I think, breaks
the Tamarin. When are we done with the analysis: We may not get the
analysis published.
Advertising the research group in IRTF.
Deirdre: It is up to the chairs to find a suitable expert and to
determine the timeline. Do we require publishing this work? No.
David: There are two parts to this: (a) Outreach - Lead researchers to
do research. We should do more in the IETF. (b) How does this fit into
our process and at what level does this become blocking? I fear the
potential for deadlock. I cannot see this being a way to block work. If
a student gets distracted, we will be blocked.
Deirdre: The WG will decide about whether it will block something. In
the practice it will likely be a back-and-forth. It should not work as a
way to throw work over the wall.
Stephen: Good idea. Echo was Jonathan said. I am the other co-chair of
the formal method group. I am not OK to have the triage group to block
the work. It is OK to have the chairs block the work.
Deirdre: The triage group only gives their opinion and their estimate
about the duration of the work.
Stephen: Go ahead and do it. Don't worry about blocking.
Arnaud: Like the intention.
Christopher Patton: This is a good idea. I am also concerned about
changing processes too much. At the start, I would apply the same level
as today. I would like to involve the people doing the analysis in the
design process.
Deirdre: I also want to involve students early on.
Plaintext limit of 2^14 creates problems.
Suggestion to increase the limit to 2^16.
Increases performance.
How? TLS length field is a uint_16. Record Size Limit extension allows
a maximum size of less than 2^24 bytes.
This draft defines a flags extension to negotiate a size of 2^16 - 257
bytes in TLS 1.3 (with 256 bytes being the maximimum padding size).
Ekr: This is a worthy goal. I am not sure about the design details but
we can figure this out later. We should adopt it.
Kyle: This is useful for data center networks.
Alex: Do you have some of the performance metrics?
Should we adopt this based on performance grounds if we don't have
performance data?
Stephen: What happens if this is implemented badly? Would this have an
impact on traffic analysis?
John: Haven't thought about that. In 5G core signaling traffic
interfaces, traffic analysis is not a big thing.
I am not opposing.
Martin: I share the concern from Alex. In HTTP 2 we had a similar
discussion. I believe there are diminishing returns. Use a record size
scaling extension (by any number of bits).
Ekr: Asking Martin for the details about the solution.
Kyle: Agree with the step size of 2x / 4x since it also make it possible
to use in-place encryption with fewer tags.
Sean: Will work with the authors on what goes into the draft.
It is hard to distinguish bots. We would like to send certificates and
the client authentication has to be initiated by the server.
Proposal: Send a single bit when a client certificate is available.
Suggests a TLS flags.
2 interoperable implementations.
Sean: Last time we had some interest but there were some questions.
Ekr: I would like to see enthusiasm.
(Rich taking notes. Will not be as complete as Hannes has been)
Motivation is long-lived TLS connections. Exmaples include securing
telco signalling traffic, industrial factory/IoT.
Got a great deal of feedback on the design and the details are quite
different for -01:
Questions:
Scott: I'd perfer it be done completely in the TLS layer. Something to
think about is what if both sides ask for new key at the same time?
Hannes: Feedback on -00 draft was "don't change TLS state machine" So
really need the WG to provide input/consensus here.
Dennis Jackson: I have concerns about the changes, but haven't had a lot
of time to look. I think you don't mean "perfect secrecy" but rather
"post-compromise security" Concern about mixing layers, suppose a
middlebox terminates TLS and is endpoint is oblivioius.
Hannes: Might be caught between terminology changes (followed what IKEv2
uses), but happy to change. We mean ECDH for key exchange. As for
layering, I take the point; the WG would decide.
John Matteson: I think the -01 draft goes in the wrong direction (mixing
the layers). Concerned about the "static key"
Hannes: it's an ephemeral key, generated for the connection and shared
during the connection start.
Jonathan Hoyland: I do like the app-layer style because, while it breaks
the proof (as does the -00 version). But this is very similar to the
extended key schedule that I proposed pre-pandemic. That doesn't break
the Tamarin proofs and provides the same results.
Both agree: need to discuss the keys, guarantees, security proof.
David Benjamin: I think HPKE should be just key shares, and that I was
perhaps understood and that authenticated exporters aren't right.
Hannes: TLS WG did auth exporters, not sure why it is out of favor now.
I'm not wedded to -00 or -01 design.
[Discussion of the one/mixed layer trade-offs]
Kyle Nekritz: A new alert that says "close connection and immediately
resume" seems like it would greatly simplify things.
Hannes: Prefer to not interrupt the communication, but I am in favor of
simpler designs.
Link to the repo:
https://github.com/dconnolly/draft-connolly-cfrg-hpke-mlkem
Rich: Everywere in the TLS we are doing hybrid.
Deirdre: In LAMPS we are not.
Rich: OK. I am not saying it is too fast but it is not consistent
throughout the IETF.
John: I am supporter of this work. We want to support it to our
customers. This is super simple: just register the codepoint. There is
no RFC needed.
Ekr: I agree with John. I don't feel qualified to have a strong opinion
though I'm a little less bullish about it than you are.
Deirdre: This is not about complying CNSA 2.0; I trust it enough to make
it an option.
Scott: I strongly support this work even though I am a co-author of the
hybrid draft.
Stephen: I think this is a terrible idea. The best solution is a note to
the draft to never do it.
Quynh: We are fine with hybrid and a standalone PQ. we are not talking
about security of the ML-KEM here. If you don't feel good about it, then
don't use it.
Martin: This is a distraction. I would rather see this go as an
individual draft.
David: It takes time to publish this document is not an argument for me.
The important part is when people use it. Get a code point and let
people use it. If they are use, later get an RFC.
Sean: It seems that we can get a code point for this draft.