# TLS - IETF 118   {#tls---ietf-118}

6th November 2023  
Notes: Flo Driscoll, Rich Salz

## WG Status   {#wg-status}

Hope to finish 8446bis imminently.  
Flags draft waiting for an implementation, Jonathan has a proposal for a
flag (see presentation in this session), so this might unstick it.  
RRC waiting for implementation; Thomas said they're working on it. Need
codepoint; Sean says just a formality, so will start the process soon.

## WG I-Ds - 20 min   {#wg-i-ds---20-min}

### TLS Encrypted Client Hello (ECH) - Chris Wood - 15 min   {#tls-encrypted-client-hello-ech---chris-wood---15-min}

Arnaud Taddei - I think the overview of ECH draft doesn't do justice to
the topic. The deployment considerations are hard to understand for a
non-English speaker. I'll submit a PR.  
Eric Rescorla (EKR) - Submit issues (or PR) please.

Chris provides reminder of how ECH works. Several implementations exist,
tracked on wiki. Firefox and Chrome have implementations. Cloudflare
have an implementation but they've had to turn it off temporarily due to
a bug.

Today's objective: ship it! There are a few open issues.

Open issue 1: what clients put in the outer client hello SNI field and
what servers do with that. There's a PR open (575). Complication is
whether or not you allow domain fronting.  
EKR - Can live with that, but I want to talk about the normative
language. It would be better for the internet if we said must and gave
conditions in which you could violate the must. I'd prefer a must do it
and should check, as opposed to should do it and may check.  
Stephen Farrel (SF) - I think we should merge this and discuss in WGLC. 

Mike Bishop (MB) - A must that you don't follow under certain conditions
is a should.  
EKR - I'm saying you must do this unless there are certain conditions.
That's not a should.

Chris: WG consensus is to merge and move on.

Open issue 2: Padding. Padding is necessary to avoid leaking information
name. There's a PR about adding padding, but this seems like an
orthogonal thing that we can address in a follow up draft later on.  
EKR - This seems fine, but the text currently says that you have to pad
at the record layer. As things stand we tell you how to pad, but this
proposal says that if you want to add other padding mechanisms that'll
be a different draft.

Chris: No more comments or concerns.

Open issue 3: Non-HRR acceptance signal goes in Server Hello Randon.
Proposal is to leave as it is and close the issue.

No objections, move on.

Open issue 4: Grease HRR acceptance signal, we currently don't, it might
be good to but it's not clear the threat model requires it. Proposal is
to leave it as it is and close the issue.

No objections, move on.

Open issue 5: Extensions. Problem is that ECH extensions add complexity
to the protocol and we don't have a use case for them yet. But in the
future we might. Proposal is to leave it as it is and close the issue.  
SF: I'm not objecting. But it's not true that all libraries have added
support in a meaningful sense. Some libraries have ignored this.  
Chris: Let's talk later about this, we should get these checked.

No objections.

Open issue 6: ECH is complex. This is true. But we don't have a better
solution. Not much we can do about this except for acknowledge that it's
a complicated protocol. Proposal is to close this.  
Michael P: Not on the complexity, but related. The first paragraph in
the draft is a disclaimer on the security analysis, could you add
references please?  
Chris: We'll make sure to tidy that before doing the WGLC.

No objections

Chris: I suggest we kick off WGLC. Next version will be out this week.  
Sean: This will probably be a longer than usual WGLC because of US
holidays, maybe running to early December. Do we need early code point
values?  
Chris: Leave them as is.

### IANA Registry Updates for TLS and DTLS - Joe Salowey - 2 min   {#iana-registry-updates-for-tls-and-dtls---joe-salowey---2-min}

Joe: Working through issues on 8447bis. Updating discouraged codepoints.

Chris Patton: Does DES include 3-DES?  
Joe: No, just DES.  
John Mattsson: I plan to update draft-mattsson based on this, it's good
that this is done. The conclusion in the group last time was to update
registration requirements for NULL encryption. I'll try to do everything
you're not doing in my draft.  
Rich Salz: IANA already moved DES to deprecated; why "repeat" in this
doc?  
Sean: There's a distinction between IANA and IETF tracks. Want to match
them up as possible.  
John Mattsson: Why aren't we deprecating 3-DES or anything that uses
CBC?  
Joe: We want to get this draft out and I don't know that we have
consensus to deprecate 3-DES. Someone could write a draft on that.

Ready for last call? Hopefully we can have a quick last call. Need to
decide where to put the "comments" column (tls 1.3 only), in this draft
or the tls12-frozen draft.

### Compact TLS 1.3 - Joe Salowey - 2 min   {#compact-tls-13---joe-salowey---2-min}

Formal analysis now available. There's been some additional work on
reducing the size of the keys.

## Adoption Call   {#adoption-call}

### SSLKeyLog   {#sslkeylog}

Sean - Quite a lot of people were interested in working on this at IETF
116 but no one on the list responded to a call. ADs said we should adopt
based on consensus at the meeting, so we're going to adopt this.

A few people are willing to review so **we will adopt this**.

Jonathan Hoyland: Can we add ECH keys to the file?  
Sean: Yes if we have consensus. We adopted the doc, so we can add
anything.

## Individual I-Ds - 90 min   {#individual-i-ds---90-min}

### KEM-based Authentication for TLS 1.3/KEM-based pre-shared-key handshakes for TLS 1.3 - Thom Wiggers   {#kem-based-authentication-for-tls-13kem-based-pre-shared-key-handshakes-for-tls-13---thom-wiggers}

AuthKEM is KEM based authentication for TLS i.e., not using signatures.
Particularly for PQ setting. Draft first presented in July 2021. Some
people did some analysis work on KEM-based authentication for MQTT.
Found use of KEM for authentication resulted in time savings. Have now
split the draft into two proposals - AuthKEM-02 (KEM public keys in
certs) and AuthKEM-PSK-00 (KEM based resumption.). Today Thom is
explaining the update and asking for support.

KEM Authentication for TLS - use KEM public key for handshake auth. This
saves lots of handshake traffic.

KEM-based PSK-style handshakes - uses KEM ciphertext instead of PSK.

Asking people to submit comments on the mailing list or github mailing
list. Would like to hear from people who would like to use or implement
these protocols.

Chris Patton: I think this is a great idea. I have two buckets of
questions: 1. are we aiming for the same security properties as TLS 1.3.
2. What is your long term vision for this protocol?  
Thom: The second question is very hard to answer. This could generalise
to lots of other protocols. For TLS this is something you could
negotiate. In terms of security properties, the discussion is slightly
nuanced. You can't get exactly the same security properties but I don't
think the difference is material. I don't think AuthKEM sacrifices
forward secrecy.  
EKR: I don't think this has legs. The presentation is better, but this
is the same major structural changes to TLS which doesn't seem worth it
for the benefits. We're nowhere near deploying PQC certificates at all.
Thank you but I don't see this getting adopted. Maybe we can have a
conversation again in 3 years.  
Thom: I think that if we punt this too far into the future then we don't
get the opportunity to work on the PKI that could support this.  
EKR: Major problem is that CAs don't have post quantum roots.  
Jonathan Hoyland: I think it takes so long to get any changes through
the PKI that if we don't start now we will be stuck.  
Sean: Do PKI things in LAMPS.  
Chris Patton: Do we think that the change to the PKI will start in TLS
or from the roots? Why don't we just start?  
Richard Barnes: I think you get more effectiveness from changing the
rest of the PKI than from changing TLS.  
EKR: Unless you add PQ signatures to the rest of the PKI you don't gain
much here.  
John Gray: We (Entrust) don't have public PKIs that can do PQ but we do
have private ones. There are other PKIs than WebPKI.

Thom: Would like to clarify that the second draft has nothing to do with
PKIs.

**Show of hands - Is there interest in adopting this work (both drafts)
now? Yes - 29, No - 12**  
Chris: We'll talk and follow up with the authors.

### TLS 1.2 is (still) frozen - Rich Salz - 10 min   {#tls-12-is-still-frozen---rich-salz---10-min}

Content: No new algorithms for TLS 1.2 except for ALPN and key exporter
labels. Annotation that new ciphers are for TLS 1.3 or later. We'll
state that there will not be Post-Quantum for TLS 1.2. Clarify this is
for TLS only, not DTLS. Impact on other protocols has been split out
into a separate draft which is intended for UTA.

Ready for adoption? Expect it to be quickly ready for WGLC after people
have read it.

Chris: Last time we talked about this there was clear interest in the
room in adoption. So we'll do a confirmation call for adoption on the
list.  
Sean: Not that this draft does not say that we should stop using TLS 1.2
at a certain date.  
Rich: No, we're just saying that it won't change or get better. We might
fix bugs if we find them.

### Legacy RSASSA-PKCS1-v1\_5 codepoints for TLS 1.3 - Andrei Popov - 15 min   {#legacy-rsassa-pkcs1-v1_5-codepoints-for-tls-13---andrei-popov---15-min}

This draft was originally published by David Benjamin, would like to
restart the discussion. Problem is that commonly used client-side
cryptographic devices cannot sign TLS 1.3 CertificateVerify. This blocks
TLS 1.3 deployments, means that entire deployments are stuck with TLS
1.2.

Proposal is to add three legacy codepoints, RSASSA-PKCS1 (with
SHA256/384/512), that can only be used in the client CertificateVerify
message.

Would like adoption. Planning for some implementations in Chrome stack
and Windows stack.

EKR: What fraction of devices can do PSS but with the wrong salt length?

Andrei: That's a difficult question, telemetry won't tell us directly.  
EKR: This is gross but we're probably going to have to do it. Are you
saying that if we said that you must use PSS but we would relax the salt
length that wouldn't be enough?  
Andrei: Probably not.  
Chris Patton: Why do you need a public codepoint?  
Andrei: We'd like this to be on the standards track so it can be used by
different implementations.  
Chris Patton: Have you considered post-handshake authentication?  
Andrei: That's a huge change to systems.  
Deb Cooley: Have you found this with our smart cards? Are there
particularly smart cards you've seen this issue with?  
Andrei: I know less about smart cards than TPMs but I have seen the
issue with smart cards as well.  
Deb Cooley: We can try and shift smart cards, but really we're only
looking on using these smart cards until 2035.

**Show of hands - Do you favour adopting the PKCS1 draft? Yes - 36, No -
1**  
Sean: Let's go ahead, I'll mark things in the datatracker.  
Paul Wouters (AD): You should confirm this on the list.  
Sean: Ok.

### TLS Key Share Prediction - David Benjamin - 15 min   {#tls-key-share-prediction---david-benjamin---15-min}

In ECDHE negotitaion the client sends two extensions - supported\_groups
and key\_share with information. The policies as to what are selected
are up to implementation. Semantics for supported\_groups are specified
but we have not specified what happens when the client omits keys from
some key\_share but not all key\_shares. This leads to different server
behaviour.

This might be fine now because clients predict their preferred
algorithm. However, with the PQ transition the client might not know
what a server supports. You could fix this by having some out of band
prediction (e.g. DNS). However, this might still lead to the wrong
option.

This draft is trying to clean this up. Clarifies that client key share
is a prediction, not a preference. Servers should not assume key share
list reflects preference. Needs to look at supported\_groups for full
list of supported groups. Also add DNS hints (this could be pushed to
another draft). This draft also tries to solve some compatibility issues
for older TLS 1.3 servers. Current behavior is okay if you do not care
if attacker picks which curve is used.

EKR: Nice catch. As I understand it, the attack problem is only created
when a new PQ KEM comes around or when you (server) DO have a
preference. You shouldn't promise that you do what you don't do.  
David Benjamin: I should say "if you have no preferences between you
groups that are stronger than a round trip."  
EKR: I think we should stop making normative changes to 8446bis, but we
should add some text. I'm not totally sold on this solution for the
future, let me propose some alternatives. A TLS flag that says "this is
preference order" is one. Another is to do the analog of SCSV for cipher
suite fallback signalling.  
David: I can't reason about those without more thought.  
EKR: Agree.  
David: I put this in one document because it's easier to follow this
way, we could also put it in 8446bis.  
David: Cloudflare on the list said that they already do selection on the
client side. Chrome does not.  
Chris Patton: I really like the DNS hint. I think the selection
algorithm could use a little workshopping. I wondered if you considered
defining an extension to signal (from the client) the new behaviour.  
David: Problem is that older servers will ignore the extension. This is
simplest thing that I could come up with.  
Chris Patton: Can we update 1.3?  
Sean: Yes.  
Thom: I think this is a problem that we need to fix. Relying on DNS only
solves it for things that are reliant on DNS/are connected to the public
internet. I'm in favour of also configuring something on the server.  
David: Yes, non-DNS based servers will need to solve this problem a
different way.

Sean: There might be some quick iterations with EKR to get some new text
in 8446bis, meanwhile everyone else will keep working on this.

### TLS Trust Expressions - Devon O'Brien, David Benjamin, Bob Beck - 30 min   {#tls-trust-expressions---devon-obrien-david-benjamin-bob-beck---30-min}

Devon: TLS trust expressions allow relying parties to convey their trust
in CAs to subscribers. Motivating use case - rotating root keys is hard.
Need multiple years of overlap between new and old keys.

Relying parties do not tell the subscriber what they trust, and also
different relying parties have different requirements - these can
conflict. Because subscribers need a certificate bundle supported by all
relying parties, they need to have a bundle that's the intersection of
what's supported. This poses challenges for all parties - for CAs it
means that only ubiquitous roots are useful, and it's difficult to
transition; for subscribers (often websites) choice is limited and it's
hard to predict what will work; for relying parties policy changes
burden the ecosystem.

Proposal here is to move from a single certificate model to a multi
certificate model with different cert parts for different relying
parties. This requires a certificate negotiation mechanisms to select
the right path, and an issuance mechanism for subscribers to obtain
multiple paths.

EKR: TLS 1.3 restricts you to one EE cert but an arbitrary number of
intermediate certs.  
David: What you're describing here is path building where you send a
bunch of stuff and the relying party chooses what to use. This punts a
lot of complexity to the client and means that we are sending lots of
unnecessary things to a client. At the moment that's ok, but with PQC
it's a problem because certs get much bigger.  
EKR: It's one thing to know that for a given connection I need to send a
particular certificate, it's another thing to know that everyone
supports a specific certificate.  
David: This is primarily about the per connection thing.

David: Can we just use the certificate\_authorities extension? This is
inefficient, and also relying parties may trust many CAs so this would
be massive. Instead we propose named trust stores. Relying party
references versioned a named trust stores. Subscriber has metadata about
which trust stores match each cert path. Allows subscriber to pick the
best eligible option. The subscriber gets this information by the root
program publishing a "trust store manifest" to the CAs. CAs publish this
to subscribers. On the relying party side, root program sends list of
trust anchors to relying party.

Trust store manfiest would be a JSON document published by a root
program, describing current and historical versions of a trust store. CA
collects manifests from each root program it participates in and
generates TrustStoreInclusionList for each issued cert path. Sends this
to the subscriber. On the relying party side, the root programs provide
trustexpressionlist with trust anchor list. Path is eligible if it
matches any trust expression on the list. For privacy purposes, only
advertise trust anchors common to anonymity set. Other trust anchors
will continue to work, and if no expressions match subscribers should
use previous behaviour.

Bob: We've done some stuff for an ACME extension. ACME already can send
multiple cert paths. Current version suggestions clients use their own
heuristics, with this no more heuristic is needed. Might need some
future work for complex cases. Have defined a new media type:
application/pem-certificate-chain-with-properties. Net result is that
CAs can transparently issue multiple paths that together cover all
relying parties.

Multi-cert examples:

*   Key rotation - CA operator generates new root key and issues from
    both in parallel. Out-of-date relying parties work as long as old
    root key is in operation.
*   Eliding intermediates - Can omit intermediates as in
    draft-ietf-tls-cert-abridge. CA sends short path and long path to
    subscribers, subscribers pick the appropriate one.
*   Postquantum roots - Allows PQ roots to be gradually deployed.
*   Backup Certs - Subscriber can combine output from multiple CAs.
    Gives a backup if one CA is unreachable.

Dennis Jackson: It seems that the key security benefit of this draft is
making it easier to remove CAs. But it relies on CAs to provision those
backups in the first place. There's not an incentive for a CA to do
that, they don't want to be removed. My bigger concern, I don't think
it's good to have different CAs between different root stores. I think
it's good that the world is forced to align behind CAs that are globally
trusted. If countries can add their own CAs I think we'll start to see
this, and it could be an effective censorship mechanism.  
Devon: CA distrust is not a major goal here. At the moment there's a
huge barrier to add new CAs. This doesn't require a CA to collaborate
with another CA for a fallback solution. There's a lot more work needed
on the ACME side to enable this. There are multiple other options for
subscribers to obtain these certificates. On your second point, we
currently don't have a common set of CAs, there are CAs that are left in
the preriphery for arbitrarily long lengths of time.  
David: There are variations not just within different relying parties,
there's a whole space of variability that will be resolved if we can do
this more clearly.

Jonathan Hoyland: I'm not a big fan of these groups of CAs. The set of
CAs will grow much more quickly than the set of set of CAs.  
Dennis: On any connection you're not going to send very many. The
subscriber information will grow a bit but you're not going to send
these very often.

Nicola Tuveri: I want to go back to the concern about censorship and
surveillance. The moment you have this extension that marks what you're
excluding, you are giving your ISP a signal if you're deliberately
excluding a government provided root.  
David: You should communicate what's in your anonymity set.

Stepher Farrell: Echo Dennis's concern. I'm also not convinced that it
takes 3-4 years to issue certificates. New-ish CAs tend to start as
intermediates. Thank you for not pretending this is simple.  
David: 3-4 year thing - if you allow cross-signing it doesn't take that
long but that has some interesting security implications. If you don't
then it can take even longer, you need to wait for the oldest relying
party to age off.  
Devon: Expecting CAs to approach a competitor to be cross-signed has its
own problems. I don't think cross-signs are the pancaea here.

Please take other comments to the list.

### TLS Flag - Request mTLS - Jonathan Hoyland - 5 min   {#tls-flag---request-mtls---jonathan-hoyland---5-min}

Distinguishing bots is hard because many bots come from public clouds
and send special user agents. But anyone can imitate this. We want to
use mutual TLS but that needs to be intiated by the server in TLS 1.3.
We could send a certificate request every time but humans might be
confused. This is a proposal to add a flag that bots send that says "I
have a client certificate configured". To be done in TLS Flags. Do
people think this is useful?

Thom: This might help solve a problem in AuthKEM. We have problems
authenticating a cert request message. This would probably help
partially address that issue.  
Rich: I think this is useful because we have some customers who want to
do mutual authentication by policy.  
Jonathan: This is aimed strictly at bots not browsers.  
Andrei Popov: Does this need to be sent by the client or could the
server send something that says if you should only answer this request
if you have a certificate?  
Jonathan: We'd need to ask the browsers if that works but I wouldn't
have thought so.  
Chris P: Following up on that point, it might be fine for Cloudflare to
send a certificate request to every eyeball but it would be really
weird. What work is remaining for this draft?  
Jonathan: Just say this looks good. It is predicated on the TLS flags
draft which was blocked on lack of implementations. I've written two
implementations that I'm trying to get open sourced.

We'll take this to the list to see if people are interested.

### TurboTls - Time Permitting   {#turbotls---time-permitting}

No time permitting, but please go and take a look at the slides.

### Designated Exterts - registration requests   {#designated-exterts---registration-requests}

No time permitting - There are also slides about designated experts
registration requests which might be interesting.