[{"author": "Martin Thomson", "text": "

Keep the conversations Sybil

", "time": "2023-07-26T20:02:26Z"}, {"author": "Martin Thomson", "text": "

It's the Dennis Jackson show

", "time": "2023-07-26T20:03:32Z"}, {"author": "Martin Thomson", "text": "

I for one welcome our new overlords.

", "time": "2023-07-26T20:03:58Z"}, {"author": "Richard Barnes", "text": "

@Martin Thomson Cumaean or Delphic Sybil?

", "time": "2023-07-26T20:05:42Z"}, {"author": "Martin Thomson", "text": "

@Benjamin Schwartz I'm not seeing how this would include ALPN

", "time": "2023-07-26T20:08:17Z"}, {"author": "Christian Huitema", "text": "

+1 on ECH on port != 443!

", "time": "2023-07-26T20:10:03Z"}, {"author": "Benjamin Kaduk", "text": "

Yeah, for issue #10 the SVCB spec is (IIRC) pretty clear on the qname to use

", "time": "2023-07-26T20:10:19Z"}, {"author": "Richard Barnes", "text": "

wait, so things work better with ECH?

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

i guess you're also subsetting in other ways

", "time": "2023-07-26T20:12:05Z"}, {"author": "Thom Wiggers", "text": "

Nightly users have more reliable connections

", "time": "2023-07-26T20:12:05Z"}, {"author": "Christopher Wood", "text": "

@Richard at the mic?

", "time": "2023-07-26T20:12:06Z"}, {"author": "Benjamin Kaduk", "text": "

PeopleServers willing to advertise new stuff have not-broken setups?

", "time": "2023-07-26T20:12:16Z"}, {"author": "Thom Wiggers", "text": "

Nightly/Beta users probably include lots of developers

", "time": "2023-07-26T20:12:38Z"}, {"author": "Martin Thomson", "text": "

Nightly is pretty small. Beta is not as highly correlated with \"developers\" as you might expect; the results we get from Beta are usually very strange in surprising ways.

", "time": "2023-07-26T20:18:16Z"}, {"author": "Daniam Henriques", "text": "

With the 1% trials, does that mean a subset of stable releases downloaded ship with ech=enabled?

", "time": "2023-07-26T20:19:25Z"}, {"author": "Martin Thomson", "text": "

experimental design varies, but the usual practice is to have the feature dynamically updated

", "time": "2023-07-26T20:19:47Z"}, {"author": "Thom Wiggers", "text": "

^ i.e. it fetches a set of settings from the internet

", "time": "2023-07-26T20:20:04Z"}, {"author": "Martin Thomson", "text": "

that is, all browsers ask a server periodically for what to do

", "time": "2023-07-26T20:20:10Z"}, {"author": "Daniam Henriques", "text": "

ah, thanks a lot

", "time": "2023-07-26T20:20:10Z"}, {"author": "Thom Wiggers", "text": "

alternatively you could of course randomly sample a number between [1,100] and check if the value == 42 and you have 1%; no need to have separate binaries :p

", "time": "2023-07-26T20:20:47Z"}, {"author": "Thom Wiggers", "text": "

(no idea what Chrome does, probably what MT said tho)

", "time": "2023-07-26T20:21:15Z"}, {"author": "Martin Thomson", "text": "

not all intermediates, but all unconstrained intermediates

", "time": "2023-07-26T20:21:18Z"}, {"author": "Thom Wiggers", "text": "

all intermediates for large enough values of all

", "time": "2023-07-26T20:21:40Z"}, {"author": "Martin Thomson", "text": "

the usual practice here is to have a unique client ID and then you select a subset of prf(client_id) values to enable the feature on

", "time": "2023-07-26T20:21:51Z"}, {"author": "Martin Thomson", "text": "

it turns out that X.509 is verbose in the extreme. OIDs are easy to compress

", "time": "2023-07-26T20:23:48Z"}, {"author": "Benjamin Kaduk", "text": "

I remember that back when we were doing RFC 8478, there was a bit of pondering about whether it would make sense to publish a public dictionary that's pre-distributed for use in a given context :)

", "time": "2023-07-26T20:24:25Z"}, {"author": "Stephen Farrell", "text": "

CA's cutting and pasting binary data into a web form that then ends up being passed into x.509 libraries - hmm, what could go wrong? I guess browsers can check 1st though

", "time": "2023-07-26T20:24:50Z"}, {"author": "Martin Thomson", "text": "

@Stephen Farrell the only cost there is that compression performance degrades ever so slightly. And it should be easy to automate some sort of validation process before the value is committed.

", "time": "2023-07-26T20:25:31Z"}, {"author": "Thom Wiggers", "text": "

AIUI the binary data is used to generate the compression dictionary so it's passed to zstd, not x.509 parsers

", "time": "2023-07-26T20:25:38Z"}, {"author": "Corey Bonnell", "text": "

Martin Thomson said:

\n
\n

not all intermediates, but all unconstrained intermediates

\n
\n

CAs now need to disclose all CA certs in CCADB regardless of whether there's technical constraints. This is a recent change from just a year or two ago

", "time": "2023-07-26T20:26:19Z"}, {"author": "Benjamin Kaduk", "text": "
\n

deployed with a yearly software update

\n
\n

Paging Peter Gutmann

", "time": "2023-07-26T20:26:21Z"}, {"author": "Martin Thomson", "text": "

@Corey Bonnell I wasn't sure that we'd picked up those for distribution. Maybe we do just pass them down. (It's a good change though.)

", "time": "2023-07-26T20:27:07Z"}, {"author": "Martin Thomson", "text": "

That \"optimal\" measure is unattainable, so this is much closer to an ideal than the slides might imply.

", "time": "2023-07-26T20:28:59Z"}, {"author": "Christian Huitema", "text": "

I love the confidence, \"we are not introducing any cause of errors\"!

", "time": "2023-07-26T20:29:08Z"}, {"author": "Benjamin Kaduk", "text": "

It's attainable...if you allocate a compression codepoint for each intermediate CA

", "time": "2023-07-26T20:29:26Z"}, {"author": "Jonathan Hoyland", "text": "

Is there any security question from pairing encryption with compression?

", "time": "2023-07-26T20:30:17Z"}, {"author": "Watson Ladd", "text": "

shills SQI-Sign at the sidh shore

", "time": "2023-07-26T20:30:48Z"}, {"author": "Benjamin Kaduk", "text": "

There shouldn't be any confidential data going into the compression input, AIUI

", "time": "2023-07-26T20:30:55Z"}, {"author": "Martin Thomson", "text": "

@Jonathan Hoyland only to the same extent that the length of the chain is revealing

", "time": "2023-07-26T20:30:56Z"}, {"author": "Stephen Farrell", "text": "

I'd be for adoption

", "time": "2023-07-26T20:31:09Z"}, {"author": "Martin Thomson", "text": "

But what @Benjamin Kaduk says applies, the classic concern about mixing data from different security levels doesn't apply

", "time": "2023-07-26T20:31:24Z"}, {"author": "Benjamin Kaduk", "text": "

This is fine and interesting, but it also seems that it could be done outside the WG if we weren't interested

", "time": "2023-07-26T20:31:47Z"}, {"author": "Stephen Farrell", "text": "

we have the tz database

", "time": "2023-07-26T20:32:51Z"}, {"author": "Jonathan Hoyland", "text": "

I can't remember the context, but I remember there was some crazy attack by guessing data and doing a timing attack on the decompression algorithm

", "time": "2023-07-26T20:32:58Z"}, {"author": "Christopher Inacio", "text": "

@hoyland I can't imagine how the compression here interacts with with the encryption beyond certificate validation; and in that case, its really much more just compression of \"text\" in the certificate.

", "time": "2023-07-26T20:33:12Z"}, {"author": "Daniel Gillmor", "text": "

we also have the public suffix list, and the dns root certificates

", "time": "2023-07-26T20:33:33Z"}, {"author": "Thom Wiggers", "text": "

Pretty sure those attacks (was it BREACH? --> no CRIME) require varying data, but this scheme compresses the exact same amount of data each time?

", "time": "2023-07-26T20:33:43Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Jonathan Hoyland are you thinking of TLS CRIME?

", "time": "2023-07-26T20:33:49Z"}, {"author": "Thom Wiggers", "text": "

ah that was it

", "time": "2023-07-26T20:34:11Z"}, {"author": "Jonathan Hoyland", "text": "

@Alex Chernyakhovsky Yes!

", "time": "2023-07-26T20:34:35Z"}, {"author": "Jonathan Hoyland", "text": "

That was it

", "time": "2023-07-26T20:34:42Z"}, {"author": "Christian Huitema", "text": "

Make the cert code twice longer and allow for entries in the list as shortish hashes?

", "time": "2023-07-26T20:34:55Z"}, {"author": "Jonathan Hoyland", "text": "

Ah ok, and it doesn't apply here?

", "time": "2023-07-26T20:34:58Z"}, {"author": "Benjamin Kaduk", "text": "

One could perhaps have a codepoint for site-specific use and let people do their own thing if they want

", "time": "2023-07-26T20:35:12Z"}, {"author": "Daniel Gillmor", "text": "

and the wireless-registration database. i've been trying to tag this sort of universally-distributed data for debian over here: https://salsa.debian.org/explore/projects/topics/real-world-data

", "time": "2023-07-26T20:35:12Z"}, {"author": "Christopher Inacio", "text": "

But the database in this case is pre-distributed; so its minimal change to encrypted stream.

", "time": "2023-07-26T20:35:15Z"}, {"author": "Alex Chernyakhovsky", "text": "

I don't think this scheme is vulnerable to the type of problem that TLS CRIME was because there's no user-provided data here

", "time": "2023-07-26T20:35:36Z"}, {"author": "Jonathan Hoyland", "text": "

The attacker can vary the sending cert, because this is before auth can happen

", "time": "2023-07-26T20:35:49Z"}, {"author": "Jonathan Hoyland", "text": "

Ah, right

", "time": "2023-07-26T20:35:58Z"}, {"author": "Benjamin Kaduk", "text": "

Welllll...if we are talking about using this for post-quantum certs, then we'll get people wanting to use post-quantum user certs and trying to compress those.

", "time": "2023-07-26T20:36:43Z"}, {"author": "Jonathan Hoyland", "text": "

But a malicious server (pre-auth) could vary stuff

", "time": "2023-07-26T20:37:00Z"}, {"author": "Daniel Gillmor", "text": "

they'll try to compress a p-q signature in the ee cert anyway, even if the ee cert isn't pq itself

", "time": "2023-07-26T20:37:20Z"}, {"author": "Martin Thomson", "text": "

it's a good thing that there is a performance motivation for keeping your client updated (as if there weren't ample OTHER reasons)

", "time": "2023-07-26T20:37:59Z"}, {"author": "Thom Wiggers", "text": "

@Jonathan Hoyland RFC8879 already offers certificate compression; perhaps you can find some details on the applicability of these attacks in the history of that RFC

", "time": "2023-07-26T20:38:06Z"}, {"author": "Jonathan Hoyland", "text": "

Good idea

", "time": "2023-07-26T20:39:11Z"}, {"author": "Eric Rescorla", "text": "

Maybe we could compress the post-quantum algorithms using classical algorithms

", "time": "2023-07-26T20:39:40Z"}, {"author": "Deb Cooley", "text": "

SMH

", "time": "2023-07-26T20:40:09Z"}, {"author": "Benjamin Kaduk", "text": "

Why is the IESG in an ivory tower? Could it be an ebony tower?

", "time": "2023-07-26T20:40:14Z"}, {"author": "Jonathan Hoyland", "text": "

Isn't ebony also a protected species?

", "time": "2023-07-26T20:40:46Z"}, {"author": "David Benjamin", "text": "

One would hope PQ keys and sigs themselves are not compressible. That would mean we defined them wrong and could have made them more size efficient. :-)

", "time": "2023-07-26T20:40:58Z"}, {"author": "Benjamin Kaduk", "text": "

For some definition of protected, yes, I think. Some level of certification and origin-tracking for legal shipments

", "time": "2023-07-26T20:41:17Z"}, {"author": "Daniel Gillmor", "text": "

quantum safe compression is used when you don't want quantum computers to be able to decompress the data

", "time": "2023-07-26T20:41:33Z"}, {"author": "Mike Ounsworth", "text": "

Reply to @Martin Thomson 's at-mic comment:
\nPrivate CAs tend to be ... private. They probably don't want the dictionaries of their cert contents to be public. (I hope that's not what you were suggesting).

", "time": "2023-07-26T20:41:42Z"}, {"author": "David Benjamin", "text": "

Of course, the X.509 crap surrounding the (PQ|classical) cryptographic material is quite compressible... one could argue this is really a symptom of X.509 being a terrible, terrible format.

", "time": "2023-07-26T20:41:53Z"}, {"author": "Martin Thomson", "text": "

@Mike Ounsworth a codepoint registration does not require that you publish the details of the algorithm (I believe it is optional)

", "time": "2023-07-26T20:42:24Z"}, {"author": "Daniel Gillmor", "text": "

@David Benjamin maybe we should be using the term \"abridgable\" for the certs, since parts of the certs absolutely should not be compressible.

", "time": "2023-07-26T20:42:25Z"}, {"author": "Mike Ounsworth", "text": "

Martin Thomson said:

\n
\n

Mike Ounsworth a codepoint registration does not require that you publish the details of the algorithm (I believe it is optional)

\n
\n

As long as you're liberal on what \"specification required\" means.

", "time": "2023-07-26T20:44:08Z"}, {"author": "Roman Danyliw", "text": "

I had trouble following the action that the WG needs the ADs to look into -- I thought I heard (a) \"there might be something out of the ordinary here can the ADs check that this would work\"; and then (b) \"we don't need the IESG consultation this would be a community decision\".

", "time": "2023-07-26T20:44:38Z"}, {"author": "Kazuho Oku", "text": "

Sounds essentially like each existing CA pushing their intermediate CA certificate to clients (modulo the compression of OIDs).

", "time": "2023-07-26T20:44:48Z"}, {"author": "Thom Wiggers", "text": "

Ben makes a good point when the enterprise dictionaries enter the picture though

", "time": "2023-07-26T20:44:49Z"}, {"author": "Deb Cooley", "text": "

Enterprise dictionaries should be pushed to the enterprises

", "time": "2023-07-26T20:45:37Z"}, {"author": "Benjamin Kaduk", "text": "

Roman Danyliw said:

\n
\n

I had trouble following the action that the WG needs the ADs to look into -- I thought I heard (a) \"there might be something out of the ordinary here can the ADs check that this would work\"; and then (b) \"we don't need the IESG consultation this would be a community decision\".

\n
\n

The draft currently specifies a procedure that all clients and servers use independently to fetch data from an external source and construct the concrete tangible database to use. More often the IETF publishes the actual database rather than having people independently recompute that. Are we sure?

", "time": "2023-07-26T20:45:48Z"}, {"author": "Daniel Gillmor", "text": "

+1 @Benjamin Schwartz

", "time": "2023-07-26T20:45:51Z"}, {"author": "Martin Thomson", "text": "

It seems like a little bit of discussion in the draft regarding the privacy properties is worthwhile.

", "time": "2023-07-26T20:46:21Z"}, {"author": "Daniel Gillmor", "text": "

each additional bit of differentiation is part of the fingerprint scope

", "time": "2023-07-26T20:46:30Z"}, {"author": "Roman Danyliw", "text": "

@Kaduk -- thanks.

", "time": "2023-07-26T20:47:00Z"}, {"author": "Martin Thomson", "text": "

enterprise_cert_compression that contains a list of enterprise numbers

", "time": "2023-07-26T20:47:15Z"}, {"author": "Deb Cooley", "text": "

Many times enterprise cert chains aren't publically trusted because they don't follow CAB Forum rules, not because they are 'private'.

", "time": "2023-07-26T20:48:04Z"}, {"author": "Deb Cooley", "text": "

Certainly US Fed PKI Roots and Intermediate certs are discoverable.

", "time": "2023-07-26T20:48:45Z"}, {"author": "Jonathan Hoyland", "text": "

How cacheable is this on the server side?

", "time": "2023-07-26T20:49:04Z"}, {"author": "Jonathan Hoyland", "text": "

100% at best compression should be possible, no?

", "time": "2023-07-26T20:49:37Z"}, {"author": "Thom Wiggers", "text": "

I think the draft just lets you set up the server with a static string

", "time": "2023-07-26T20:49:37Z"}, {"author": "Kazuho Oku", "text": "

I think we'd want to recompress every time OCSP stapling is updated, because compressing them as one would give us better compression?

", "time": "2023-07-26T20:50:01Z"}, {"author": "Thom Wiggers", "text": "

ah that's a good shout

", "time": "2023-07-26T20:50:27Z"}, {"author": "Martin Thomson", "text": "

https://github.com/dennisjackson/draft-jackson-tls-cert-abridge/issues/10

", "time": "2023-07-26T20:51:38Z"}, {"author": "Mike Ounsworth", "text": "

TLS 1.2 is frozen.
\nIn addition to accepting deprecations to address new attacks, you do also need to be able to fix broken logic, should someone discover some flaw in the documented logic.

", "time": "2023-07-26T20:53:35Z"}, {"author": "Benjamin Kaduk", "text": "

You can always un-freeze it right before fixing it :)

", "time": "2023-07-26T20:54:42Z"}, {"author": "Yoav Nir", "text": "

I don't get why we need this. This is a document that does nothing except bind the hands of the TLS working group.

", "time": "2023-07-26T20:55:26Z"}, {"author": "David Benjamin", "text": "

If we need to make an actual protocol change to TLS 1.2 to fix a bug, that won't fix the existing TLS 1.2 servers anyway. They would need to take a code change, at which point they should pick up the code change that gives them TLS 1.3.

", "time": "2023-07-26T20:55:47Z"}, {"author": "Yoav Nir", "text": "

If we don't want to TLS 1.2 algorithms, let's not standardize new algorithms for 1.2

", "time": "2023-07-26T20:55:51Z"}, {"author": "Daniel Gillmor", "text": "

@Yoav Nir that is absolutely the point. we want to be able to easily turn people away who come trying to tweak 1.2

", "time": "2023-07-26T20:55:55Z"}, {"author": "David Benjamin", "text": "

If there is an issue that an implementation can unilaterally fix, then yeah it probably makes sense to apply the fix. But those are pretty rare and usually look like \"remove this bad cipher suite\".

", "time": "2023-07-26T20:56:36Z"}, {"author": "David Benjamin", "text": "

By unilaterally I mean, e.g., TLS 1.2 clients can protect themselves and it fixes existing TLS 1.2 servers (or vice versa) without changing them.

", "time": "2023-07-26T20:57:48Z"}, {"author": "Mike Ounsworth", "text": "

I'm thinking of a Bleichenbacher type fix, which I believe was a unilateral fix of checking the padding properly (yes yes I'm aware that the 1.2 spec got it right but implementers just didn't implement properly).

", "time": "2023-07-26T20:57:50Z"}, {"author": "David Benjamin", "text": "

Ah, fair, that was also a unilateral-type fix.

", "time": "2023-07-26T20:58:25Z"}, {"author": "Benjamin Kaduk", "text": "

The SEC ADs can arguably already do the bit about \"new stuff MUST support TLS 1.3\"

", "time": "2023-07-26T20:59:23Z"}, {"author": "David Benjamin", "text": "

(I would argue the Bleichenbacher fix is a workaround for a broken cryptographic primitive used in RSA key exchange. It's true that implementors often implemented the workaround wrong, but the root problem is that RSAES-PKCS1-v1_5 is bust. But that's splitting hairs. :smile: )

", "time": "2023-07-26T20:59:43Z"}, {"author": "Martin Thomson", "text": "

I disagree with @David Schinazi. As much as I hate to admit it, signaling/posturing has a real effect.

", "time": "2023-07-26T21:00:44Z"}, {"author": "Mike Bishop", "text": "

This isn't intended to bind the IETF, it's intended to signal to the industry that TLS 1.2 is no longer maintained.

", "time": "2023-07-26T21:00:47Z"}, {"author": "Jonathan Hoyland", "text": "

Some people like 1.2 and want to keep it because of the certificate leakage. If you want to keep certificate leakage but not use a broken cipher suite, maybe there is some logic to not freezing 1.2?

", "time": "2023-07-26T21:01:01Z"}, {"author": "Eric Orth", "text": "

Counter to what David is saying: I think it is useful to write down as the plan of record that we don't want to modify 1.2 any more. Saying our thinking and intent is always as far as RFCs can go because we can always change our mind and revise things in the future.

", "time": "2023-07-26T21:01:28Z"}, {"author": "Yoav Nir", "text": "

The word is deprecate

", "time": "2023-07-26T21:01:45Z"}, {"author": "Benjamin Kaduk", "text": "

I think Schinazi is right that the charter update would be more strongly binding than what this draft does, though that's mostly orthogonal to whether we want to do what this draft does

", "time": "2023-07-26T21:02:02Z"}, {"author": "Martin Thomson", "text": "

depreciation is a useful concept though

", "time": "2023-07-26T21:02:02Z"}, {"author": "Jonathan Hoyland", "text": "

TLS-1.2-die-die-die?

", "time": "2023-07-26T21:02:03Z"}, {"author": "David Benjamin", "text": "

@Jonathan Hoyland Seems that's exactly a group of folks who'd benefit from us signaling we have no intention of adding new stuff to TLS 1.2.

", "time": "2023-07-26T21:02:10Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan Hoyland too soon, sadly

", "time": "2023-07-26T21:02:26Z"}, {"author": "Martin Thomson", "text": "

TLS 1.2 continues to depreciate in value every day

", "time": "2023-07-26T21:02:31Z"}, {"author": "David Schinazi", "text": "

So it's not like fine wine?

", "time": "2023-07-26T21:02:47Z"}, {"author": "Alex Chernyakhovsky", "text": "

TLS1.2 is fine, until it's not

", "time": "2023-07-26T21:03:03Z"}, {"author": "Martin Thomson", "text": "

definitely not a fine wine, and not even something that you can use as a tax offset

", "time": "2023-07-26T21:03:14Z"}, {"author": "Eric Orth", "text": "

It's already rotting.

", "time": "2023-07-26T21:03:21Z"}, {"author": "David Schinazi", "text": "

@Alex Ah yes, like driving off a cliff

", "time": "2023-07-26T21:03:21Z"}, {"author": "Richard Barnes", "text": "

would we fix TLS 1.2 in the event of a catastrophic break?

", "time": "2023-07-26T21:03:30Z"}, {"author": "Daniel Gillmor", "text": "

TLS 1.2: worth 8% less than TLS 1.3 (\u2190 depreciation)

", "time": "2023-07-26T21:03:30Z"}, {"author": "Martin Thomson", "text": "

TLS 1.2, aging like a high-pitched whine

", "time": "2023-07-26T21:03:41Z"}, {"author": "David Schinazi", "text": "

@MT nice

", "time": "2023-07-26T21:03:48Z"}, {"author": "Roman Danyliw", "text": "

As a balloting AD, having a consensus BCP which says \"MUST use TLS 1.3\" is helpful basis for authoring a short(er) DISCUSS.

", "time": "2023-07-26T21:04:37Z"}, {"author": "John Preu\u00df Mattsson", "text": "

The future can always revert the decision to not add anything to TLS 1.2

", "time": "2023-07-26T21:05:05Z"}, {"author": "Jonathan Hoyland", "text": "

Roman Danyliw said:

\n
\n

As a balloting AD, having a consensus BCP which says \"MUST use TLS 1.3\" is helpful basis for authoring a short(er) DISCUSS.

\n
\n

MUST use latest TLS

", "time": "2023-07-26T21:05:11Z"}, {"author": "John Preu\u00df Mattsson", "text": "

+1 for conveying a very strong message.

", "time": "2023-07-26T21:05:25Z"}, {"author": "Daniel Gillmor", "text": "

the longer they need to transition, the stronger and clearer we need to be about what they need to do.

", "time": "2023-07-26T21:05:37Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Anyone not listening can continue to use TLS 1.2

", "time": "2023-07-26T21:05:39Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Jonathan Hoyland is it worth specify what at the time of writing the latest version is, to lower bound it?

", "time": "2023-07-26T21:05:57Z"}, {"author": "Martin Thomson", "text": "

There are things that you can't do with TLS 1.3. Generally, that is a good thing.

", "time": "2023-07-26T21:06:34Z"}, {"author": "Jonathan Hoyland", "text": "

Alex Chernyakhovsky said:

\n
\n

Jonathan Hoyland is it worth specify what at the time of writing the latest version is, to lower bound it?

\n
\n

MUST use the latest TLS. As of this writing the latest version of TLS is TLS 1.3. This will change in the future. Hopefully.

", "time": "2023-07-26T21:06:50Z"}, {"author": "David Schinazi", "text": "

Aren't the \"features of TLS 1.2 that 1.3 doesn't have\" things that this WG believes to be bugs?

", "time": "2023-07-26T21:07:05Z"}, {"author": "Mike Ounsworth", "text": "

@Deb Cooley what was your point there? Do you think those enterprises that depend on TLS 1.2 features will also continue to need new features added to 1.2? Like, are you objecting to a feature freeze?

", "time": "2023-07-26T21:07:06Z"}, {"author": "Jonathan Hoyland", "text": "

David Schinazi said:

\n
\n

Aren't the \"features of TLS 1.2 that 1.3 doesn't have\" things that this WG believes to be bugs?

\n
\n

Yes.

", "time": "2023-07-26T21:07:16Z"}, {"author": "Martin Thomson", "text": "

Thing you can do in TLS 1.2 that you can't (easily) do in TLS 1.3: configure it badly.

", "time": "2023-07-26T21:07:35Z"}, {"author": "Jonathan Hoyland", "text": "

Leak certs, and passive monitoring seem to be the main two.

", "time": "2023-07-26T21:07:39Z"}, {"author": "Eric Orth", "text": "

For most of the things those enterprises want, probably yes.

", "time": "2023-07-26T21:07:59Z"}, {"author": "Martin Thomson", "text": "

Aren't there CBC attacks?

", "time": "2023-07-26T21:08:13Z"}, {"author": "Deb Cooley", "text": "

The enterprises I provide guidance for are resigned to not having new features. They do believe they need the current features. (do I agree w/ them? meh)

", "time": "2023-07-26T21:08:21Z"}, {"author": "Erik Nygren", "text": "

But that might be worth acknowleding. \"If your environment relies on protocol vulnerabilities in TLS 1.2 you will need to come up with some other solution.\"

", "time": "2023-07-26T21:09:07Z"}, {"author": "Tero Kivinen", "text": "

My understanding was that using client side authentication with smartcards etc is something that is not that easy on TLS-1.3. I.e., the renegotiation stuff where you first connect without client side authentication and then start requiring it when you click in login...

", "time": "2023-07-26T21:09:22Z"}, {"author": "Benjamin Kaduk", "text": "

\"We retain change control over TLS protocols, and have no intent to do things to TLS 1.2\" and \"TLS 1.2 is frozen\" seem pretty equivalent to me

", "time": "2023-07-26T21:09:27Z"}, {"author": "Thom Wiggers", "text": "

@Tero: the protocol supports that just fine with post-handshake auth

", "time": "2023-07-26T21:09:47Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Benjamin Kaduk I think \"we do not intend to do things\" seems to be a bit more malleable in that is more obviously allows for breakfix work

", "time": "2023-07-26T21:10:15Z"}, {"author": "Jonathan Hoyland", "text": "

Tero Kivinen said:

\n
\n

My understanding was that using client side authentication with smartcards etc is something that is not that easy on TLS-1.3. I.e., the renegotiation stuff where you first connect without client side authentication and then start requiring it when you click in login...

\n
\n

TLS 1.3 has post-handshake auth, but I don't like it. You should use EAs.

", "time": "2023-07-26T21:10:24Z"}, {"author": "Eric Orth", "text": "

All the arguments that enterprises still need 1.2 just sound like reasons to not deprecate, but this proposal isn't such a deprecation.

", "time": "2023-07-26T21:10:26Z"}, {"author": "Tero Kivinen", "text": "

Thom Wiggers said:

\n
\n

@Tero: the protocol supports that just fine with post-handshake auth

\n
\n

how do you configure that on apache?

", "time": "2023-07-26T21:10:32Z"}, {"author": "Richard Barnes", "text": "

think of the children^Wenterprises

", "time": "2023-07-26T21:10:56Z"}, {"author": "John Preu\u00df Mattsson", "text": "

+1

", "time": "2023-07-26T21:11:03Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Please don't

", "time": "2023-07-26T21:11:13Z"}, {"author": "Jonathan Hoyland", "text": "

Tero Kivinen said:

\n
\n

Thom Wiggers said:

\n
\n

@Tero: the protocol supports that just fine with post-handshake auth

\n
\n

how do you configure that on apache?

\n
\n

That sounds like a feature request for Apache, not a limitation of TLS 1.3.

", "time": "2023-07-26T21:11:42Z"}, {"author": "Thom Wiggers", "text": "

@Tero: idk, how do you do it in 1.2?

", "time": "2023-07-26T21:11:46Z"}, {"author": "Thom Wiggers", "text": "

shouldn't have to be different

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

Deb++

", "time": "2023-07-26T21:13:13Z"}, {"author": "Tero Kivinen", "text": "

Thom Wiggers said:

\n
\n

shouldn't have to be different

\n
\n

https://id.acr.fi/login.html has the config for apache, when I was writing those instructions I had to disable TLS-1.3, as the smartcard stuff did not work if using TLS-1.3. (the instructions are in Finnish as they tell how to do that for Finnish identity card)

", "time": "2023-07-26T21:13:30Z"}, {"author": "Mike Bishop", "text": "

Tero Kivinen said:

\n
\n

Thom Wiggers said:

\n
\n

@Tero: the protocol supports that just fine with post-handshake auth

\n
\n

how do you configure that on apache?

\n
\n

If an application doesn't support some feature of the TLS protocol, take that up with the application. That said, Apache is HTTP, and HTTP doesn't have that feature. The draft died because there wasn't implementation interest. If that has changed, come to HTTP tomorrow and argue to bring back the client cert side of Secondary Certs as well.

", "time": "2023-07-26T21:14:19Z"}, {"author": "Jonathan Hoyland", "text": "

Mike Bishop said:

\n
\n

Tero Kivinen said:

\n
\n

Thom Wiggers said:

\n
\n

@Tero: the protocol supports that just fine with post-handshake auth

\n
\n

how do you configure that on apache?

\n
\n

If an application doesn't support some feature of the TLS protocol, take that up with the application. That said, Apache is HTTP, and HTTP doesn't have that feature. The draft died because there wasn't implementation interest. If that has changed, come to HTTP tomorrow and argue to bring back the client cert side of Secondary Certs as well.

\n
\n

I will already be there arguing that :P

", "time": "2023-07-26T21:14:50Z"}, {"author": "Jonathan Hoyland", "text": "

Would appreciate the backup

", "time": "2023-07-26T21:15:13Z"}, {"author": "Thom Wiggers", "text": "

@Tero: I can't speak to the details but in general smartcard authentication in the browser is probably better handled through javascript APIs anyway for better usability

", "time": "2023-07-26T21:15:24Z"}, {"author": "A.J. Stein", "text": "

Why can't these organizations send individuals that represent their position? Each person that has spoken of them, has spoken of them as a separate entity in the third person. Surely they can come represent themselves?

", "time": "2023-07-26T21:15:30Z"}, {"author": "Tero Kivinen", "text": "

Now I simply say you have to use \"SSLProtocol -ALL -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2\" because it did not work if TLSv1.3 was there.

", "time": "2023-07-26T21:16:00Z"}, {"author": "Christian Huitema", "text": "

We all particpate as individuals

", "time": "2023-07-26T21:16:01Z"}, {"author": "Martin Thomson", "text": "

@Tero Kivinen I hope you aren't suggesting use of 1.0 or 1.1

", "time": "2023-07-26T21:16:38Z"}, {"author": "A.J. Stein", "text": "

Christian Huitema said:

\n
\n

We all particpate as individuals

\n
\n

Thus my point. :-)

", "time": "2023-07-26T21:16:48Z"}, {"author": "Jonathan Hoyland", "text": "

We are all individuals. (According to Monty Python)

", "time": "2023-07-26T21:17:09Z"}, {"author": "Tero Kivinen", "text": "

Martin Thomson said:

\n
\n

Tero Kivinen I hope you aren't suggesting use of 1.0 or 1.1

\n
\n

I am not suggesting using them, but there are still people using them so they need to be enabled...

", "time": "2023-07-26T21:17:18Z"}, {"author": "Martin Thomson", "text": "

:grimacing:

", "time": "2023-07-26T21:17:50Z"}, {"author": "Martin Thomson", "text": "

I am not thrilled about having this split into two

", "time": "2023-07-26T21:17:57Z"}, {"author": "Benjamin Kaduk", "text": "

A.J. Stein said:

\n
\n

Why can't these organizations send individuals that represent their position? Each person that has spoken of them, has spoken of them as a separate entity in the third person. Surely they can come represent themselves?

\n
\n

We've had a handful of such first parties show up over the years to talk about what they do and what they want. Perhaps the most polite thing I can say is that we discovered some irreconcilable differences

", "time": "2023-07-26T21:18:00Z"}, {"author": "Thom Wiggers", "text": "

I would like to also point out a study by Birghan and Van der Merwe showing that client authentication is barely used (much, much less than 0.001%)

", "time": "2023-07-26T21:18:22Z"}, {"author": "Eric Orth", "text": "

That's better support than I expected after that discussion.

", "time": "2023-07-26T21:18:42Z"}, {"author": "Thom Wiggers", "text": "

https://secweb.work/papers/2022/birghan2022clienttls.pdf

", "time": "2023-07-26T21:18:58Z"}, {"author": "Martin Thomson", "text": "

TLS 1.2 is deprecated. The IETF won't continue to enhance the protocol. Use TLS 1.3 (or newer). Done.

", "time": "2023-07-26T21:18:58Z"}, {"author": "Jonathan Hoyland", "text": "

Thom Wiggers said:

\n
\n

I would like to also point out a study by Birghan and Van der Merwe showing that client authentication is barely used (much, much less than 0.001%)

\n
\n

I think that will increase significantly as orgs want to do things like zero trust.

", "time": "2023-07-26T21:19:25Z"}, {"author": "Daniel Gillmor", "text": "

and that is why they need to use TLS 1.3: 1.2 leaks client identities on the wire

", "time": "2023-07-26T21:20:07Z"}, {"author": "Daniel Gillmor", "text": "

client certs are just about the worst rationale for using 1.2 i can possibly imagine
\nand i say that as a one-time advocate for client certs

", "time": "2023-07-26T21:20:39Z"}, {"author": "Erik Nygren", "text": "

As an example, a great use-case for client certs is as a second factor in Enterprise environments as an alternative to IP ACLs in a zero-trust world, but where there is some other authentication (eg, SSO/MFA) being used as the primary factor.

", "time": "2023-07-26T21:20:51Z"}, {"author": "Erik Nygren", "text": "

And yes, for that use-case I'd really like it to become TLS 1.3 only to not leak user identities to the network.

", "time": "2023-07-26T21:21:21Z"}, {"author": "Martin Thomson", "text": "

So we have one that is too big, one that is too hard to implement, and one that is both slow and big

", "time": "2023-07-26T21:21:48Z"}, {"author": "Daniel Gillmor", "text": "

@Martin Thomson we call that \"maximalist\"

", "time": "2023-07-26T21:22:20Z"}, {"author": "Benjamin Kaduk", "text": "

Fast. Small. Secure.
\nPick two or less?

", "time": "2023-07-26T21:22:31Z"}, {"author": "Thom Wiggers", "text": "

EHT is also broken now

", "time": "2023-07-26T21:23:31Z"}, {"author": "Eric Rescorla", "text": "

So we should just use \"EdDSA?\"

", "time": "2023-07-26T21:24:21Z"}, {"author": "Thom Wiggers", "text": "

HAWK does not need floating point hardware which is an important improvement

", "time": "2023-07-26T21:24:26Z"}, {"author": "Eric Rescorla", "text": "

Eric Rescorla said:

\n
\n

So we should just use \"EdDSA?\"

\n
\n

That one seems like the best

", "time": "2023-07-26T21:24:49Z"}, {"author": "Yoav Nir", "text": "

@EKR Yes, seems like a no brainer

", "time": "2023-07-26T21:24:57Z"}, {"author": "Thom Wiggers", "text": "

Eric: that's the obama giving a medal to obama meme :P

", "time": "2023-07-26T21:25:11Z"}, {"author": "Martin Thomson", "text": "

I notice that EdDSA also performs very well on the \"classic security\" axis (not shown)

", "time": "2023-07-26T21:25:27Z"}, {"author": "Jonathan Hoyland", "text": "

Bas is going to send round the boys with the kneecapping sticks.

", "time": "2023-07-26T21:26:24Z"}, {"author": "Eric Rescorla", "text": "

It is somewhat concerning that so many of these algorithms don't seem to survive that axis

", "time": "2023-07-26T21:26:37Z"}, {"author": "Martin Thomson", "text": "

yeah, I'm not going to go out and start putting these into my code

", "time": "2023-07-26T21:27:27Z"}, {"author": "Thom Wiggers", "text": "

I think that our message is in part: these new schemes aren't miracles, so going with the things that are slightly more battle-tested isn't a bad move

", "time": "2023-07-26T21:27:56Z"}, {"author": "Thom Wiggers", "text": "

https://pqshield.github.io/nist-sigs-zoo/

", "time": "2023-07-26T21:28:20Z"}, {"author": "Kris Kwiatkowski", "text": "

Seems Dilithium has set the bar quite high

", "time": "2023-07-26T21:29:06Z"}, {"author": "Martin Thomson", "text": "

35ms (presumably on fairly good hardware) is a bit much

", "time": "2023-07-26T21:31:15Z"}, {"author": "David Benjamin", "text": "

Not to mention 1s signing time.

", "time": "2023-07-26T21:31:35Z"}, {"author": "Deb Cooley", "text": "

try that on a smartcard

", "time": "2023-07-26T21:31:44Z"}, {"author": "Eric Rescorla", "text": "

1s seems fine!

", "time": "2023-07-26T21:31:52Z"}, {"author": "Eric Rescorla", "text": "

The Web is too fast already

", "time": "2023-07-26T21:31:59Z"}, {"author": "Martin Thomson", "text": "

how does PQRSA perform here? or is that only defined as a KEM?

", "time": "2023-07-26T21:32:28Z"}, {"author": "David Benjamin", "text": "

I've seen TPMs take > 2 seconds to do an RSA signature. :-(

", "time": "2023-07-26T21:32:45Z"}, {"author": "Eric Rescorla", "text": "

Is this a new post-quantum signature scheme?

", "time": "2023-07-26T21:33:04Z"}, {"author": "Eric Rescorla", "text": "

That Hoyland has invented

", "time": "2023-07-26T21:33:13Z"}, {"author": "David Benjamin", "text": "

(I mean > 2 seconds to do just plain RSA-2048, not joke RSA key sizes.)

", "time": "2023-07-26T21:33:38Z"}, {"author": "Benjamin Kaduk", "text": "

I said in httpbis-zulip but can say again here: you could use an exporter to get the certificate request context to use

", "time": "2023-07-26T21:35:03Z"}, {"author": "Deb Cooley", "text": "

vs having the server request a client auth?

", "time": "2023-07-26T21:35:54Z"}, {"author": "Benjamin Kaduk", "text": "

The http use case wants the client to do unprompted authentication

", "time": "2023-07-26T21:36:18Z"}, {"author": "Eric Rescorla", "text": "

yeah.

", "time": "2023-07-26T21:36:29Z"}, {"author": "Deb Cooley", "text": "

after the server is authenticated, right?

", "time": "2023-07-26T21:36:38Z"}, {"author": "Eric Rescorla", "text": "

I'm not sure I'm so excited about the general conceot.

", "time": "2023-07-26T21:36:38Z"}, {"author": "Deb Cooley", "text": "

and after we have an encrypted tunnel?

", "time": "2023-07-26T21:36:50Z"}, {"author": "Martin Thomson", "text": "

@Eric Rescorla it's better than the complete reinvention that @David Schinazi was embarking upon.

", "time": "2023-07-26T21:37:01Z"}, {"author": "Benjamin Kaduk", "text": "

Sounds like the chairs need to assign some homework to someone

", "time": "2023-07-26T21:37:04Z"}, {"author": "Eric Rescorla", "text": "

@David Schinazi reinvention enthusiast

", "time": "2023-07-26T21:37:14Z"}, {"author": "Benjamin Kaduk", "text": "

Deb Cooley said:

\n
\n

and after we have an encrypted tunnel?

\n
\n

I think I showed up in the middle of the httpbis discussion ... there may have been a case where you want to do it in 0-RTT?
\nThough Jonathan's comment at the mic suggests not

", "time": "2023-07-26T21:38:04Z"}, {"author": "Deb Cooley", "text": "

shipping a client auth in the clear sounds like a bad idea.

", "time": "2023-07-26T21:38:41Z"}]