Minutes IETF116: tls: Tue 04:00
minutes-116-tls-202303280400-00

TLS Working group at IETF 116

March 28th 2023

========

Agenda bash

Stephen Farrell (SF): ECH: doing good things; getting interop testing
results, but would like to know results about more results.

Dennis Jackson (DJ): running tests in Firefox beta/nightly, hoping to
publish within a few weeks.

Alessandro Ghedini (AG): Cloudflare running experiments; no real issues
or broken traffic. No timeline for publishing results.

Rich Salz (RS): Has anyone asked the HTTP side of this is? The service
based records?

SF: In order to get code upstreamed it would be helpful to have an RFC.

SPT: To get included into OS things you need an RFC number. It's a
balance between more testing and getting it published quickly.

Ekr: If the experiments look good, the next thing to do is to "turn the
knob". Cloudflare is running this, but we'd like to get more input from
other people who are interested in running on the server side.

Kyle Nekritz (KN) (Zulip): Meta will have some ECH results in the next
couple of months too.

I-D presentations

8447bis

Joe Salowey (JS) presenting.

Any questions for Joe before WGLC?
-none-
Ok, we'll proceed to WGLC.

cTLS draft-08

Ben Schwartz (BS) presenting.

Richard Barnes (RB): there are very early implementations, they'll need
updating with the breaking changes.

Hybrid key exchange in TLS

Scott Fluhrer (ScF) presenting.

Mike Ounsworth (MO): which combiner function to use will have related
discussion in CFRG and likely also in PQUIP. My opinion is that it's
fine for the TLS hybrid keyex draft to note that it deviates from CFRG
guidance, and why, with security analysis, and that's fine.

Martin Thomson (MT): Keep simple combiner is already well documented in
this draft about what the constraints are here that justify it. Huge
performance impacts to the extra hashing.

Bas Westerbaan (BW): in favour of the current combiner.

Jonathan Hoyland (JH): Can we not assign a codepoint, but not publish an
RFC until we have the final draft for Kyber?

Russ Housley (RH): Advocating for more robust combiner: codepoints will
come along later that define less robust KEMs, so we should define a
combiner strong enough to handle whatever comes later.
Note: we only have guarantees about IPR on the final NIST spec.

Ekr: RFC should have no Code points, issue draft to allocate code
points. Minimizing hashes is nice but not critical (we already have a
lot).

Chris Wood (CW): consensus to mint an -00 to get early Specification
Required codepoints, but otherwise wait for NIST.

SPT: on the KEM combiner point, we'll wait for CFRG discussion.

ECH and SVCB

Benajamin Schwartz (BS) presenting.

David Schinazi (DS): Why did you choose this option between adding this
text into the ECH draft vs making it its own draft?

BS: As a practical matter I think I did it this way because I could do
it myself, without coordinating with the ECH authors. They are also
fully separable.

DS : Makes sense, I support adoption.

AG: I think it makes sense as separate drafts. Don't care if we do it
this way or in the ECH drafts.

Eric Orth (EO): It all looks good to me. No opinion on separate vs
combined draft. Move forward.

RS: It should be a separate draft. The target audience is not just TLS
but all the DNS community.

SPT: Unless there are any violent objections we're going to do a
consensus call on the mailing list.

Any violent objectors?
-none-
Ok, we'll proceed with consensus call.

Merkle Tree Certificates

David Benjamin (DB) presenting.
Core idea: sigs in tls are gonna be a wholesale mess to migrate to PQ.
The marginal cost to overhauling the whole thing is as low as it'll ever
be. This is not a full X.509 replacement in itself.

BS: I think of it as "If we have to do merkle signatures for PQ reasons,
we might as well unify that with the CT merkle tree".

RB: This is similar to STH discipline. Why would this not founder for
the same reasons.
DB: This cannot be the only mechanism, emergency rekey needs to be
possible, for usual cases of renewal this trade-off would be OK.

JH: Do you have a mechanism for what signatures to expect?
DB: that is the wrong way to think about it, we're not logging X.509
certificate, this is independent from X.509 certs. (ie there are no
signatures here).
JH: do we need transparency server auditing? How do we detect a lazy
transparency server that doesn't bother checking anything$?
DB: out-of-scope for this draft. We don't currently solve that problem
in CT in general, so let's solve that for both places at the same time.

Paul Wouters (PW): Just put the keys in DNS.

SF: What's the mechanism to get this to a stable draft state?
SPT: we need to huddle with the ADs.

Compact ECC encodings

John Mattson (JM) presenting.
JM: are compact representations useful to cTLS?

RB: initially cTLS had some compact representations, but eventually it
got too complicated and removed it.

MT: We don't need to stop (registering codepoints?) as a result of 8447.
This seems like a reasonable thing to do.

SPT: anyone disagree with doing this?

Ekr: This is conceptually good, but details need to be thought about.
The real question is that this is only valuable if people want to do it.

SPT: let's give this a couple month break to deal with current WLCGs and
revisit this before 117 given that there's no burning urgency for this.

NULL encryption and non-FS PSK dont-dont-dont

John Mattson (JM) presenting.

MT: Point of clarification: H2 doesn't prohibit non-ephemeral keyex.

Ekr: Two points: 1) now that we're deprecating DHE, we're alreday there.
2) This document should forward discourage NULL ciphersuites.

MT: It seems a bit odd that we're allowing so much RSA, but prohibiting
ffdhe. Do we have to fix 8447 to say that registering a NULL ciphersuite
automatically gets a 'D'?

Ekr: You can't register a group.

Remove packet number encryption in dTLS 1.3

Boris Pismenny (BP) presenting.

Ekr: ports are bad news and lead to the two sides doing different
things. Just do it in the handshake. You can register a codepoint for
this if you want.

SPT: other than the authors, is there any adoption for this?

BS: Could you expand on the motivation? It seems like a small gain in
AES cycles.

BP: we do high-performance computing. The high-performance world
generally doesn't do encryption today; CPU performance is the barrier to
adoption of TLS, so we're trying to squeeze as much as we can.

BS: we should discuss more on-list what is specifically painful about
sequence numbers; it seems fairly negligeable.
BP: latency and extra state.
BS: isn't it equally stateless either way?

Yoav Nir (YN): this draft makes a normative reference to the TLS Flags
draft, so some process issues.

Kazuho Oku (KO): Is there really a need for this? Seems like a small
improvement.
BP: Yes, we have clients for whom this would make a difference.

MT: is that "5%" number from published experiments?
DP: No experiments yet, it's hypothetical.
MT: I vote against this, do what Ekr suggested (register a custom
codepoint?).
SPT: talk to the chairs, we'll help you navigate the process.

TLS 1.2 Deprecation

SPT presenting.

Rich Salz: Get PCI to do it, because money makes the world go round.
(PCI-DSS could ban 1.2).
We could put out an RFC that says 1.2 is now frozen.

Alex Chernyakhovsky (AC): Wearing my YouTube hat; the problem is
clients. There's a lot of deployed set-top boxes that can't be patched.
This feels too soon.

SPT: We're just trying to get the conversation going, not advocating
this (yet).

Wes Hardaker (WH): deprecating in the sense that IETF will no longer
spend effort updating is one thing, but announcing to operators to stop
using it is something else. The Internet still has so much TLS 1.2 (esp.
of new devices) that it actually looks like 1.2 is still gaining
marketshare relative to 1.3. The messaging here has to be very very
clear.

Ekr: I think the WG should stop working on 1.2. When used properly TLS
1.2 is still good as far as we know. We could deprecate 1.2 for H/2,
before deprecating it for other things.

SPT: How long would it be before FF would turn off support for 1.2

Ekr: Below single digit %, so probably less than 10 years, but I
wouldn't be surprised if it was 5.
MT: Agree with Ekr, TLS 1.2 is currently over 30% so it's not happening
any time soon. Greenfield should be 1.3 as a baseline. Cloudflare report
a 9% TLS 1.2 rate.

AG: Start telling people not to use it for new things.

MO: with my AppSecSecurity pentester hat on, we need to be careful to
distinguish between "not recommended for new things" and "vulnerable,
turn it off" otherwise we're gonna create CVE hell.

Tommy Pauly: We need to do more advertising of TLS 1.3. We see about 12%
TLS 1.2 over the last 24h.

Ekr: Issue some statment that say:

1. We're going to stop updating TLS 1.2
2. Use TLS 1.3 for greenfield
3. We'll be monitoring usage and will deprecate it once usage gets low
   enough.

Rich Salz volunteers
RS: Will the draft also say we won't accept IANA codepoints for 1.2
Ekr: that would be a mistake because then you'll just get un-authorized
codepoints that clash.
Viktor Dukhovni (VD): Raising the ceiling seems to have worked pretty
well.

JM: what about dTLS 1.2?
Ekr: John's right, dTLS 1.3 adoption lags TLS 1.3, so we need to be
careful about deprecating dTLS 1.2. Fine to not accept new features.