[{"author": "Christopher Patton", "text": "

Is this the chat for the 118 meeting?

", "time": "2023-11-06T08:35:29Z"}, {"author": "Joseph Salowey", "text": "

yes

", "time": "2023-11-06T08:35:42Z"}, {"author": "Yoav Nir", "text": "

That's what the title says

", "time": "2023-11-06T08:35:50Z"}, {"author": "Yoav Nir", "text": "

It does seem to be far less chatty than in previous meetings.

", "time": "2023-11-06T08:36:20Z"}, {"author": "Dennis Jackson", "text": "

9.30am on a Monday will do that

", "time": "2023-11-06T08:36:42Z"}, {"author": "Thom Wiggers", "text": "

it's early and the room seems pretty full (fewer people remote?)

", "time": "2023-11-06T08:36:55Z"}, {"author": "Christopher Patton", "text": "

just asking because I'm using Tulip for the first time and the interface confused me :) thanks

", "time": "2023-11-06T08:37:38Z"}, {"author": "Deb Cooley", "text": "

zulip

", "time": "2023-11-06T08:38:36Z"}, {"author": "Stephen Farrell", "text": "

wrt ECH we made some packages (e.g. for nginx) and wrote up a bit of a HOWTO - be great to get any feedback if someone wants to try it out - https://defo.ie/quick-setup-guide-for-encrypted-client-hello-ech.html

", "time": "2023-11-06T08:38:42Z"}, {"author": "Anthony Somerset", "text": "

Stephen Farrell said:

\n
\n

wrt ECH we made some packages (e.g. for nginx) and wrote up a bit of a HOWTO - be great to get any feedback if someone wants to try it out - https://defo.ie/quick-setup-guide-for-encrypted-client-hello-ech.html

\n
\n

thanks @Stephen Farrell - will definitely take a look at this

", "time": "2023-11-06T08:40:48Z"}, {"author": "Benjamin Schwartz", "text": "

Nope, EKR is right, it's a SHOULD.

", "time": "2023-11-06T08:40:57Z"}, {"author": "Stephen Farrell", "text": "

padding punting seems fine

", "time": "2023-11-06T08:45:11Z"}, {"author": "Richard Barnes", "text": "

i think Wood should definitely make ECH less complex

", "time": "2023-11-06T08:49:20Z"}, {"author": "Richard Barnes", "text": "

should be easy right

", "time": "2023-11-06T08:49:29Z"}, {"author": "David Benjamin", "text": "

Mandatory extensions can be greased. I think the draft might even suggest doing it now?

", "time": "2023-11-06T08:49:51Z"}, {"author": "Anthony Somerset", "text": "

i think ECH once more widely adopted will lead to better docs which can lead to a future BCP

", "time": "2023-11-06T08:50:00Z"}, {"author": "Thom Wiggers", "text": "

It's exciting that ECH is finally this far :D

", "time": "2023-11-06T08:51:28Z"}, {"author": "Stephen Farrell", "text": "

we did do an update of draft-ietf-tls-wkech btw, but nothing really to say about it, it's fine to consider that once ECH WGLC done

", "time": "2023-11-06T08:53:00Z"}, {"author": "Eric Rescorla", "text": "

I can't believe we are deprecating IDEA. End of an era!

", "time": "2023-11-06T08:53:42Z"}, {"author": "Yoav Nir", "text": "

I can't believe we are deprecating IDEA now. Why not 3DES?

", "time": "2023-11-06T08:54:44Z"}, {"author": "Stephen Farrell", "text": "

yeah I was wondering about 3des too (but wasn't really listening;-)

", "time": "2023-11-06T08:55:15Z"}, {"author": "Yoav Nir", "text": "

Why not CBC in general

", "time": "2023-11-06T08:55:19Z"}, {"author": "Christopher Patton", "text": "

3DES does not imply CBC

", "time": "2023-11-06T08:56:07Z"}, {"author": "Christopher Patton", "text": "

errr, well maybe it does for TLS?

", "time": "2023-11-06T08:56:17Z"}, {"author": "David Benjamin", "text": "

It does for TLS.

", "time": "2023-11-06T08:56:22Z"}, {"author": "Thom Wiggers", "text": "

triple-discouraged

", "time": "2023-11-06T08:56:39Z"}, {"author": "Eric Rescorla", "text": "

Can we do double-DES in ED mode? :)

", "time": "2023-11-06T08:58:41Z"}, {"author": "Thom Wiggers", "text": "

Eric: let's meet in the middle

", "time": "2023-11-06T08:59:11Z"}, {"author": "Anthony Somerset", "text": "

meetecho - please can the front mic be turned up in the stream slightly - its quiet compared to the other mics

", "time": "2023-11-06T08:59:28Z"}, {"author": "Christopher Patton", "text": "

good idea Jonathan

", "time": "2023-11-06T08:59:29Z"}, {"author": "Christopher Patton", "text": "

@Eric Rescorla what is ED mode?

", "time": "2023-11-06T08:59:37Z"}, {"author": "Richard Barnes", "text": "

i think Sean just needs to get closer to the mic sometimes

", "time": "2023-11-06T08:59:50Z"}, {"author": "Yoav Nir", "text": "

extremely deprecated

", "time": "2023-11-06T08:59:55Z"}, {"author": "Christopher Patton", "text": "

ah!!

", "time": "2023-11-06T09:00:09Z"}, {"author": "Anthony Somerset", "text": "

sorry sean is fine, front - mic in the room

", "time": "2023-11-06T09:00:10Z"}, {"author": "Eric Rescorla", "text": "

@Christopher Patton \"Encrypt Decrypt\" mode

", "time": "2023-11-06T09:00:15Z"}, {"author": "Jonathan Hoyland", "text": "

I think they meant the front room mic

", "time": "2023-11-06T09:00:17Z"}, {"author": "Eric Rescorla", "text": "

It's like EDE but without the last E :)

", "time": "2023-11-06T09:00:27Z"}, {"author": "David Benjamin", "text": "

At least in terms of what browsers have managed, we (Chrome) got rid of 3DES before we got rid of SHA-1 in sigalgs. So it is a little odd that the draft is doing the latter, but not the former. But we have also done both, so I'd be on board with a 'D' for either. But also don't care whether this happens now or later. :-)

", "time": "2023-11-06T09:00:36Z"}, {"author": "Lorenzo Miniero", "text": "

Front room mic = speaker mic, or mic line?

", "time": "2023-11-06T09:00:38Z"}, {"author": "John Preu\u00df Mattsson", "text": "

I am happy to help with SSLKEYLOGFILE

", "time": "2023-11-06T09:00:43Z"}, {"author": "Eric Rescorla", "text": "

It's not quite as bad as it sounds because it's not the same key!

", "time": "2023-11-06T09:00:45Z"}, {"author": "Richard Barnes", "text": "

terminology collision with HPKE?

", "time": "2023-11-06T09:01:04Z"}, {"author": "Jonathan Hoyland", "text": "

Mic line lic

", "time": "2023-11-06T09:01:08Z"}, {"author": "David Benjamin", "text": "

Would love to see CBC across the board go, but the web's not quite there yet. Maybe someday.

", "time": "2023-11-06T09:01:12Z"}, {"author": "Deb Cooley", "text": "

(commonly called 2 key TDES?)

", "time": "2023-11-06T09:01:13Z"}, {"author": "Jonathan Hoyland", "text": "

The front mic line mic is quiet in the room too

", "time": "2023-11-06T09:02:06Z"}, {"author": "Eric Rescorla", "text": "

@Deb Cooley isn't 2 key 3des key A, B, A?

", "time": "2023-11-06T09:04:42Z"}, {"author": "Deb Cooley", "text": "

I don't remember actually

", "time": "2023-11-06T09:04:59Z"}, {"author": "Deb Cooley", "text": "

I'm old, but not that old

", "time": "2023-11-06T09:05:14Z"}, {"author": "Yoav Nir", "text": "

It may be worth making a deprecation document after the current one, with the intent that it gets published in 2 years or so. Of course, by then it might be reduced to \"just use TLS 1.3\"

", "time": "2023-11-06T09:05:15Z"}, {"author": "Deb Cooley", "text": "

Is there a problem with TLS 1.2?

", "time": "2023-11-06T09:05:37Z"}, {"author": "Eric Rescorla", "text": "

It's one less

", "time": "2023-11-06T09:05:59Z"}, {"author": "Eric Rescorla", "text": "

Or I guess .1 less

", "time": "2023-11-06T09:06:07Z"}, {"author": "Yoav Nir", "text": "

No, except that you might misconfigure and use single DES. Publishing a new RFC does not necessarily update implementations.

", "time": "2023-11-06T09:06:24Z"}, {"author": "Richard Barnes", "text": "

please see my draft on SonnetDES, which is ABAB CDCD EFEF GG

", "time": "2023-11-06T09:06:55Z"}, {"author": "Alex Chernyakhovsky", "text": "

Amazing, when can I get a hardware accelerator for it?

", "time": "2023-11-06T09:07:45Z"}, {"author": "Christopher Patton", "text": "

To put a fine point on my question: Do we sacrifice forward secrecy?

", "time": "2023-11-06T09:08:42Z"}, {"author": "Jonathan Hoyland", "text": "

+1 to Thom. Security differences do exist, but not materially relevant

", "time": "2023-11-06T09:08:58Z"}, {"author": "Christopher Patton", "text": "

It would be great if we could enumerate these at least

", "time": "2023-11-06T09:09:58Z"}, {"author": "David Benjamin", "text": "

IIRC, we sacrifice downgrade protection with the False Start analog.

", "time": "2023-11-06T09:10:07Z"}, {"author": "Stephen Farrell", "text": "

+1 to ekr - if there were a place to store good-idea-but-not-yet I-Ds this'd fit that I think

", "time": "2023-11-06T09:10:17Z"}, {"author": "Stephen Farrell", "text": "

@Jonathan Hoyland we're in that bad PKI place for the last 40 years already, not clear that's gonna be fixed

", "time": "2023-11-06T09:12:03Z"}, {"author": "Anthony Somerset", "text": "

front mic line mic could still with being turned up on stream

", "time": "2023-11-06T09:12:27Z"}, {"author": "David Benjamin", "text": "

Is there any more to the PKI bits here than \"define a new key type\"?

", "time": "2023-11-06T09:12:54Z"}, {"author": "David Benjamin", "text": "

I certainly wish the spelling for that in X.509 were better and have lots of opinions on it, but I think it's mostly orthogonal.

", "time": "2023-11-06T09:13:48Z"}, {"author": "Christopher Patton", "text": "

I don't think so

", "time": "2023-11-06T09:13:48Z"}, {"author": "Deb Cooley", "text": "

The rest of the PKI structure has to change too?

", "time": "2023-11-06T09:14:07Z"}, {"author": "Deb Cooley", "text": "

at least to be updated w/ new algorithms?

", "time": "2023-11-06T09:14:21Z"}, {"author": "Christopher Patton", "text": "

I think the merits of this draft should be considered independently of where the PKI is and will be in the next 10 years

", "time": "2023-11-06T09:15:14Z"}, {"author": "David Benjamin", "text": "

But the change for the rest of the PKI is the same whether we go with Kyber (KEM) or Dilithium/Falcon (signature) for the long-term server credential.

", "time": "2023-11-06T09:15:15Z"}, {"author": "Christopher Patton", "text": "

There will be a period of time where there are both classical and PQ primitives in the train of trust. Our goal should be to minimize that time.

", "time": "2023-11-06T09:15:39Z"}, {"author": "Eric Rescorla", "text": "

@David Benjamin no, it's just like s/p256/p256, dilithium/

", "time": "2023-11-06T09:15:39Z"}, {"author": "Stephen Farrell", "text": "

the poll question is a bit ambiguous - I am interested in the topic but would oppose adoption now

", "time": "2023-11-06T09:16:27Z"}, {"author": "Christopher Patton", "text": "

I also am not sure it's baked enough for adoption.... we'd have to figure out if it's something you negotiate or a standalone protocol.

", "time": "2023-11-06T09:17:12Z"}, {"author": "Thom Wiggers", "text": "

I also think adopting the drafts would be adopting two fairly rough WIP documents

", "time": "2023-11-06T09:18:09Z"}, {"author": "Thom Wiggers", "text": "

but i'm happy to hear that there is interest to continue working on the topics

", "time": "2023-11-06T09:18:36Z"}, {"author": "Yoav Nir", "text": "

@christopher Patton: it's a bad trend that WGs only adopt fully baked solutions. It makes them rubber-stamp groups rather than working groups.

", "time": "2023-11-06T09:18:50Z"}, {"author": "Raghu Saxena", "text": "

Is it possible to view the meeting if one is not a member of the WG? I can listen to it via the Audio stream at least.

", "time": "2023-11-06T09:19:14Z"}, {"author": "Thom Wiggers", "text": "

@Raghu Saxena working groups don't have \"members\" so if you can find the audio stream you should be able to find Meetecho

", "time": "2023-11-06T09:19:48Z"}, {"author": "Anthony Somerset", "text": "

Raghu Saxena said:

\n
\n

Is it possible to view the meeting if one is not a member of the WG? I can listen to it via the Audio stream at least.

\n
\n

I'm technically not a member of this WG but i am in the full meetecho client

", "time": "2023-11-06T09:19:54Z"}, {"author": "Thom Wiggers", "text": "

https://meetecho.ietf.org/client/?group=tls

", "time": "2023-11-06T09:19:56Z"}, {"author": "Lorenzo Miniero", "text": "

You do need to register at the meeting to join, though

", "time": "2023-11-06T09:20:35Z"}, {"author": "Raghu Saxena", "text": "

Will just wait for it to be uploaded to YT.

", "time": "2023-11-06T09:21:02Z"}, {"author": "Florence D", "text": "

Maybe this should be obvious, but what are ALPN and key exporter labels exceptions in the TLS 1.2 is frozen draft?

", "time": "2023-11-06T09:21:46Z"}, {"author": "Yoav Nir", "text": "

The TLS registry experts will not automatically reject registrations of new ALPN and exporter labels.

", "time": "2023-11-06T09:22:35Z"}, {"author": "Florence D", "text": "

Sorry, wrong question. Why are they the exceptions?

", "time": "2023-11-06T09:23:35Z"}, {"author": "Florence D", "text": "

I mistyped before.

", "time": "2023-11-06T09:23:49Z"}, {"author": "Eric Rescorla", "text": "

Actually, why do you need an ALPN exception for 1.2, given that ALPN works for both?

", "time": "2023-11-06T09:24:21Z"}, {"author": "Yoav Nir", "text": "

The draft says that al new things that are defined do not apply to TLS 1.2, only to TLS 1.3. That is why ALPN needs to be explicitly called out.

", "time": "2023-11-06T09:27:27Z"}, {"author": "Jonathan Hoyland", "text": "

Not saying don't adopt it, but I hate this.

", "time": "2023-11-06T09:28:09Z"}, {"author": "David Benjamin", "text": "

The salt length problem is that PSS was specified wrong. Rogaway's paper was super generic because it was writing a proof. But then PKCS#1 just imported those parameters rather than picking values like they were supposed to. And as a result no one agrees what PSS parameters to use.

", "time": "2023-11-06T09:28:39Z"}, {"author": "Eric Rescorla", "text": "

Obviously, this is regrettable, but seems like it may be regrettable but necessary

", "time": "2023-11-06T09:29:00Z"}, {"author": "David Benjamin", "text": "

IIRC, TPM 2.0 says something unhelpful like \"pick the largest salt length that fits\", which is not what TLS 1.3 wants, and is kinda vague. And then FIPS says \"salt length should not be larger than hash length\" so there's a footnote somewhere that says \"oh you're FIPS, pick the largest salt length that FIPS allows\".

", "time": "2023-11-06T09:30:27Z"}, {"author": "David Benjamin", "text": "

Which means TPM 2.0 has no idea whatsoever what salt length it uses.

", "time": "2023-11-06T09:30:37Z"}, {"author": "David Benjamin", "text": "

OpenSSL has an RSA-PSS verification mode that tries to allow all salt lengths by recovering the salt length. That has always seemed kinda questionable to me. I doubt the security proof actually covers this.

", "time": "2023-11-06T09:31:18Z"}, {"author": "Thom Wiggers", "text": "

can we vote 'ugh but yes'

", "time": "2023-11-06T09:31:40Z"}, {"author": "Jonathan Hoyland", "text": "

Is the solution here DNSSEC?

", "time": "2023-11-06T09:37:28Z"}, {"author": "John Preu\u00df Mattsson", "text": "

CSIDH would be awesome if it was faster. Hopefully AwesomeNewKEM is not just smaller but also a full replacement for ECDH, not just a KEM....

", "time": "2023-11-06T09:37:46Z"}, {"author": "Thom Wiggers", "text": "

CSIDH also has very, very significant question marks surrounding its security analysis

", "time": "2023-11-06T09:38:07Z"}, {"author": "Alex Chernyakhovsky", "text": "

Requiring DNSSEC to avoid a downgrade in TLS seems like a deployability nightmare

", "time": "2023-11-06T09:38:37Z"}, {"author": "Thom Wiggers", "text": "

CSIDH scales like RSA so we might need CSIDH-4096 for 128-bit security in the pessimist analysis. Then it's not exactly as small anymore.

", "time": "2023-11-06T09:38:59Z"}, {"author": "Benjamin Schwartz", "text": "

I do enjoy DNSSEC but no.

", "time": "2023-11-06T09:39:04Z"}, {"author": "Thom Wiggers", "text": "

We have a paper about higher-security CSIDH incl. TLS analysis https://thomwiggers.nl/publication/secsidh/secsidh.pdf

", "time": "2023-11-06T09:40:04Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Thom Wiggers said:

\n
\n

CSIDH scales like RSA so we might need CSIDH-4096 for 128-bit security in the pessimist analysis. Then it's not exactly as small anymore.

\n
\n

Ok, looks like I need to read up on the latest analysis of CSIDH. The original paper promised 512-bit public keys for NIST PQC security level 1....

\n

Thanks for the link

", "time": "2023-11-06T09:42:47Z"}, {"author": "Stephen Farrell", "text": "

DNS hint should defo be separated out of this and done later; the clarifying/fixing stuff for clients/servers is good to do now but likely better in it's own draft

", "time": "2023-11-06T09:45:31Z"}, {"author": "Kyle Nekritz", "text": "

FWIW, 8446 does include

\n
\n

However, the values MAY be a non-contiguous subset of the \"supported_groups\" extension and MAY omit the most preferred groups. Such a situation could arise if the most preferred groups are new and unlikely to be supported in enough places to make pregenerating key shares for them efficient.

\n
", "time": "2023-11-06T09:46:10Z"}, {"author": "Dennis Jackson", "text": "

I think main thing is to tackle the faulty servers by making it clear this is a security issue. DNS Hint might be useful but hopefully not for very long

", "time": "2023-11-06T09:46:54Z"}, {"author": "Eric Rescorla", "text": "

@Kyle Nekritz well that's basically what I would have wirtten

", "time": "2023-11-06T09:47:15Z"}, {"author": "Eric Rescorla", "text": "

@Dennis Jackson Well, I actually am not sure I would call this a security issue prior to the introduction of the DNS hint

", "time": "2023-11-06T09:47:37Z"}, {"author": "Deirdre Connolly", "text": "

Agreed with @Thom Wiggers

", "time": "2023-11-06T09:47:43Z"}, {"author": "Benjamin Schwartz", "text": "

@Dennis I don't quite agree: the DNS hint is useful for avoiding HRR even if there are no security issues

", "time": "2023-11-06T09:48:10Z"}, {"author": "Stephen Farrell", "text": "

@Eric Rescorla isn't there a security issue here without an active attacker in the PQ case where the client/server land on 25519 say?

", "time": "2023-11-06T09:48:40Z"}, {"author": "Jonathan Hoyland", "text": "

Three part harmony?

", "time": "2023-11-06T09:49:20Z"}, {"author": "Dennis Jackson", "text": "

Well the DNS hint is only useful to the extent there's uncertainty about server support for PQ and we don't want to penalise old servers that don't do PQ. I'd hope to see PQ support fast and want to start penalising old servers with worse perf to encourage updates.

", "time": "2023-11-06T09:49:45Z"}, {"author": "Eric Rescorla", "text": "

Stephen Farrell said:

\n
\n

Eric Rescorla isn't there a security issue here without an active attacker in the PQ case where the client/server land on 25519 say?

\n
\n

That's a difficult semantic question. I mean, if you wanted to insist on PQ, you should have insisted on it

", "time": "2023-11-06T09:49:51Z"}, {"author": "Eric Rescorla", "text": "

Anyway, I think we agree on the facts

", "time": "2023-11-06T09:50:22Z"}, {"author": "Stephen Farrell", "text": "

yep

", "time": "2023-11-06T09:50:33Z"}, {"author": "Stephen Farrell", "text": "

what's a subscriber here? (sorry got distracted so probably missed that)

", "time": "2023-11-06T09:51:43Z"}, {"author": "Eric Rescorla", "text": "

The server

", "time": "2023-11-06T09:51:56Z"}, {"author": "Steffen Fries", "text": "

is the trustedCA extension not addressing that signaling?

", "time": "2023-11-06T09:52:28Z"}, {"author": "Richard Barnes", "text": "

is this like \"would you like my WebPKI cert or my eIDAS cert?\"

", "time": "2023-11-06T09:55:16Z"}, {"author": "Dennis Jackson", "text": "

shameless plug: https://last-chance-for-eidas.org

", "time": "2023-11-06T09:55:46Z"}, {"author": "Thom Wiggers", "text": "

This may be addressed already but I wonder about tracking/fingerprinting risks

", "time": "2023-11-06T09:56:13Z"}, {"author": "Stephen Farrell", "text": "

yeah, part of me is not wanting it be too easy to add new roots that get widely used quickly

", "time": "2023-11-06T09:56:14Z"}, {"author": "Deb Cooley", "text": "

It isn't easy today, so you are happy?

", "time": "2023-11-06T09:57:24Z"}, {"author": "Stephen Farrell", "text": "

I'm always happy:-)

", "time": "2023-11-06T09:57:32Z"}, {"author": "Deb Cooley", "text": "

LOL

", "time": "2023-11-06T09:57:37Z"}, {"author": "Dennis Jackson", "text": "

I'm sceptical this will make it easier to remove CAs. This is relying on CAs to offer the backup certs via ACME in the 1st place. They are actively incentivised to not do this because they want removal to be hard.

", "time": "2023-11-06T09:57:50Z"}, {"author": "Jonathan Hoyland", "text": "

Stephen Farrell said:

\n
\n

I'm always happy:-)

\n
\n

You and Bruce Banner

", "time": "2023-11-06T09:58:17Z"}, {"author": "Richard Barnes", "text": "

yeah but what if you gzip it

", "time": "2023-11-06T09:59:26Z"}, {"author": "Deb Cooley", "text": "

that assumes a server has certs from all of those Roots?

", "time": "2023-11-06T09:59:50Z"}, {"author": "Stephen Farrell", "text": "

/me wonders how would this collide with the compressed certs based on cadb thing

", "time": "2023-11-06T10:00:30Z"}, {"author": "Yoav Nir", "text": "

Is the next step going to be a hash&url of the trust anchor list? Have a hash instead of a name?

", "time": "2023-11-06T10:01:19Z"}, {"author": "Benjamin Schwartz", "text": "

chrome/v2 mozilla/v3 Safari/527 (KHTML like Gecko)

", "time": "2023-11-06T10:01:41Z"}, {"author": "Richard Barnes", "text": "

seems like you could overlap this with CT / MTC by having each log be a \"root program\"

", "time": "2023-11-06T10:01:53Z"}, {"author": "Christopher Patton", "text": "

Privacy slide - Yet another reason for everyone to implement ECH

", "time": "2023-11-06T10:04:03Z"}, {"author": "Christopher Patton", "text": "

everyone go encrypt your handshake

", "time": "2023-11-06T10:04:20Z"}, {"author": "Jonathan Hoyland", "text": "

The set of trusted CAs will grow more slowly than the set of sets of trusted CAs

", "time": "2023-11-06T10:04:26Z"}, {"author": "Dennis Jackson", "text": "

Stephen Farrell said:

\n
\n

/me wonders how would this collide with the compressed certs based on cadb thing

\n
\n

There quite juxtaposed. Abridged Certs is pitching for a world in which all root stores have a large intersection. This draft is pitching for the opposite. But this trust expressions draft is also a long term effort which will take a lot of server-side and CA-side changes to implement.

", "time": "2023-11-06T10:04:30Z"}, {"author": "Thom Wiggers", "text": "

Would be nice but I think deploying ECH for non-cloud parties is still a bit tough (and they don't get the anonymity set)

", "time": "2023-11-06T10:04:50Z"}, {"author": "Dennis Jackson", "text": "

Fwiw, I think having websites all use pretty much the same CAs globally is part of what keeps the web open. Trust Expressions would allow different countries to have different root stores entirely. Sites would then need to provision certs from each country they want to be available in.

", "time": "2023-11-06T10:05:55Z"}, {"author": "Kyle Nekritz", "text": "

Abridged certs could allow you to more cheaply send \"all the cross signed intermediates\" which is an alternative solution to the problem though

", "time": "2023-11-06T10:06:01Z"}, {"author": "Stephen Farrell", "text": "

@Dennis Jackson I was more wondering if this and abridged certs could agree on how to represent the same stuff when they need to - there should be overlapping data

", "time": "2023-11-06T10:06:04Z"}, {"author": "Christopher Patton", "text": "

One nice deployment model for ECH might be: use your ECDSA-P256 signing key for HPKE-P256 decryption (don't @ me)

", "time": "2023-11-06T10:06:11Z"}, {"author": "Christopher Patton", "text": "

(This might be easier to deploy for the average TLS operator, Thom)

", "time": "2023-11-06T10:06:34Z"}, {"author": "Christopher Patton", "text": "

Key reuse can be scary, but you can often do it securely. I'm not sure about this particular case.

", "time": "2023-11-06T10:07:15Z"}, {"author": "Thom Wiggers", "text": "

Aside from the deployment challenges (syncing keys to DNS seems much harder than rotating server configs, and that gets screwed up by some bigger sites on the internet all the time still), convincing people that they should deploy it seems hard

", "time": "2023-11-06T10:08:02Z"}, {"author": "Christopher Patton", "text": "

I'd love to talk about why.

", "time": "2023-11-06T10:08:28Z"}, {"author": "Thom Wiggers", "text": "

@Christopher Patton that kind of key reuse has no PQ future

", "time": "2023-11-06T10:08:30Z"}, {"author": "Thom Wiggers", "text": "

unless AuthKEM, of course ;-)

", "time": "2023-11-06T10:08:50Z"}, {"author": "Thom Wiggers", "text": "

(in which case you could also perhaps combine with AuthKEM-PSK...)

", "time": "2023-11-06T10:09:04Z"}, {"author": "Richard Barnes", "text": "

can't we just use a bloom filter for this

", "time": "2023-11-06T10:09:16Z"}, {"author": "Dennis Jackson", "text": "

Only by knowing the set of all CAs :-P. CA-Transparency if you will.

", "time": "2023-11-06T10:09:38Z"}, {"author": "Kyle Nekritz", "text": "

Another possibility is the server offering everything it supports in DNS then the client picks one in ClientHello

", "time": "2023-11-06T10:10:00Z"}, {"author": "Richard Barnes", "text": "

@Dennis :100:

", "time": "2023-11-06T10:10:19Z"}, {"author": "Richard Barnes", "text": "

that is not the emoji i picked!

", "time": "2023-11-06T10:10:33Z"}, {"author": "Deirdre Connolly", "text": "

@Kyle Nekritz i like that

", "time": "2023-11-06T10:10:43Z"}, {"author": "Thom Wiggers", "text": "

@Richard Barnes weird, I see different emoji in MeetEcho and Zulip

", "time": "2023-11-06T10:10:53Z"}, {"author": "Richard Barnes", "text": "

amazing

", "time": "2023-11-06T10:11:12Z"}, {"author": "Richard Barnes", "text": "

if only we had a standard for encoding emoji

", "time": "2023-11-06T10:11:28Z"}, {"author": "Erik Nygren", "text": "

While SVCB will let us put stuff into the DNS, keeping those synchronized is not always going to be easy to maintain.

", "time": "2023-11-06T10:12:08Z"}, {"author": "Stephen Farrell", "text": "

not sure the 3-5 years before issuing is true though is it? don't \"new\" CAs start by being intermediates ?

", "time": "2023-11-06T10:14:44Z"}, {"author": "Eric Rescorla", "text": "

Stephen Farrell said:

\n
\n

not sure the 3-5 years before issuing is true though is it? don't \"new\" CAs start by being intermediates ?

\n
\n

Yeah, that's confusing

", "time": "2023-11-06T10:15:05Z"}, {"author": "Deb Cooley", "text": "

The 4 global trust lists are not country based.

", "time": "2023-11-06T10:15:09Z"}, {"author": "Eric Rescorla", "text": "

Like that's how LE started

", "time": "2023-11-06T10:15:14Z"}, {"author": "Paul Wouters", "text": "

So how long would the payload be for \u201cthe Mozilla CA minus the 25 mandatory European government CAs\u201d ?

", "time": "2023-11-06T10:15:29Z"}, {"author": "Eric Rescorla", "text": "

I like how optimistic you are that it's just 25

", "time": "2023-11-06T10:16:20Z"}, {"author": "Dennis Jackson", "text": "

It's about 55. 20 already trusted by our root program having gone through the checks. 20 never applied. 5 in process of applying, 10 rejected or asked to re-apply when they fix outstanding security issues.

", "time": "2023-11-06T10:17:11Z"}, {"author": "Richard Barnes", "text": "

actually, to paul's point, doesn't this remove user agency?

", "time": "2023-11-06T10:17:22Z"}, {"author": "Richard Barnes", "text": "

like if a user removes a CA from their local root store, they now can't express their trust

", "time": "2023-11-06T10:17:47Z"}, {"author": "Richard Barnes", "text": "

you can only benefit from this extension if you're part of the Browser Industrial Complex

", "time": "2023-11-06T10:18:08Z"}, {"author": "Deb Cooley", "text": "

And if you are in the habit of 'trimming your trust store', where does that leave you?

", "time": "2023-11-06T10:18:35Z"}, {"author": "Thom Wiggers", "text": "

They seemed to support sending {supported lists} + {exclusions}

", "time": "2023-11-06T10:18:38Z"}, {"author": "Richard Barnes", "text": "

ok but ugh

", "time": "2023-11-06T10:18:57Z"}, {"author": "Jonathan Hammell", "text": "

cooley_v1

", "time": "2023-11-06T10:19:19Z"}, {"author": "Deb Cooley", "text": "

??

", "time": "2023-11-06T10:19:31Z"}, {"author": "Richard Barnes", "text": "

that's deb's root store

", "time": "2023-11-06T10:19:44Z"}, {"author": "Deb Cooley", "text": "

LOL

", "time": "2023-11-06T10:19:50Z"}, {"author": "Richard Barnes", "text": "

sign me up

", "time": "2023-11-06T10:19:55Z"}, {"author": "Thom Wiggers", "text": "

subscribe

", "time": "2023-11-06T10:19:56Z"}, {"author": "Eric Rescorla", "text": "

I would only use cooley_v2

", "time": "2023-11-06T10:20:04Z"}, {"author": "Thom Wiggers", "text": "

cooley_v3_3_cooley_4_you

", "time": "2023-11-06T10:20:20Z"}, {"author": "Deb Cooley", "text": "

good move, the initial release is always buggy

", "time": "2023-11-06T10:20:35Z"}, {"author": "Dennis Jackson", "text": "

I believe the exclusions are only for browser-level removals. User-level exclusions would be a near-unique fingerprint right?

", "time": "2023-11-06T10:21:05Z"}, {"author": "Richard Barnes", "text": "

@Dennis - good point

", "time": "2023-11-06T10:21:21Z"}, {"author": "Thom Wiggers", "text": "

Yeah I share those concerns

", "time": "2023-11-06T10:21:23Z"}, {"author": "Richard Barnes", "text": "

really we just need a TLS user-agent extension that people can use to select TLS features

", "time": "2023-11-06T10:22:43Z"}, {"author": "Deb Cooley", "text": "

Is this really a TLS issue?

", "time": "2023-11-06T10:22:59Z"}, {"author": "Richard Barnes", "text": "

that's kinda my point, it only barely is

", "time": "2023-11-06T10:23:11Z"}, {"author": "Deb Cooley", "text": "

(or is it a trust store management issue)

", "time": "2023-11-06T10:23:18Z"}, {"author": "Richard Barnes", "text": "

the server just needs some signal to select a cert

", "time": "2023-11-06T10:23:21Z"}, {"author": "Richard Barnes", "text": "

this is another application for TLS-User-Agent!

", "time": "2023-11-06T10:24:29Z"}, {"author": "Benjamin Schwartz", "text": "

It seems like multi-CA could be done in 1-RTT by letting the server say \"also I have these other roots if you prefer\". That's slower but if heuristics can guess the CA right 98% of the time then maybe it's fine.

", "time": "2023-11-06T10:24:31Z"}, {"author": "Yoav Nir", "text": "

Are there still browsers that pop up a certificate picker when they get the cert request? I remember thsi from IE5 in the 1990s

", "time": "2023-11-06T10:24:49Z"}, {"author": "Richard Barnes", "text": "

@Yoav yes

", "time": "2023-11-06T10:25:01Z"}, {"author": "Eric Rescorla", "text": "

yes, though I think not if you don't have a cert

", "time": "2023-11-06T10:25:10Z"}, {"author": "Deb Cooley", "text": "

If you have more than one cert that is good for the job, you still get to pick.

", "time": "2023-11-06T10:25:34Z"}, {"author": "Erik Nygren", "text": "

This flag seems quite useful for a range of use-cases that want to have a mix of human and API client users on the same endpoint

", "time": "2023-11-06T10:25:37Z"}, {"author": "Eric Rescorla", "text": "

Deb Cooley said:

\n
\n

If you have more than one cert that is good for the job, you still get to pick.

\n
\n

Don't get me started on that UI

", "time": "2023-11-06T10:25:47Z"}, {"author": "Deb Cooley", "text": "

yeah, I know

", "time": "2023-11-06T10:25:58Z"}, {"author": "Yoav Nir", "text": "

It's really not \"I have certificate\" It's \"I have a certificate for this server\"

", "time": "2023-11-06T10:26:07Z"}, {"author": "Richard Barnes", "text": "

CertificateRequestIfYouWanna

", "time": "2023-11-06T10:26:30Z"}, {"author": "Deb Cooley", "text": "

clients don't get certs for a specific server.

", "time": "2023-11-06T10:26:31Z"}, {"author": "Deb Cooley", "text": "

right?

", "time": "2023-11-06T10:26:37Z"}, {"author": "Eric Rescorla", "text": "

That's called FIDO

", "time": "2023-11-06T10:26:51Z"}, {"author": "Thom Wiggers", "text": "

In theory no, in practice maybe?

", "time": "2023-11-06T10:26:53Z"}, {"author": "Thom Wiggers", "text": "

I remember getting a client cert to sign in to StartSSL back in the day

", "time": "2023-11-06T10:27:04Z"}, {"author": "Yoav Nir", "text": "

Sure they do. Some years ago my bank tried to use certificates for online banking. That cert would not work for gmail or any other server.

", "time": "2023-11-06T10:27:05Z"}, {"author": "Thom Wiggers", "text": "

the only time I ever used one

", "time": "2023-11-06T10:27:09Z"}, {"author": "Deb Cooley", "text": "

SMH

", "time": "2023-11-06T10:27:24Z"}, {"author": "Richard Barnes", "text": "

but certs are not provisioned on a per-site basis

", "time": "2023-11-06T10:27:25Z"}, {"author": "Richard Barnes", "text": "

maybe you can filter in CertificateRequest?

", "time": "2023-11-06T10:27:43Z"}, {"author": "Deb Cooley", "text": "

do bots use browsers?

", "time": "2023-11-06T10:27:50Z"}, {"author": "David Benjamin", "text": "
\n

It seems like multi-CA could be done in 1-RTT by letting the server say \"also I have these other roots if you prefer\". That's slower but if heuristics can guess the CA right 98% of the time then maybe it's fine.

\n
\n

Heuristics can really only be deployed by large server providers, who can fingerprint ClientHellos to make guesses about client preferences. For something broadly applicable, I think it's important to have something more precise. The heuristic strategy also means we're implicitly assuming that extension order, etc., covers this information, so all the downside with none of the benefit.

", "time": "2023-11-06T10:27:56Z"}, {"author": "Thom Wiggers", "text": "

not just bytes, also the UI implications! Scary popups and everything!

", "time": "2023-11-06T10:28:03Z"}, {"author": "Richard Barnes", "text": "

@deb they use TLS clients!

", "time": "2023-11-06T10:28:04Z"}, {"author": "Yoav Nir", "text": "

User certificate are provisioned on a per-site basis.

", "time": "2023-11-06T10:28:42Z"}, {"author": "Thom Wiggers", "text": "

Bots might well use browsers, there's APIs to control web browsers from code

", "time": "2023-11-06T10:28:43Z"}, {"author": "Yoav Nir", "text": "

All that said, I am , of course, in favor of any thing that uses TLS flags

", "time": "2023-11-06T10:29:02Z"}, {"author": "Erik Nygren", "text": "

There are a bunch of use-cases where browsers and other sorts of clients get mixed together and where for the latter client certs are vastly better than IP ACLs. (I really hate IP ACLs.)

", "time": "2023-11-06T10:29:04Z"}, {"author": "Thom Wiggers", "text": "

Thanks everyone, lots of good discussion

", "time": "2023-11-06T10:30:04Z"}]