[{"author": "Jonathan Hoyland", "text": "

Aren't computers wonderful.

", "time": "2023-03-28T04:01:51Z"}, {"author": "Mike Ounsworth", "text": "

I can take notes, but would appreciate a second note-taker.

", "time": "2023-03-28T04:03:18Z"}, {"author": "Christopher Patton", "text": "

let's deprecate 1.3!

", "time": "2023-03-28T04:03:39Z"}, {"author": "Mike Ounsworth", "text": "

I can take notes, but would appreciate a second note-taker.

", "time": "2023-03-28T04:03:50Z"}, {"author": "Jonathan Hoyland", "text": "

KEMTLS as TLS 1.4?

", "time": "2023-03-28T04:03:56Z"}, {"author": "Christopher Patton", "text": "

SVCB is pretty much deployed?

", "time": "2023-03-28T04:07:35Z"}, {"author": "Benjamin Schwartz", "text": "

Yep, SVCB (well, HTTPS) is live in all browsers and many websites

", "time": "2023-03-28T04:07:57Z"}, {"author": "Amir Omidi", "text": "

That's great to hear

", "time": "2023-03-28T04:08:13Z"}, {"author": "Rich Salz", "text": "

yeah, but support for the ECH extensions? Is such support needed or do they just let people add any SVCB extensions?

", "time": "2023-03-28T04:08:17Z"}, {"author": "Benjamin Schwartz", "text": "

Use of the \"ech\" SVCB key is well-defined but still basically experimental. I'll be talking about the formal status of that in a few minutes.

", "time": "2023-03-28T04:09:26Z"}, {"author": "Rich Salz", "text": "

I am interested in deployment of 'ech' fields in DNS that support SVCB.

", "time": "2023-03-28T04:10:09Z"}, {"author": "Rich Salz", "text": "

Because without DNS support of 'ech' then ECH in TLS is not very useful, IMO

", "time": "2023-03-28T04:10:35Z"}, {"author": "Eric Rescorla", "text": "

Yes, that's correct.

", "time": "2023-03-28T04:10:42Z"}, {"author": "Benjamin Schwartz", "text": "

The \"ech\" key definition is stable, but the contents are an ECHConfigList, which has not reached WGLC, so SVCB is basically not the limiting factor.

", "time": "2023-03-28T04:11:12Z"}, {"author": "Eric Rescorla", "text": "

@Rich Salz I'm not sure I understand your thesis, though. I mean, the DNS kind of needs to be coordinated with the service provider.

", "time": "2023-03-28T04:11:15Z"}, {"author": "Eric Rescorla", "text": "

So, I would imagine any service provider ready to deploy ECH can make SVCB work

", "time": "2023-03-28T04:11:34Z"}, {"author": "Kyle Nekritz", "text": "

We (Meta) will hopefully have some ECH experimentation/deployment within the next couple months as well

", "time": "2023-03-28T04:11:55Z"}, {"author": "Martin Thomson", "text": "

Is the concern that we don't have a good plan for SVCB documents? Because that has been worked out now (and presumably is what we'll be talking about in a few minutes)

", "time": "2023-03-28T04:11:55Z"}, {"author": "Eric Rescorla", "text": "

@Kyle Nekritz AMAZING

", "time": "2023-03-28T04:12:03Z"}, {"author": "Rich Salz", "text": "

Being mostly ignorant, on purpose, of DNS I want to know if 'ech' needs extra work above and beyond SVCB and if, for example, it's supported/supportable in BIKND

", "time": "2023-03-28T04:12:06Z"}, {"author": "Eric Rescorla", "text": "

\\o/

", "time": "2023-03-28T04:12:12Z"}, {"author": "Benjamin Schwartz", "text": "

@Kyle Nekritz WOOHOO

", "time": "2023-03-28T04:12:17Z"}, {"author": "Eric Rescorla", "text": "

We managed to configure the straight HTTPS record in BIND for something

", "time": "2023-03-28T04:12:35Z"}, {"author": "Stephen Farrell", "text": "

@Kyle Nekritz great!

", "time": "2023-03-28T04:12:42Z"}, {"author": "Eric Rescorla", "text": "

though it might have been with an explicit value

", "time": "2023-03-28T04:12:45Z"}, {"author": "Stephen Farrell", "text": "

HTTPS in bind worked just fine far as I've seen

", "time": "2023-03-28T04:13:09Z"}, {"author": "Martin Thomson", "text": "

@Joseph Salowey rsa_fixed_dh and dss_fixed_dh in certificate types seem a little bit like they might need to be \"D\"

", "time": "2023-03-28T04:13:16Z"}, {"author": "Mike Bishop", "text": "

If the DNS server can publish SVCB records, adding particular keys should be minor. But I agree, it'd be good to have confirmation of that from DNS folks.

", "time": "2023-03-28T04:13:20Z"}, {"author": "Stephen Farrell", "text": "

sorry, when I said \"with bind\" I meant publishing ech= values too

", "time": "2023-03-28T04:13:48Z"}, {"author": "Rich Salz", "text": "

If we're waiting on more data from the TLS side to move forward than getting any data from the DNS side seems like something to get as well.

", "time": "2023-03-28T04:14:41Z"}, {"author": "Eric Rescorla", "text": "

Hmm.. I thought we had deployed https but I think I was wrong

", "time": "2023-03-28T04:15:25Z"}, {"author": "Eric Rescorla", "text": "

But note that bind lets you just provide the bytestring and a numeric codepoint

", "time": "2023-03-28T04:15:34Z"}, {"author": "Richard Barnes", "text": "

@EKR if you're still running on bare HTTP, you should really get on that

", "time": "2023-03-28T04:15:55Z"}, {"author": "Eric Rescorla", "text": "

@Richard Barnes HTTP/0.9

", "time": "2023-03-28T04:16:15Z"}, {"author": "Stephen Farrell", "text": "

bind knows about HTTPS now and takes the presentation format, I think NSD last I looked still needed the numeric codepoint but it's been a while

", "time": "2023-03-28T04:16:54Z"}, {"author": "Jonathan Hoyland", "text": "

Yeah, proving agreement on the templates is super important. It needs to be bound into the key-schedule.

", "time": "2023-03-28T04:16:58Z"}, {"author": "Jonathan Hoyland", "text": "

(Also, come to the Usable Formal Methods RG tomorrow :partying_face: )

", "time": "2023-03-28T04:17:50Z"}, {"author": "Christopher Patton", "text": "

+1

", "time": "2023-03-28T04:18:23Z"}, {"author": "Richard Barnes", "text": "

oh no, i hadn't looked to see how much work it would be

", "time": "2023-03-28T04:18:44Z"}, {"author": "Christopher Patton", "text": "

why secp384r1+Kyber768? I would think secp256r1+Kyber768 would be a better choice right now.

", "time": "2023-03-28T04:19:54Z"}, {"author": "Eric Rescorla", "text": "

secp256k1!

", "time": "2023-03-28T04:20:24Z"}, {"author": "Christopher Patton", "text": "

(yes, sorry)

", "time": "2023-03-28T04:20:35Z"}, {"author": "Eric Rescorla", "text": "

(That was a joke)

", "time": "2023-03-28T04:20:45Z"}, {"author": "Christopher Patton", "text": "

:)

", "time": "2023-03-28T04:20:57Z"}, {"author": "Jonathan Hoyland", "text": "

Is there a reason not to put this in an RFC cluster with Kyber, and make the initial codepoint X25519Kyber768?

", "time": "2023-03-28T04:21:54Z"}, {"author": "David Benjamin", "text": "

Let's keep it simple. Boring concatenation works fine here.

", "time": "2023-03-28T04:22:01Z"}, {"author": "Christopher Patton", "text": "

+1 David

", "time": "2023-03-28T04:22:10Z"}, {"author": "Stephen Farrell", "text": "

how's all that kyber IPR stuff going?

", "time": "2023-03-28T04:23:06Z"}, {"author": "Mike Bishop", "text": "

I like the suggestion to have a draft that registers a codepoint but never becomes an RFC. When NIST is done, we let the draft expire and register the final combination elsewhere.

", "time": "2023-03-28T04:28:48Z"}, {"author": "Rich Salz", "text": "

+1 to Russ's points.

", "time": "2023-03-28T04:29:43Z"}, {"author": "Stephen Farrell", "text": "

also +1 to Russ' point on IPR - it'd be bad to see possibly encumbered stuff at this level

", "time": "2023-03-28T04:30:48Z"}, {"author": "Viktor Dukhovni", "text": "

Length-prefixed parts seem reasonable to me.

", "time": "2023-03-28T04:32:06Z"}, {"author": "Martin Thomson", "text": "

FWIW, I'm suggesting that we don't wait to see what CFRG says, unless they decide to explode the whole idea of k1||k2

", "time": "2023-03-28T04:32:27Z"}, {"author": "Martin Thomson", "text": "

length prefixing is pointless work

", "time": "2023-03-28T04:32:42Z"}, {"author": "Martin Thomson", "text": "

@Benjamin Schwartz said \"very extensible\", which - despite knowing what he meant - still engages a visceral reaction in me

", "time": "2023-03-28T04:34:00Z"}, {"author": "Erik Nygren", "text": "

@Rich Salz , on the SVCB topic there's also a defined ability to represent parameters in zone files as keyNNN=\"data\" even if the ech= parameter doesn't have a presentation to wire format parser yet.

", "time": "2023-03-28T04:34:21Z"}, {"author": "Stephen Farrell", "text": "

adopt it

", "time": "2023-03-28T04:36:37Z"}, {"author": "Rich Salz", "text": "

would you say that kind of thing is ready for wide-spread deployment?

", "time": "2023-03-28T04:36:49Z"}, {"author": "Anthony Somerset", "text": "

adopt - get dnsdir for review asap as well - although i don't see any issues there either

", "time": "2023-03-28T04:37:09Z"}, {"author": "Richard Barnes", "text": "

so the tl;dr here is just \"split the ECH stuff out of SVCB\"?

", "time": "2023-03-28T04:37:14Z"}, {"author": "Rich Salz", "text": "

@Erik, I mean \"is putting key=bytes\" qualify as ready for large-scale deployment, that the rest of ECH is requiring before moving forward?

", "time": "2023-03-28T04:38:10Z"}, {"author": "Anthony Somerset", "text": "

agree about keeping it seperate as well

", "time": "2023-03-28T04:39:32Z"}, {"author": "Mike Bishop", "text": "

Richard Barnes said:

\n
\n

so the tl;dr here is just \"split the ECH stuff out of SVCB\"?

\n
\n

Yes, exactly. It was a little odd there anyway, since ECH isn't necessarily a core aspect of connection setup. But it's a natural extension to register.

", "time": "2023-03-28T04:39:46Z"}, {"author": "Erik Nygren", "text": "

So rather than ech=\"[...]\" you'd do key5=\"[...]\". The presentation format is defined as being base64 for ech= (before being converted to binary wire format) whereas with key5= it would be escaped encoding. All of the other plumbing (eg, key synchronization, etc) is going to be much more work than just the presentation to wire format conversion. (And it's likely that bind9 already just supports ech=)

", "time": "2023-03-28T04:40:10Z"}, {"author": "Stephen Farrell", "text": "

@Rich Salz bind takes that just fine, e.g. \"HTTPS 1 draft-13.esni.defo.ie. ech=AMD+DQA88QAgACDP5BkVscfKSJcI3UtV/rZ3ZkG/OGhYmL0g2MfxBipJAwAEAAEAAQANY292ZXIuZGVmby5pZQAA/g0APMkAIAAgqrQDl0Of4LDPk92pyTp7phw0vBdNEmfekpL62rbLYmUABAABAAEADWNvdmVyLmRlZm8uaWUAAP4NADxfACAAIBnMZspPBWTQE3dsaLJofWHb8AWIOL2cEUwtwVKhvv11AAQAAQABAA1jb3Zlci5kZWZvLmllAAA=\" is from a zone file for bind

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

whatever gets the docs done, man

", "time": "2023-03-28T04:40:25Z"}, {"author": "Mike Bishop", "text": "

If we merge this with anything, it might be the draft using .well-known URLs. Different ways of discovering the ECH config.

", "time": "2023-03-28T04:40:47Z"}, {"author": "Richard Barnes", "text": "

maybe we could osmosis it, but keep it in the Approved IESG state

", "time": "2023-03-28T04:40:52Z"}, {"author": "Richard Barnes", "text": "

stretch goal for the chairs

", "time": "2023-03-28T04:40:57Z"}, {"author": "Stephen Farrell", "text": "

merging in the .well-known stuff might make sense, can be looked at later

", "time": "2023-03-28T04:41:09Z"}, {"author": "Richard Barnes", "text": "

-1 to combining with anything else. keep the already-approved stuff separate from anything new

", "time": "2023-03-28T04:41:33Z"}, {"author": "David Schinazi", "text": "

@Richard that's a fair point

", "time": "2023-03-28T04:42:02Z"}, {"author": "Rich Salz", "text": "

+1 to Richard's -1 -- the other Richard.

", "time": "2023-03-28T04:42:09Z"}, {"author": "Erik Nygren", "text": "

Merging with the .well-known might be more confusing? Since they have fairly different (albeit complementry) purposes

", "time": "2023-03-28T04:42:10Z"}, {"author": "Anthony Somerset", "text": "

i violently agree :D

", "time": "2023-03-28T04:42:13Z"}, {"author": "Eric Rescorla", "text": "

I would just make the signatures smaller

", "time": "2023-03-28T04:43:50Z"}, {"author": "Erik Nygren", "text": "

But I'd also prefer to just keep it separate given that almost all of this was in the RFC Editor queue already, so it would be better to not open .

", "time": "2023-03-28T04:43:57Z"}, {"author": "Richard Barnes", "text": "

i mean, do we really need signatures?

", "time": "2023-03-28T04:44:01Z"}, {"author": "Richard Barnes", "text": "

can't we just use the blockchain?

", "time": "2023-03-28T04:44:16Z"}, {"author": "Eric Rescorla", "text": "

@Richard Barnes good plans

", "time": "2023-03-28T04:44:36Z"}, {"author": "Richard Barnes", "text": "

i mean, CT is basically a blockchain

", "time": "2023-03-28T04:44:49Z"}, {"author": "Martin Thomson", "text": "

@Richard Barnes isn't that what the idea is?

", "time": "2023-03-28T04:44:54Z"}, {"author": "Richard Barnes", "text": "

yeah i was just realizing that

", "time": "2023-03-28T04:45:02Z"}, {"author": "Alex Chernyakhovsky", "text": "

Not all merkle trees are blockchains :)

", "time": "2023-03-28T04:45:09Z"}, {"author": "Eric Rescorla", "text": "

Can we just use Ethereum?

", "time": "2023-03-28T04:45:11Z"}, {"author": "Marten Seemann", "text": "

TLSCoin?

", "time": "2023-03-28T04:45:24Z"}, {"author": "Martin Thomson", "text": "

CACoin

", "time": "2023-03-28T04:45:35Z"}, {"author": "Rich Salz", "text": "

Yes, let's solve the micropayments problem since X509 is too hard to change

", "time": "2023-03-28T04:45:39Z"}, {"author": "Christian Huitema", "text": "

nifty-tls

", "time": "2023-03-28T04:45:46Z"}, {"author": "Richard Barnes", "text": "

@Alex - CT-like, \"grow to the right\" Merkle trees are an awful lot like blockchains

", "time": "2023-03-28T04:45:47Z"}, {"author": "Richard Barnes", "text": "

blockchains with log-depth proofs

", "time": "2023-03-28T04:45:57Z"}, {"author": "Alex Chernyakhovsky", "text": "

This draft doesn't grow to the right, AIUI, it is a fixed-width window

", "time": "2023-03-28T04:46:02Z"}, {"author": "Richard Barnes", "text": "

nice to see that MLS isn't the only WG that includes a graph theory seminar

", "time": "2023-03-28T04:46:43Z"}, {"author": "Martin Thomson", "text": "

not to be confused with a steve urkel tree

", "time": "2023-03-28T04:47:07Z"}, {"author": "Rich Salz", "text": "

LOL

", "time": "2023-03-28T04:47:14Z"}, {"author": "Richard Barnes", "text": "

DID I SIGN THAT??

", "time": "2023-03-28T04:47:24Z"}, {"author": "Martin Thomson", "text": "

no mention here of delegated credentials

", "time": "2023-03-28T04:48:48Z"}, {"author": "Martin Thomson", "text": "

though the same logic applies

", "time": "2023-03-28T04:48:54Z"}, {"author": "Mike Ounsworth", "text": "

Martin Thomson said:

\n
\n

FWIW, I'm suggesting that we don't wait to see what CFRG says, unless they decide to explode the whole idea of k1||k2

\n
\n

The question is whether you want k1||ct1||k2||ct2, and separately whether any of those things are (or need to be) fixed-length. For TLS, as I understand it, it doesn't matter, largely because ephemeral KEM means that you can't do repeated chosen-ciphertext attacks against the same server key.

", "time": "2023-03-28T04:49:40Z"}, {"author": "Martin Thomson", "text": "

@Mike Ounsworth yeah, we don't worry about that extra information presently in TLS

", "time": "2023-03-28T04:50:43Z"}, {"author": "Martin Thomson", "text": "

that is bound later via Finished and the transcript

", "time": "2023-03-28T04:51:15Z"}, {"author": "Jonathan Hoyland", "text": "

I mean there is some benefit to considering framing of some kind, if we're worried about some clever attack where k1||k2 == k3||k4 for k1 \u2260 k3 and k2 \u2260 k4.

", "time": "2023-03-28T04:51:43Z"}, {"author": "Richard Barnes", "text": "

issuance delay was a killer for doing inclusion proofs in CT. EKR and i wrote up a scheme of exactly this shape for CT, and it was rejected on the basis of \"i can't issue a cert immediately\"

", "time": "2023-03-28T04:51:57Z"}, {"author": "Eric Rescorla", "text": "

Yep.

", "time": "2023-03-28T04:52:31Z"}, {"author": "Benjamin Schwartz", "text": "

I wonder if you can avoid the issuance delay using XMSS or similar.

", "time": "2023-03-28T04:52:32Z"}, {"author": "Marten Seemann", "text": "

This really is a blockchain, with a block time of 1h

", "time": "2023-03-28T04:52:38Z"}, {"author": "Alex Chernyakhovsky", "text": "

Please do not call things a blockchain that don't do the proof-of-work/proof-of-stake thing

", "time": "2023-03-28T04:53:04Z"}, {"author": "Martin Thomson", "text": "

@Marten Seemann inclusion proof contains work, so it is a proof of work?

", "time": "2023-03-28T04:53:09Z"}, {"author": "Eric Rescorla", "text": "

I think the issuance delay is in part because of the need to include it in the transparency service.

", "time": "2023-03-28T04:53:11Z"}, {"author": "Christopher Wood", "text": "

^ +1

", "time": "2023-03-28T04:53:28Z"}, {"author": "Mike Ounsworth", "text": "

Jonathan Hoyland said:

\n
\n

I mean there is some benefit to considering framing of some kind, if we're worried about some clever attack where k1||k2 == k3||k4 for k1 \u2260 k3 and k2 \u2260 k4.

\n
\n

That most certainly matters for \"the general case\" like CMS where you can pair arbitrarily bad KEMs (cough RSA-KEM RFC 5990) in a completely non-negotiated, non-transcripted way with long-term keys. The question here is whether that applies to TLS. Seems pretty consensus-y that it does not.

", "time": "2023-03-28T04:53:30Z"}, {"author": "Martin Thomson", "text": "

Yes, if you are relying on the inclusion proof, then you need the inclusion to be proven

", "time": "2023-03-28T04:53:40Z"}, {"author": "Mike Bishop", "text": "

Do you really need the lifetime to be universal? Seems like you just need a separate sub-tree for each batch of lifetimes.

", "time": "2023-03-28T04:53:43Z"}, {"author": "Alex Chernyakhovsky", "text": "

Why do that over having lots of different CAs with the global parameters?

", "time": "2023-03-28T04:54:14Z"}, {"author": "Alex Chernyakhovsky", "text": "

Seems analogous to me?

", "time": "2023-03-28T04:54:22Z"}, {"author": "Martin Thomson", "text": "

@Mike Bishop I think that you need some expectation of when then batch is available, just as a service guarantee if nothing else

", "time": "2023-03-28T04:54:24Z"}, {"author": "Eric Rescorla", "text": "

I actually think there's a reasonable argument that Haber-Stornetta timestamping services are blockchains, as is CT.

", "time": "2023-03-28T04:54:32Z"}, {"author": "Eric Rescorla", "text": "

Also there's \"permissioned\" blockchains

", "time": "2023-03-28T04:54:47Z"}, {"author": "Richard Barnes", "text": "

TLS 1.3 key schedule, also a blockchain

", "time": "2023-03-28T04:54:51Z"}, {"author": "Richard Barnes", "text": "

It can wait

", "time": "2023-03-28T04:55:19Z"}, {"author": "Richard Barnes", "text": "

MeetEcho's awesome 15sec unmute time strikes again!

", "time": "2023-03-28T04:55:31Z"}, {"author": "Eric Rescorla", "text": "

So the efficiency here is coming from having cached the merkle tree?

", "time": "2023-03-28T04:56:18Z"}, {"author": "Eric Rescorla", "text": "

And the main signature

", "time": "2023-03-28T04:56:31Z"}, {"author": "Martin Thomson", "text": "

@Eric Rescorla I believe that the cache only holds the heads

", "time": "2023-03-28T04:56:32Z"}, {"author": "Martin Thomson", "text": "

so you have a signature on the head from each CA, the inclusion proof provides the counter-hashes in the tree

", "time": "2023-03-28T04:56:55Z"}, {"author": "Alex Chernyakhovsky", "text": "

Each \"cert\" is an inclusion proof to some heads, and you need to deliver the signed heads for each batch

", "time": "2023-03-28T04:56:57Z"}, {"author": "Richard Barnes", "text": "

\"what if CT was the PKI??\"

", "time": "2023-03-28T04:57:23Z"}, {"author": "Marten Seemann", "text": "

Does that mean that I have to contact the CA (or a mirror) to get the block that contains the certificate?

", "time": "2023-03-28T04:57:53Z"}, {"author": "Nicholas Gajcowski", "text": "

Inclusion proof is necessary hashes to travese up tree root?

", "time": "2023-03-28T04:58:17Z"}, {"author": "Richard Barnes", "text": "

@Nicholas - yes, the hashes on the \"copath\"

", "time": "2023-03-28T04:58:37Z"}, {"author": "Alex Chernyakhovsky", "text": "

You don't care which block has the cert. You just care a proof that the CA actually included it in the signature

", "time": "2023-03-28T04:58:38Z"}, {"author": "Benjamin Schwartz", "text": "

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

", "time": "2023-03-28T04:59:01Z"}, {"author": "Dennis Jackson", "text": "

But this isn't a merkle tree. Each batch of certificates is independent.

", "time": "2023-03-28T04:59:43Z"}, {"author": "Alex Chernyakhovsky", "text": "

Each batch is a merkle tree

", "time": "2023-03-28T04:59:54Z"}, {"author": "Dennis Jackson", "text": "

Yes, but no linkage between the windows.

", "time": "2023-03-28T05:00:18Z"}, {"author": "Marten Seemann", "text": "

Then I don't understand where the batching gives you any advantage

", "time": "2023-03-28T05:00:39Z"}, {"author": "Dennis Jackson", "text": "

So in short you still need a transparency service for the transparency service :-P

", "time": "2023-03-28T05:00:50Z"}, {"author": "Martin Thomson", "text": "

@Marten Seemann batching reduces the load on the distribution system

", "time": "2023-03-28T05:01:05Z"}, {"author": "Rich Salz", "text": "

@Dennis, by your definition wouldn't all \"merkle trees\" be immutable?

", "time": "2023-03-28T05:01:12Z"}, {"author": "Rich Salz", "text": "

What

", "time": "2023-03-28T05:01:16Z"}, {"author": "Dennis Jackson", "text": "

This draft moves the concern from \"I'm worried about what CAs are signing\" to \"I'm worried about what the transparency service is signing\"

", "time": "2023-03-28T05:01:29Z"}, {"author": "Martin Thomson", "text": "

keep in mind that you need to effectively broadcast the tree heads to all web users

", "time": "2023-03-28T05:01:30Z"}, {"author": "Rich Salz", "text": "

What's the difference between a head and a certificate? In this case seems just changing the terminology.

", "time": "2023-03-28T05:01:37Z"}, {"author": "Alex Chernyakhovsky", "text": "

The transparency service isn't signing anything

", "time": "2023-03-28T05:01:41Z"}, {"author": "Alex Chernyakhovsky", "text": "

It's just conveying signatures produces by the CAs to the RPs

", "time": "2023-03-28T05:01:51Z"}, {"author": "Dennis Jackson", "text": "

The transparency service is the witness that those heads are correct and not split view.

", "time": "2023-03-28T05:02:11Z"}, {"author": "Mike Ounsworth", "text": "

Rich Salz said:

\n
\n

What's the difference between a head and a certificate? In this case seems just changing the terminology.

\n
\n

maybe if you swap \"certificate\" for \"trust anchor\" ?

", "time": "2023-03-28T05:02:11Z"}, {"author": "Martin Thomson", "text": "

@Alex Chernyakhovsky you might imagine a counter-signature from transparency services, along the lines of SCTs

", "time": "2023-03-28T05:02:13Z"}, {"author": "Alex Chernyakhovsky", "text": "

And really the combination of transparency services / monitors decide what the root store is, effectievly

", "time": "2023-03-28T05:02:14Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Martin Thomson sure, but I don't think that's required for this scheme to work?

", "time": "2023-03-28T05:02:29Z"}, {"author": "Dennis Jackson", "text": "

If the transparency service can equivocate, you're back in \"PKI without CT\" land.

", "time": "2023-03-28T05:02:29Z"}, {"author": "Richard Barnes", "text": "

@mt yo dawg, i heard you like transparency

", "time": "2023-03-28T05:02:37Z"}, {"author": "Amir Omidi", "text": "

@Dennis Jackson, its pretty simple to verify that the transparency services are following the CAs properly though

", "time": "2023-03-28T05:03:46Z"}, {"author": "Martin Thomson", "text": "

can DC + wildcards address the velocity issues

", "time": "2023-03-28T05:04:42Z"}, {"author": "Amir Omidi", "text": "

Backup certificates from other CAs can also address it

", "time": "2023-03-28T05:05:13Z"}, {"author": "Dennis Jackson", "text": "

Amir: I'm not so sure in practice. Right now the transparency services are (in theory) independent of Google. In this draft, Google is the transparency service.

", "time": "2023-03-28T05:06:21Z"}, {"author": "Devon O'Brien", "text": "

@Dennis Jackson The Transparency Service, as likely implemented, will be explicitly trusted by the RP. An example later in the slides is a software update channel where the TS is operated by the RP/browser vendor.

", "time": "2023-03-28T05:06:44Z"}, {"author": "Benjamin Schwartz", "text": "

I can imagine an emergency option for fast issuance even within the Merkle tree framework, at the cost of larger handshakes for fast-issued certs.

", "time": "2023-03-28T05:06:49Z"}, {"author": "Dennis Jackson", "text": "

If that's the model Devon, that's weaker than what we have now with CT.

", "time": "2023-03-28T05:07:13Z"}, {"author": "Devon O'Brien", "text": "

@Benjamin Schwartz You almost certainly lose the issuance transparency element if you do that

", "time": "2023-03-28T05:07:15Z"}, {"author": "Benjamin Schwartz", "text": "

@Devon O'Brien You would need an XMSS-type SCT from the transparency log.

", "time": "2023-03-28T05:08:10Z"}, {"author": "Amir Omidi", "text": "

There can be more than one transparency monitoring service at the same time. Misbehaving transparency servers can be dropped like how CT can be dropped for example.

", "time": "2023-03-28T05:08:18Z"}, {"author": "Martin Thomson", "text": "

BoF!'

", "time": "2023-03-28T05:08:46Z"}, {"author": "Martin Thomson", "text": "

Which is to say, nice work for socializing this here, but I'd like to see a BoF

", "time": "2023-03-28T05:09:11Z"}, {"author": "Daniel Gillmor", "text": "

@Paul Wouters :+1:

", "time": "2023-03-28T05:09:33Z"}, {"author": "Richard Barnes", "text": "

because DNSSEC is gonna have a great time with giant PQ sigs

", "time": "2023-03-28T05:09:50Z"}, {"author": "David Schinazi", "text": "

Just put the DNS zone in a CT log

", "time": "2023-03-28T05:10:17Z"}, {"author": "Daniel Gillmor", "text": "

DNSSEC transparency is long overdue

", "time": "2023-03-28T05:10:30Z"}, {"author": "Benjamin Schwartz", "text": "

@Richard Barnes Fun fact: DNS messages and records are limited to 64Kbytes. There is no extended-length mechanism.

", "time": "2023-03-28T05:10:36Z"}, {"author": "Eric Rescorla", "text": "

Any system which depends on retrieving new big values from DNS is going to have a bad day

", "time": "2023-03-28T05:10:36Z"}, {"author": "Richard Barnes", "text": "

https://www.internetfire.org/projects/dns-transparency

", "time": "2023-03-28T05:10:38Z"}, {"author": "Stephen Farrell", "text": "

Not sure if even a BoF would be sufficient (necessary yes, but maybe not sufficient), could be a workshoppy type thing needed

", "time": "2023-03-28T05:10:56Z"}, {"author": "Eric Rescorla", "text": "

@Benjamin Schwartz conveniently anything more than like 1000 bytes doesn't really work that reliably :)

", "time": "2023-03-28T05:11:11Z"}, {"author": "Daniel Gillmor", "text": "

Eric Rescorla said:

\n
\n

Any system which depends on retrieving new big values from DNS is going to have a bad day

\n
\n

unless you use encrypted transport

", "time": "2023-03-28T05:11:15Z"}, {"author": "Rich Salz", "text": "

post-quantum, tls, dns, merkle trees. turtles all the way down

", "time": "2023-03-28T05:11:44Z"}, {"author": "Devon O'Brien", "text": "

@Dennis Jackson Google functionally was the transparency service for many years, while it required Google SCTs. A reason 1st party TS might be more palatable is because they completely reflect all CA issuances, and do so before they even reach RPs. The TS both defines what RPs trust as well as publishing the set of valid certificates.

", "time": "2023-03-28T05:11:48Z"}, {"author": "Eric Rescorla", "text": "

@Daniel Gillmor yes, to a reliable server

", "time": "2023-03-28T05:11:52Z"}, {"author": "Amir Omidi", "text": "

The IPV4 evil bit solves the need to do any of this /s

", "time": "2023-03-28T05:12:00Z"}, {"author": "Jonathan Hoyland", "text": "

@Amir Omidi As we saw last week[1] some CAs don't bother checking the validity SCT staples, and got away with that bad behaviour for a very long time.
\nThe transparency servers can just not check anything, and rely on the CAs to not misbehave.

\n

[1] https://sslmate.com/blog/post/march_2023_ct_blunders

", "time": "2023-03-28T05:12:43Z"}, {"author": "Amir Omidi", "text": "

Oh I know - I'm on Google Trust Services and we had this blunder: https://bugzilla.mozilla.org/show_bug.cgi?id=1815874

", "time": "2023-03-28T05:13:32Z"}, {"author": "Richard Barnes", "text": "

this is great and all, but kind of funny in light of the numbers davidben was just talking about

", "time": "2023-03-28T05:13:53Z"}, {"author": "Daniel Gillmor", "text": "

i was just writing that

", "time": "2023-03-28T05:14:04Z"}, {"author": "Daniel Gillmor", "text": "

7 bytes per key vs. multiple thousands

", "time": "2023-03-28T05:14:20Z"}, {"author": "Richard Barnes", "text": "

i was just writing that

", "time": "2023-03-28T05:14:26Z"}, {"author": "Yoav Nir", "text": "

Nice. In this session we had a talk about big keys that require hundreds of bytes to encode, and about much smaller keys that are already compact, and making them more compact.

", "time": "2023-03-28T05:14:48Z"}, {"author": "Jonathan Hoyland", "text": "

@Amir Omidi Ouch, that looks painful.

", "time": "2023-03-28T05:14:53Z"}, {"author": "Viktor Dukhovni", "text": "

DNS already use compact encodings along these lines avoiding ASN.1

", "time": "2023-03-28T05:16:07Z"}, {"author": "Yoav Nir", "text": "

Great minds and all that...

", "time": "2023-03-28T05:16:30Z"}, {"author": "Dennis Jackson", "text": "

@Devon O'Brien - My point is that right now is that the trust model for undiscoverable MiTM is $BROWSER_VENDOR not to ship bad code and no more than 2 bad CT logs and one bad CA.

", "time": "2023-03-28T05:16:37Z"}, {"author": "Dennis Jackson", "text": "

As currently written, the draft moves this to $BROWSER_VENDOR not to ship bad code, $BROWSER_VENDOR not to lie about a tree head update and one bad CA.

", "time": "2023-03-28T05:17:20Z"}, {"author": "Nicholas Gajcowski", "text": "

With compact, you don\u2019t have to worry about getting a bad y. But will need to address getting a bad x where there isn\u2019t a y.

", "time": "2023-03-28T05:17:26Z"}, {"author": "Devon O'Brien", "text": "

@Dennis Jackson I see your point now. I'm not sure a compromised $browser_vendor would need CT Logs to get away with undiscoverable MITM under that threat model today.

", "time": "2023-03-28T05:20:08Z"}, {"author": "David Benjamin", "text": "

@Dennis Jackson You can also use one of the models with multiple mirrors. Though I suppose, to avoid the RP contacting mirrors directly, we'd need the mirrors to counter-sign things, which seems easy enough. Want to file something on the GitHub? :-) (Though I also agree with Devon here.)

", "time": "2023-03-28T05:20:45Z"}, {"author": "Richard Barnes", "text": "

If you don't trust your browser vendor, you're pretty well out of luck

", "time": "2023-03-28T05:20:47Z"}, {"author": "Martin Thomson", "text": "

correction: HTTP/2 doesn't forbid it

", "time": "2023-03-28T05:20:59Z"}, {"author": "Benjamin Schwartz", "text": "

My biggest concern about compact representations is about compatibility. If the world tried to move to the compact curves, there would be an awkward period where we have a lot of HelloRetryRequest, which is enough of a barrier that I think the majority of clients would be unlikely to switch.

", "time": "2023-03-28T05:21:04Z"}, {"author": "Dennis Jackson", "text": "

@David Benjamin - I have a half written mail, but too many fires not enough time. I'm hoping to get it to soon. :-)

", "time": "2023-03-28T05:21:22Z"}, {"author": "Viktor Dukhovni", "text": "

psk_ke is already unusable. :-(

", "time": "2023-03-28T05:21:35Z"}, {"author": "David Benjamin", "text": "

@Dennis Jackson Conveniently, the actual format of the signed windows being tossed around is mostly a great big TODO in the document right now anyway. :-)

", "time": "2023-03-28T05:22:09Z"}, {"author": "Benjamin Schwartz", "text": "

(But in cTLS, the parties can pin the key exchange method ahead of time so it might work there.)

", "time": "2023-03-28T05:22:53Z"}, {"author": "Andrew Campling", "text": "

A trust model that relies on a s/w vendor not to do something, in particular not to ship bad code, seems a little flimsy

", "time": "2023-03-28T05:23:31Z"}, {"author": "Stephen Farrell", "text": "

deprecate the future!

", "time": "2023-03-28T05:23:56Z"}, {"author": "Benjamin Schwartz", "text": "

@Andrew Campling Surely all trust models meet that description.

", "time": "2023-03-28T05:24:04Z"}, {"author": "Benjamin Schwartz", "text": "

Unless you have an implementation of HTML and CSS in silicon!

", "time": "2023-03-28T05:25:20Z"}, {"author": "Martin Thomson", "text": "

John just summoned Peter Gutmann

", "time": "2023-03-28T05:27:42Z"}, {"author": "Deb Cooley", "text": "

RFC9151 says RSA 3K or 4K. (not 2K)

", "time": "2023-03-28T05:28:44Z"}, {"author": "Christian Huitema", "text": "

Is Peter Gutmann in the room?

", "time": "2023-03-28T05:28:55Z"}, {"author": "Eric Rescorla", "text": "

I am in favor of adopting this draft.

", "time": "2023-03-28T05:29:20Z"}, {"author": "Stephen Farrell", "text": "

yeah

", "time": "2023-03-28T05:29:30Z"}, {"author": "Martin Thomson", "text": "

I am in favour also

", "time": "2023-03-28T05:29:31Z"}, {"author": "Eric Rescorla", "text": "

Deb Cooley said:

\n
\n

RFC9151 says RSA 3K or 4K. (not 2K)

\n
\n

What about MST3K?

", "time": "2023-03-28T05:29:43Z"}, {"author": "Deb Cooley", "text": "

eh?

", "time": "2023-03-28T05:30:16Z"}, {"author": "Deb Cooley", "text": "

(it is early where I am)

", "time": "2023-03-28T05:30:25Z"}, {"author": "Martin Thomson", "text": "

mystery science theater 3000

", "time": "2023-03-28T05:30:31Z"}, {"author": "Deb Cooley", "text": "

SMH

", "time": "2023-03-28T05:30:37Z"}, {"author": "Rich Salz", "text": "

I really wish John Gilmore's idea -- use weird RSA sizes that aren't multiples of 1024, to make it more difficult for hardware -- had more uptake.

", "time": "2023-03-28T05:30:37Z"}, {"author": "Richard Barnes", "text": "

https://en.wikipedia.org/wiki/Mystery_Science_Theater_3000

", "time": "2023-03-28T05:30:39Z"}, {"author": "Deb Cooley", "text": "

yeah, yeah, but it is literally 0130 here.

", "time": "2023-03-28T05:30:57Z"}, {"author": "Nicholas Gajcowski", "text": "

I don\u2019t know what mst3k is either. Lol

", "time": "2023-03-28T05:30:59Z"}, {"author": "Deb Cooley", "text": "

now we do.

", "time": "2023-03-28T05:31:07Z"}, {"author": "Eric Rescorla", "text": "

The new port is bad news

", "time": "2023-03-28T05:31:10Z"}, {"author": "Viktor Dukhovni", "text": "

I see a cluster of 1300 bit RSA keys in DNSSEC.

", "time": "2023-03-28T05:31:23Z"}, {"author": "Deb Cooley", "text": "

yuck

", "time": "2023-03-28T05:31:34Z"}, {"author": "Martin Thomson", "text": "

The new port is a bad idea, but we can't stop someone from defining a new protocol

", "time": "2023-03-28T05:31:35Z"}, {"author": "Mike Ounsworth", "text": "

I've seen RSA-2084 and RSA-4069

", "time": "2023-03-28T05:31:43Z"}, {"author": "Viktor Dukhovni", "text": "

O(100) out of 21.6 million, so not common, but still unexpected.

", "time": "2023-03-28T05:31:50Z"}, {"author": "Martin Thomson", "text": "

because this would be a new protocol

", "time": "2023-03-28T05:31:52Z"}, {"author": "Rich Salz", "text": "

I didn't say no uptake, I said more uptake :)

", "time": "2023-03-28T05:31:59Z"}, {"author": "Yoav Nir", "text": "

If we adopt this draft, it will finally dislodge tls-flags, so there's that.

", "time": "2023-03-28T05:32:02Z"}, {"author": "Rich Salz", "text": "

Is \"draft-sbn\" the first use of author initials as the name?

", "time": "2023-03-28T05:33:02Z"}, {"author": "Martin Thomson", "text": "

it's one AES operation per record

", "time": "2023-03-28T05:34:26Z"}, {"author": "Martin Thomson", "text": "

the scrubbing back and forth and dealing with alignment issues is perhaps a little expensive

", "time": "2023-03-28T05:35:10Z"}, {"author": "Eric Rescorla", "text": "

I think I was actually wrong about the two sides disagreeing

", "time": "2023-03-28T05:35:18Z"}, {"author": "Martin Thomson", "text": "

with port numbers, you can totally disagree

", "time": "2023-03-28T05:35:34Z"}, {"author": "Martin Thomson", "text": "

those aren't authenticated

", "time": "2023-03-28T05:35:40Z"}, {"author": "Eric Rescorla", "text": "

Yes, but I think it will cause a handshake failure

", "time": "2023-03-28T05:35:43Z"}, {"author": "Martin Thomson", "text": "

it probably would, yes

", "time": "2023-03-28T05:35:51Z"}, {"author": "Eric Rescorla", "text": "

The attacker will be able to remove the encrypted SN (mostly) but not re-inject

", "time": "2023-03-28T05:36:08Z"}, {"author": "Christian Huitema", "text": "

Just try harder and design your hardware to do the right thing!

", "time": "2023-03-28T05:36:11Z"}, {"author": "Martin Thomson", "text": "

you might need to know the keys in order to rewrite the packet as well as flipping the port

", "time": "2023-03-28T05:36:20Z"}, {"author": "Eric Rescorla", "text": "

Well, unless you use short sequence numbers in which case you can just produce like all 256 values

", "time": "2023-03-28T05:36:25Z"}, {"author": "Eric Rescorla", "text": "

And figure one will decrypt

", "time": "2023-03-28T05:36:28Z"}, {"author": "Eric Rescorla", "text": "

(256 encrypted values)

", "time": "2023-03-28T05:36:39Z"}, {"author": "Martin Thomson", "text": "

Tru, 256 values isn't many

", "time": "2023-03-28T05:36:41Z"}, {"author": "Christian Huitema", "text": "

We had that exact same discussion with another vendor for QUIC a couple years ago, and eventually they just fixed the hardware...

", "time": "2023-03-28T05:36:55Z"}, {"author": "Stephen Farrell", "text": "

+1 to fix the h/w

", "time": "2023-03-28T05:37:06Z"}, {"author": "Alex Chernyakhovsky", "text": "

What is the hardware in question here? Mellanox CX6?

", "time": "2023-03-28T05:38:14Z"}, {"author": "Christian Huitema", "text": "

I am completely unconvinced. Seems like there is some unstated silly reason behind that!

", "time": "2023-03-28T05:38:30Z"}, {"author": "Christian Huitema", "text": "

The Microsoft experiments 2 years ago did mention 5% if I remember

", "time": "2023-03-28T05:39:12Z"}, {"author": "Martin Thomson", "text": "

5% is not a convincing number, at least for me

", "time": "2023-03-28T05:39:27Z"}, {"author": "Stephen Farrell", "text": "

can we future-deprecate that now as well?

", "time": "2023-03-28T05:39:32Z"}, {"author": "Benjamin Schwartz", "text": "

5% was my total guess, just header size / MTU.

", "time": "2023-03-28T05:39:58Z"}, {"author": "Martin Thomson", "text": "

if John was attempting to summon Peter Gutmann, this discussion is like drawing a pentagram in blood and drippy candles

", "time": "2023-03-28T05:40:47Z"}, {"author": "Eric Rescorla", "text": "

@Sean Turner why are you thinking so small? Deprecate TLS 1.3

", "time": "2023-03-28T05:40:50Z"}, {"author": "Anthony Somerset", "text": "

doesn't deprecation just mean, there will be no more work done on this and at some point in the future it might go away

", "time": "2023-03-28T05:42:43Z"}, {"author": "Anthony Somerset", "text": "

rather than it goes away now

", "time": "2023-03-28T05:42:53Z"}, {"author": "Yoav Nir", "text": "

Whoa, there's \"deprecate\" and then there's \"deprecate\".

\n

Saying that the IETF won't make new extensions to 1.2 is one thing.

\n

Telling SecDir to require \"at least TLS 1.3\" in the Security Considerations of new documents is another.

\n

Telling the world to stop using TLS 1.2 is a whole different thing.

", "time": "2023-03-28T05:43:27Z"}, {"author": "Mike Ounsworth", "text": "

Why are we moving to deprecate 1.2? Is it \"bad\" in some \"your data is at risk / CVSS 10.0\" sort of way?

", "time": "2023-03-28T05:43:38Z"}, {"author": "Benjamin Schwartz", "text": "

\"deprecate: to disparage or belittle\" -> \"You should feel ashamed for using TLS 1.2\".

", "time": "2023-03-28T05:44:52Z"}, {"author": "Stephen Farrell", "text": "

tls1.1? figures for that were always tiny weren't they?

", "time": "2023-03-28T05:45:04Z"}, {"author": "Yoav Nir", "text": "

You can have good TLS 1.2 connections. But TLS 1.2 has some things like TLS_RSA_WITH_DES_CBC_SHA.

", "time": "2023-03-28T05:45:36Z"}, {"author": "Yoav Nir", "text": "

@Stephen Farrell: Yes, most implementations got 1.1 and 1.2 at the same time, so the handshake always ended with either 1.0 or 1.2

", "time": "2023-03-28T05:46:29Z"}, {"author": "Anthony Somerset", "text": "

I think

\n

WG recharter - to no longer accept anything TLS1.2 related other than to disable/discourage specific things

\n

Recommend (not require) SecDir considers requiring TLS1.3 as a minimum for new docs

", "time": "2023-03-28T05:46:58Z"}, {"author": "Stephen Farrell", "text": "

+1 for re-charter to not do new work on 1.2

", "time": "2023-03-28T05:47:50Z"}, {"author": "Mike Ounsworth", "text": "
    \n
  1. for charter text or wtv, it should be \"deprecate, except for security-critical fixes\"
    2. \n
  2. as an appsec guy, I second being very very clear about \"deprecate\" vs \"vulnerable\". Otherwise my professional life will BLOW UP with takedown requests.
    3. \n
", "time": "2023-03-28T05:48:06Z"}, {"author": "Stephen Farrell", "text": "

Maybe also make a statement about deprecating tl1.2 except as per UTA spec?

", "time": "2023-03-28T05:48:17Z"}, {"author": "Viktor Dukhovni", "text": "

No objections to treating 1.2 as a stable protocol barring a compelling unforseen future incentive. However definitely premature to say its use is actively discouraged.

", "time": "2023-03-28T05:48:25Z"}, {"author": "Yoav Nir", "text": "

I don't think we need to put this in the charter. Any document adoption requires a discussion. Hopefully the people in the WG have enough sense not to adopt it.

", "time": "2023-03-28T05:48:59Z"}, {"author": "John Gray", "text": "

Umm, we still have customers that wonder why their software stopped working because they are still using TLS 1.1 or 1.0 (to our horror). I think planning a long term roadmap for deprecation of 1.2 is a good idea, but realistically it won't be able to happen suddenly (without breaking the internet) for many years...

", "time": "2023-03-28T05:50:07Z"}, {"author": "Alex Chernyakhovsky", "text": "

So we're using deprecate to mean \"done, no new work\"? Do we need a new word? \"doneprecate\"?

", "time": "2023-03-28T05:51:17Z"}, {"author": "Eric Rescorla", "text": "

I think MT's \"if you are designing a new protocol that uses TLS then it should be >= 1.3\" is a good line

", "time": "2023-03-28T05:51:33Z"}, {"author": "Eric Rescorla", "text": "

Because it's now the case that almost every environment can get 1.3

", "time": "2023-03-28T05:51:57Z"}, {"author": "Anthony Somerset", "text": "

publish a doc as a BCP perhaps?

", "time": "2023-03-28T05:53:03Z"}, {"author": "Anthony Somerset", "text": "

that encompasses the comments made here

", "time": "2023-03-28T05:53:20Z"}, {"author": "Anthony Somerset", "text": "

i agree

", "time": "2023-03-28T05:54:59Z"}, {"author": "Eric Rescorla", "text": "

The faster we publish TLS 1.4, we could more easily deprecate 1.2

", "time": "2023-03-28T05:55:49Z"}, {"author": "Christopher Wood", "text": "

Regarding raising the ceiling, earlier we discussed moving hybrid-kex forward, which only applies to TLS 1.3. Dangling PQC as a carrot to raise the ceiling seems like a good angle.

", "time": "2023-03-28T05:56:32Z"}, {"author": "Benjamin Schwartz", "text": "

No PQC for TLS 1.2 seems like a plausible rule.

", "time": "2023-03-28T05:57:20Z"}, {"author": "Richard Barnes", "text": "

+1 to reserving PQC for 1.3

", "time": "2023-03-28T05:57:39Z"}]