TLS at IETF 113

Tuesday Session

Agenda

TUESDAY
Administrivia (5min)
Note Well
Scribe: Muhammad Usama Sardar and Rich Salz (sort of) and Mike Ounsworth
(sort of)

WG Status (20min), Chairs

• Action for WG: 8446bis: Check the open PR until the end of the
  week

• Some process changes in FATT [Link to be added later]. If you have
  concerns, provide feedback.

• Adoption of some drafts, pausing on some others (deliberately)

• How deep should the security considerations be?

Discussion about IANA registry entries, standards-track or not, etc.

Thom Wiggers: When you are going for PQ and when not?
Sean: Get registry entries before.
Thom Wiggers: Maybe establish a way for this.
Paul: Tried and failed.

Watson: You don't need an RFC in order to get a codepoint.
Sean: refers to Paul statement

Ekr: Perhaps we can agree on the order, and perhaps we should all try to
be more restrained about answering only Y / N to adoption calls.
Sean: Practical aspects

Working Group Drafts

Well-Known ECH, Stephen Farrell

draft-ietf-tls-wkech

Ready for WGLC
2 open issues: one on definition and ?
Sean: can ask the director reviews for review?
Stephen: we already have it.

Ekr: Any deployments?
Stephen: Just mine
Ekr: Should not ship it as an RFC before deployment

David: CDN setup
David will some comments on the list. WGLC after these comments are
addressed

Rich points out David Benjamin's review.

Extended Key Update, Yaroslav Rosomakho

draft-ietf-tls-extended-key-update

Got a review from Ekr

Extended Key Update may reduce the attack surface.
Security properties: Forward secrecy: RFC7624 mentions static and
dynamic key exfiltration.

• Review 1/4: Confused about which key is compromised: LTK vs.
  symmetric keys

Thom: The property you're defining here is exactly called
"post-compromise security" (and not forward secrecy) for example as it
is used in the Signal protocol. Post-compromise security is with
Ephemeral Key exchange.
Hannes: It is not well-defined.
Thom: It predates the scientific papers.
Hannes: With compromise of LTK, one can impersonate.
Thom: This has been sent to FATT review.

John: Compromise of key A should not allow c

Dennis: Exactly post-compromise security; replace forward secrecy

Ekr: agrees with Dennis

*Authors agree to do this**

• Review 2/4: Conflict resolution
  Martin: Close the connection if you are under attack
  Tiru: ?

Michael Tuxen: If using DTLS, you have to ACK the message else the
client will repeatedly re-transmit if you're delaying your response.

Ekr agrees.

• Review 3/4
  Open question: does anyone object to reducing the number of messages
  we define (by adding a 'type' field)?
  No one raised their hand to speak.

• Review 4/4 ?

• Complete key derivation

Ekr: I did my review pretty quickly and I may have been incorrect. I
know the authors agree with me, but I would like more eyes on that.
(note-taker didn't catch the context)

DavidBen: when you get a new session ticket, you need to know which
resumption secret it's using ... multiple epocs needs to keep around
multiple resumption secrets, unless you drop all but the most recent ..?

Exporters are visible to application but not keyupdate
Yaroslav:
We expect that previous resumption secrets will be invalid.

Thom: It looks like you are deriving the new keys from only the message
transcript of the extended key update messages rather than the whole
transcript. This might be ok, but doesn't that invalidate all the
security proofs for TLS? Could you please derive the traffic keys from
the entire transcript as usual?

Hannes: We could look into that.

Kyle Nekritz: No strong opinion, but want behavior of re-using exported
keys to be well-defined.
Hannes: security vs. performance tradeoffs
Kyle: if we are not forbiding reuse, then why are we rotating them at
all?
Hannes: the current text doesn't forbid reusing them, but it does
invalidate the old ones.

John: May define new API.

Thanks EKR for very thorough review. Looking for more reviewers, and
working on implementations.

EKR: Please keep discussion open and push non-WG docs off if we have to.

Sean: I'm fine with that.

• Review 2/4: "Clashed" response code
  Yaroslav: intend to remove this code.

David: Are we sure it does not cause deadlock with each party waiting
for the other?
EKR: They are lexographically sorted, so you'll know.
David: Ok.
David: Why 4 messages? Are 3 messages sufficient? Yes for TLS, DTLS is
trickier.
Hannes: Agreed in Brisbane, perhaps due to "symmetry"

Valery: Review RFC 7296 where packets are delayed, lost and so on..

Victor: Frequency and delay
Hannes: we don't discuss frequency
Victor: driven by external events. Explain the interactions between this
and Resumption.

Watson: Resumtption always does another key exchange; it's basically
just skipping over the cert exchange. If our model is that we might have
mid-session compromise of the session keys, but not of the initial
handshake, then I think we should honour the resumption ticket. This
gets into the interaction with Exporter Secrets and post-compromise
security, which is messy. That's another area of interaction that needs
to be fleshed out.

Ekr: Extremely uncommon if it exists at all. This raises questions like
"are the compromised session keys somehow held in a different part of
memory from the long-term keys? Or are we considering client compromise
separately from server compromise?" I personally don't know how to
reason about these things very well so it's messy to analyze.

Large Record Sizes for TLS and DTLS with Reduced Overhead, John Mattsson

draft-ietf-tls-super-jumbo-record-limit

Make length field variable
Ekr talks about the tradeoff.

(the Zulip had a great parallel discussion about maximum size limits.
For example QUIC has a 2^62 byte limit)

Martin agrees with Ekr.

ML-KEM Post-Quantum Key Agreement for TLS 1.3, Deirdre Connolly

draft-ietf-tls-mlkem

Applied changes for on-list reviews

Victor: 768 hybrid: Larger ClientHello, have seen small number of
servers hang

Chris P: Can ignore the possibility of decryption failure?
Eric: Ignore it. This is orders of magnitude lower probability than the
transport layer failing and the checksum not catching it. Just ignore
this and treat it the same way as an unrecoverable transport failure.
(someone): The failure mode here is that people spend lots of effort
trying to code for this error case, adding code complexity and
potentially bugs for something that will (statistically) never occur in
the entirety of human history.
Martin: Hash collisions are so rare that people joke that you can code
"IF hash_collision, crash drive head into platter" and statistically
speaking, zero computers will fail, ever. The failure probablity we're
talking about here is orders of magnitude lower. Jus ignore it.
Thom agrees.
David: implementing 1024 in Chrome, but we agree that Recommended=N

Non-Working Group Drafts

A Password Authenticated Key Exchange Extension for TLS 1.3, Laura Bauman

draft-bmw-tls-pake13

General web uses are out of scope.

Ekr: One requirement missing: Fixed-length update
Laura agrees.

Dan proposes pick one; CPace as preferable.
Chris proposes to have FATT look at it before getting too far.
Samir: Key confirmation step out of band.

Watson: OPAQUE
Samir: will look into it

Scott mentions weakness of SPAKE2+, that solving a single discrete log
compromises the whole thing and suggests to look into RFC9383 which
specifies per-used N and M values

Richard supports the draft. We're at the level of mature discussion
where a Call for Adoption is appropriate.
Sean: call for adoption on Thursday.

Dual Certificates, Yaroslav Rosomakho

draft-yusef-tls-pqt-dual-certs

Transition between current and future PKI (pure PQ). When to start
talking about it?
Varies between Private/enterprise PKI and general PKI

Two certs and CV
Presents pros and cons of different options

Bas proposes simple composite and concatenation
Andrei: Does it satisfy BSI requirements?
Hannes: didn't ask BSI yet.

Ekr: Separate chains; one of them is broken and you are not aware of
this? Assign a codepoint.
John agrees with Ekr. 3 PKIs is better.
Hannes: There should not be changes.

Martin proposes to avoid protocol changes. Signature is a concatenation
of two signatures.

Watson mentions interaction cost. It's simpler to use signature
algorithm.

Michael: Pure PQ is fine, if need hybrid then this is good for
flexibility

Jonathan: Exported Authenticators. Classical as TLS and EA for PQC. Does
it achieve the same guarantees?

Dennis: 2 or 3 PKIs may not be a big deal.

Thom: Complexity and downgrade

Stavros: Maybe creating more problem. Every application may need
changes. Complexity in certificate management.
Yaroslav agrees.

Viktor: Composite is simpler and better. Application needs to be changed
to retrieve 2 certificates.

Wednesday

Note Well
Scribe -- Rich Salz, Mike Ounsworth
All non-WG drafts this session See the slides and the drafts

draft-rosomakho-tls-wimse-cert-hint Yaroslav Rosomakho

• Concerns raised (in zulip chat mainly) about privacy, server getting
  user to identify itself
• Chris Patton: supports this, especially with ECH
• Arndt S: WIMSY WG likes this
• Viktor: Does this subsume DANCE work?\, which uses DANE for client
  identities

Certificate Update in TLS 1.3 (10min), Yaroslav Rosomakho

Certificates expire, revoked, etc. and lifetimes are shrinking (on the
WebPKI) and restarting connection can be. costly.

• Bas: it sounds bad if cert outlives connection; do you have
  examples?
  (a few people in chat +1'd this)
• Y: cert private key got compromised but nobody knows, so client
  establishes a session to attacker. __ can't do certificate
  update because __ ??
• MT: I'm going to challenge the requirement. These systems need to be
  redundant and fault-tolerant. Seems unrealistic that you can't
  fail-over once a week. I reject your loss-of-private-key scenario;
  losing a connection is probably the least of your concerns.
  Applications can check cert validitiy period and should do that
  instead.
• Andrei: Other reasons for cert to be invalid beyond
  expire/revocation; not the job of the TLS layer. Server losing it's
  identity doesn't match with the proposed solution.
• Kyle: If requirement is to keep a session open over the transport,
  there are better things to do than modify TLS.
• Watson: Requirement to get new cert from same CA might be a problem.

Reliable Transparency and Revocation Mechanisms, Brendan McMillion

Cert Transparency (CT) in real-world isn't perfect and no collusion
which are needed for CT security. Monitoring CT is hard for "normal"
people. CT log sizes are a problem. KeyTrans logs make it easy to find
things that don't exist and those that do.

• EKR [Zulip]: I'm a little puzzled why we're seeing this proposal
  in this WG. It's not TLS work
• +1 (Watson, MikeO)
• Brendon: because the vast majority of the draft is a TLS extension.
• This is a change in the model, requiring clients to actively check
  with servers, as opposed to looking at data (STH/proofs)
• David Benjamin doc is complicated with multiple proof options. CT
  went through multiple revisions to get things "right" an scalable. I
  don't the draft properly thinkgs about the privacy motivation behind
  the CT decisions. This changes deployment model of every Web server.
  Can we do it in smaller steps?
• Dennis: Too big for TLS, maybe BoF.

Remote Attestation with Exported Authenticators, Muhammad Usama Sardar

One issue is that evidence/signed-data might be old. Idea is use TLS
exporters to generate evidence "now" (and tie it to the session, to
prevent re-use)

• EKR: So the issue here is that what you need to be attesting to
  (among other things) is "The data you are about to encrypt will be
  handled in way X". And that means that you can't allow new
  un-attested binaries to have access to the keys in the future.

Extensions to TLS FATT Process, Muhammad Usama Sardar

Formal methods are hare to learn, small community of experts; how to
make it sustainable? Have threat model, informal security goals, and a
protocol (message exchange, RFC 4101) before adoption.

• EKR: This proposal seems uncessessarily prescriptive for things that
  will not be universal to all drafts; ex.: adding to en existing
  protocol might not need a diagram.
• Watson: Support the goal, not sure every draft has to do this.
• Usama: I meant to write down that this is only for "substantial
  changes", not for all drafts.
• Dierdre: FATT said not a requirement to do all of this.

Implicit ECH, Nick Sullivan

Problem: outdated ECH keys, want to tmake ECH configs without limiting
server choice. Have a signed object with ECH config; trust could be
DNSSEC, certificate, or trust on first use.

• EKR: ECH authenticity is a problem, thanks for looking at it.
  Interesting idea. What if server rejects ECH?
• Nick: (missed, sorry)
• SF: when you generate the EHC public key, you might not have access
  to the signing keys here.
• NS: Sure, they can be de-coupled.
• (someone): This has to rely on an existing PKI or TOFU, those are
  the only two viable options.
• MT: lifecycle of key can be different, or equiv, from the other key.
  I'm in the TOFU camp; you can augment that with DNSSEC things, but
  TOFU is an ok starting point.
• Alessandro Ghedini: We obviously can fine-tune this, but I think we
  should continue discussing it.
  )