TLS at IETF 117

TLS Working Group Agenda - IETF 117
Wednesday, July 26, 2023, 13:00 - 15:00 PDT
Chairs: Christopher A. Wood, Joseph A. Salowey, Sean Turner
Notes: Rich Salz, Chris Inacio

Administrivia (5 minutes)

Blue sheets / scribe selection / NOTE WELL / Meeting Tips (please sign
in via the onsite tool)
Agenda revisions? None

Working Group Drafts (60 minutes)

A well-known URI for publishing ECHConfigList values, Stephen Farrell

• Asked if this should be merged with the ECH SVCB doc? Nobody said
  yes.
• Ben S.: ALPN may (or may not) be fixed in the current draft;
  according to 1/3 vs 2/3 of authors.
• Plan to edit draft to NOT support different ECH values from same
  docroot.
• Draft authors will make sure to address #12 so that ports other than
  443 will work.
• Next draft might be final, still waiting for ECH draft to progress.

ECH deployment update, Dennis Jackson

• Public info look at telemetry.mozilla.org See ECH is faster for
  lowest 25% and slower for fastest %25. Get additional roundtrip if
  ECH config changes, FFox is seeing much more of this, working to
  find out why.
• Moving to hard-fail, found one site with old stack that broke on ANY
  greasing who will be fixing by the fall.
• Chrome 1% trial maybe present next IETF; FFox to do 1% trial next
  week.
• Draft will move to issue-closing mode, goals is to be done with that
  by 118 so hopefully to IESG by January. There are some big issues
  (e.g., padding on the server) that might just be closed.

Individual Drafts and Presentations (Remaining Time)

Abridged Compression for WebPKI Certificates, Dennis Jackson

Tim Hollebeek: upcoming changes will standardize cert profiles even
more. Work with CA/B Forum.
Watson: Security issues? Dennis: Yes, but not going to look at how certs
manage root stores in this draft.
Compression (looking at Tranco top 100K) shrinks cert chain from 6K to
1K
Seeking adoption.
EKR: Concerned about draft specifying things as a procedure, is that a
concern? (e.g., when to fetch CCADB entries). ADs to talk about that
within the IESG.
Deb: Have you thought about private enterprise using this?
Dennis: Could do it, by getting code points
Deb: Put the compressed objects into CCADB?
Dennis: yes, perhaps we could
Kyle: roots will change more often, outdated clients, cross-signing --
all seem like issues.
Jonathan: make sure to put that CRIME attack isn't relevant
Martin: Focus on one database for now, don't wait for IESG to decide
process (needs broader discussion anyway). Existing code point
registration just works now if you want to do a private enterprise
version of this, but can address that more completely later.
Orie: if you generalize this as building a dictionary based on
transparency information, this has possible uses in keytrans, etc.
EKR: Remember that client can support multiple encryption schemes
Ben Schwartz: Privacy concerns about exposing dictionaries as
fingerprinting, etc? (Martin recording an issue on this)
Dennis: Intent is for "all" browsers to to base support the same
dictionary. Enterprises have a variety of configuration controls, this
would be just one more.
Ben: Okay, just think about the issue. Maybe we can adopt this in CTLS
somehow. Twobyte codespace isn't big enough for all enterprises, maybe
short size is reserved, longer range for easier use.
Bas: Numbers on compression costs?
Dennis: zstd varies about 100 bytes from longest to least-CPU.

Chris: Meetecho poll on adoption, will confirm on the list.

TLS 1.2 is Frozen, Rich Salz

Ounsworth: What if a catatrophic flaw in TLS 1.2 is found, would IETF
then be updated?
Salz: Not sure, might say stopping using 1.2

Hoyland: not "MUST TLS 1.3", "MUST TLS 1.3 or newer"; otherwise have to
update all the RFCs saying specifically 1.3

Yaron Sheffer: Many enterprises are stuck with TLS 1.2 through inertia,
specifically for service-to-service traffic. Freezing the protocol will
prevent them from adopting important enterprise-relevant work, such as
efforts on workload attestation.

David Schninazi: your draft is trying to do 2 things: (1) a BCP type
thing of don't write drafts using TLS 1.2, use 1.3 (2) DO NOT TOUCH 1.2;
any RFC can update any previous RFC, so if there is a catastrophic 1.2
flaw, then any future RFC can just replace the text in this proposed
RFC. Instead a charter update might be more impactful, but even then,
probably not necessarily.
Salz: Trying to capture sentiment of the working group and message that
to the outside world; but maybe it isn't the true sentiment

Watson Ladd: Support this draft. Likes the idea of capturing our
reasoning and sending the message outside the WG is useful.

Ben Schwartz: Maybe the right word/phrase is "feature freeze" instead of
"do not touch" to send the message that we're not planning updates to
1.2

Florence D: there are enterprises still using TLS 1.2 because they are
relying on 1.2 features; but this concerns me that even enterprises
sensibly using 1.2 and they come wanting/needing a new feature they get
turned away.

Hannes t: the writing conflates what (1) what the group wants to work on
and (2) [missed it]
Salz: that is a fault of the writing

Deb Cooley: it pains me to say this, but some enterprises still do
really need to run 1.2 and we need to support that and it will take time
for them to get to 1.3

ekr: the current charter already is discouraging of updates to any old
versions of TLS; not sure if we need the RFC and then we would still
need the charter update

Nalini: there's a non-zero number of enterprises using 1.2

Arnaud T: we speak about enterprises, but enterprises are generally not
in this room; polled room of energy providers about their roadmap for
next 5 years; and they responded about their roadmap for next 50 years

Roman D: I think we should split them and how to use any guidance into
UTA and split the ideas into 2 separate documents

David S: confused about conversation, that features of 1.2 that people
use are considered bugs and thats why they're removed from 1.3; people
can bring those features back as proposals; but it won't likely get
included in browsers or libraries because developers are working on 1.3

Deb C: just because I said poeple are using 1.2 features doesn't mean
that I agree with them; a lot of enterprises have to buy products, and
so it has to be in a product to purchase

Yaron S: 1.2 useage is not the funny stuff, its service-to-service
traffic that's still 1.2; 1.3 is not in the

Watson L: we need to send the message that you need to move, and the
word is "depreciate" (and from the crowd) the word is "deprecate" and we
need to send that message after 5 years

poll 57 for 14 against adoption of "1.2 is feature frozen"

Rich will issue a new draft before asking for confirmation on the list.

Update on post-quantum signatures (from NIST), Bas Westerbaan and Thom Wiggers

There aren't any good, performant and small, signature algorithims yet.

See https://pqshield.github.io/nist-sigs-zoo for some tables.

EKR: Performance is not good; is it getting better?

Thom: Still all over the place; one mechanism is seven minutes.

AOB Topic: Jonathan Howland

Discussion in HTTP about using exported authenticators. Possibility of
client just client certificate without being requested by server. Can
you think of a (security) reason not for him to write a draft explaining
this?

Nick: we did have "unpromoted" mode from the exported authenticators. We
removed it because it didn't match up with TLS proofs or security; there
are reasons we took it out, not necessarily impossible tho.

Jonathan: I think it was leaking client cert if done during early data;
we'd say "don't do that."

Chair wrap-up

Twice in a row we finished early.

Look on list for some WGLC emails.