[{"author": "Mike Ounsworth", "text": "

I can help with notes, but I might not know the technical details well enough to capture the debates / decisions properly.

", "time": "2022-11-10T09:31:11Z"}, {"author": "Sean Turner", "text": "

Notes here: https://notes.ietf.org/notes-ietf-115-tls#

", "time": "2022-11-10T09:32:06Z"}, {"author": "David Schinazi", "text": "

Feedback for the chairs: the text color in some of these slides is quite close to the background :-)

", "time": "2022-11-10T09:32:59Z"}, {"author": "Sean Turner", "text": "

@David: ack

", "time": "2022-11-10T09:35:44Z"}, {"author": "Andrew Campling", "text": "

Anyone that missed the ECH deployment considerations side meeting on Monday evening can catch the recording of the session at https://419.consulting/encrypted-dns/f/ech-on-the-side. (Sorry about the quality of the sound but I think you should be able to pick up the key points).

", "time": "2022-11-10T09:37:10Z"}, {"author": "Sean Turner", "text": "

@Andrew Campling thanks for that link!

", "time": "2022-11-10T09:37:32Z"}, {"author": "Rich Salz", "text": "

Totally bummed that I'm going to have to leave for noncom and can't make the session. My favorite WG but duty calls

", "time": "2022-11-10T09:39:14Z"}, {"author": "Benjamin Schwartz", "text": "

\"Further instructions to IANA regarding...\"

", "time": "2022-11-10T09:45:50Z"}, {"author": "David Schinazi", "text": "

\"An update on the registry\" though that sounds like we're closing it

", "time": "2022-11-10T09:46:12Z"}, {"author": "Richard Barnes", "text": "

i was just going to note that you could include the diff as an appendix in a full replacement doc

", "time": "2022-11-10T09:46:39Z"}, {"author": "Sean Turner", "text": "

@Benjamin Schwartz good idea ;)

", "time": "2022-11-10T09:47:42Z"}, {"author": "David Schinazi", "text": "

But then you get the opportunity to have the diff disagree with the text and arguing about which one takes precedence

", "time": "2022-11-10T09:47:43Z"}, {"author": "Richard Barnes", "text": "

\"Discouraged\" sounds like it needs reassurance :teddy_bear:

", "time": "2022-11-10T09:48:06Z"}, {"author": "Carrick Bartle", "text": "

haha

", "time": "2022-11-10T09:48:19Z"}, {"author": "Benjamin Schwartz", "text": "

\"Recommended = D\" seems a bit ... obscure

", "time": "2022-11-10T09:48:20Z"}, {"author": "Richard Barnes", "text": "

like awwww, poor SHA-1!

", "time": "2022-11-10T09:48:26Z"}, {"author": "Yoav Nir", "text": "

Rich decides!

", "time": "2022-11-10T09:48:30Z"}, {"author": "Carrick Bartle", "text": "

@benjamin +1

", "time": "2022-11-10T09:48:34Z"}, {"author": "Deb Cooley", "text": "

deprecated?

", "time": "2022-11-10T09:48:57Z"}, {"author": "Deb Cooley", "text": "

(which is different)

", "time": "2022-11-10T09:49:17Z"}, {"author": "Richard Barnes", "text": "

(to be clear, i was not saying we need a new word other than \"discouraged\")

", "time": "2022-11-10T09:49:18Z"}, {"author": "Sean Turner", "text": "

it's values for the recommended column with potential values: Y/N/D

", "time": "2022-11-10T09:49:22Z"}, {"author": "Benjamin Schwartz", "text": "

Y/N/-Y

", "time": "2022-11-10T09:49:34Z"}, {"author": "Sean Turner", "text": "

deprecated refers to document status ... subtle but different

", "time": "2022-11-10T09:50:37Z"}, {"author": "Deb Cooley", "text": "

definitely different

", "time": "2022-11-10T09:50:59Z"}, {"author": "Richard Barnes", "text": "

!remind me when this text is updated so i can update the copy/paste in MLS

", "time": "2022-11-10T09:51:23Z"}, {"author": "Martin Thomson", "text": "

Also, why are we preserving private use?

", "time": "2022-11-10T09:52:05Z"}, {"author": "Jabber", "text": "

sftcd: given how hard it is to agree on one letter, adding more could only make it harder:-)

", "time": "2022-11-10T09:52:21Z"}, {"author": "Sean Turner", "text": "

re: the values - we did do a consensus call at saag for this ;)

", "time": "2022-11-10T09:52:29Z"}, {"author": "Martin Thomson", "text": "

Encouraging people to provide a specification is a good thing (the good government theory). But I'm OK with \"niener-niener\".

", "time": "2022-11-10T09:55:27Z"}, {"author": "Deb Cooley", "text": "

'ekr stinks'

", "time": "2022-11-10T09:56:06Z"}, {"author": "Richard Barnes", "text": "

i plan to register \"fnord\"

", "time": "2022-11-10T09:56:17Z"}, {"author": "Benjamin Schwartz", "text": "

In general, I believe even FCFS policies are subject to abuse prevention heuristics

", "time": "2022-11-10T09:56:26Z"}, {"author": "Martin Thomson", "text": "

@Deb Cooley \"EXPORTER-ekr stinks\"

", "time": "2022-11-10T09:56:35Z"}, {"author": "Benjamin Schwartz", "text": "

I don't know if \"EXPORTER-tls-14\" is considered abusive by IANA...

", "time": "2022-11-10T09:57:39Z"}, {"author": "Yoav Nir", "text": "

Up until now, we've considered a published I-D as a \"specification\"

", "time": "2022-11-10T09:58:55Z"}, {"author": "Benjamin Schwartz", "text": "

@David Schinazi Is a Private Use range sufficient?

", "time": "2022-11-10T09:59:15Z"}, {"author": "Rich Salz", "text": "

World people be bothered by exporter-maga for example?

", "time": "2022-11-10T10:00:23Z"}, {"author": "Martin Thomson", "text": "

\"EXPORTER-tls-14\" should be fine

", "time": "2022-11-10T10:00:24Z"}, {"author": "Martin Thomson", "text": "

Also, this \"EXPORTER-\" prefix should be unnecessary in any version of TLS from 1.3 onwards.

", "time": "2022-11-10T10:00:48Z"}, {"author": "Yoav Nir", "text": "

But with I-Ds the specification is a particular version of the I-D. The author cannot later revise the draft and change the meaning of the code point.

", "time": "2022-11-10T10:00:58Z"}, {"author": "Martin Thomson", "text": "

How many people noted the difference between {{}} and [] in the text?

", "time": "2022-11-10T10:01:13Z"}, {"author": "Richard Barnes", "text": "

Always Be Deprecating

", "time": "2022-11-10T10:02:37Z"}, {"author": "Sean Turner", "text": "

Martin Thomson said:

\n
\n

How many people noted the difference between {{}} and [] in the text?

\n
\n

markdown fail ;)

", "time": "2022-11-10T10:03:55Z"}, {"author": "Daniel Gillmor", "text": "

\"email clients\" ? or \"SMTP clients\" ?

", "time": "2022-11-10T10:04:39Z"}, {"author": "Daniel Gillmor", "text": "

MUAs definitely should abort if they can't verify group structure

", "time": "2022-11-10T10:05:01Z"}, {"author": "Yoav Nir", "text": "

So who's opposing deprecating them?

", "time": "2022-11-10T10:05:04Z"}, {"author": "Benjamin Schwartz", "text": "

@Daniel Gillmor Presumably the latter, but I think the main point was \"opportunistic TLS\".

", "time": "2022-11-10T10:05:36Z"}, {"author": "Eric Rescorla", "text": "

EXPORTER-ekr-really-really-stinks-neiner-neiner

", "time": "2022-11-10T10:07:07Z"}, {"author": "Richard Barnes", "text": "

bring back DES for opportunistic TLS!

", "time": "2022-11-10T10:07:17Z"}, {"author": "Eric Rescorla", "text": "

RC4-40

", "time": "2022-11-10T10:07:23Z"}, {"author": "Yoav Nir", "text": "

This is surprising to me. Not too long ago pretty much all of the TLS handshakes were RSA key exchange. By the time people were looking for FS, they moved to ECDHE, not FFDHE. So I don't know where this FFDHE community sprang up from.

", "time": "2022-11-10T10:10:39Z"}, {"author": "David Schinazi", "text": "

As promised: https://github.com/tlswg/rfc8447bis/pull/33

", "time": "2022-11-10T10:11:12Z"}, {"author": "Daniel Gillmor", "text": "

Yoav, this is old SMTP servers

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

Opportunistic TLS Considered Harmful: Just Get Your Act Together

", "time": "2022-11-10T10:11:21Z"}, {"author": "Jabber", "text": "

sftcd: I think it was done in some MTA code bases/install HOWTOs - they encouraged generating your own FFDHE

", "time": "2022-11-10T10:11:49Z"}, {"author": "Yoav Nir", "text": "

Old SMTP servers use RSA key exchange, and if I owned one that was running old versions of software I would be too afraid to reconfigure it to some ciphersuite it hasn't used before. If it's using a TLS library from the last 15 years, it supports ECDHE.

", "time": "2022-11-10T10:12:58Z"}, {"author": "Paul Wouters", "text": "

if only we had TLS profiles :)

", "time": "2022-11-10T10:13:29Z"}, {"author": "Yoav Nir", "text": "

I think what we should do is deprecate FFDHE entirely. If someone has to ignore us because they are running ancient software, then they ignore us.

", "time": "2022-11-10T10:14:23Z"}, {"author": "Jabber", "text": "

sftcd: @yoav: IIUC the MTA code might well support ECDHE but has a configured FFDHE custom group that they also don't wanna change (but I may be wrong)

", "time": "2022-11-10T10:14:24Z"}, {"author": "Jonathan Hoyland", "text": "

According to the bird site not many people run their own email servers any more.

", "time": "2022-11-10T10:14:41Z"}, {"author": "Paul Wouters", "text": "

yoav: I agree. deprecate != disable

", "time": "2022-11-10T10:14:54Z"}, {"author": "Jabber", "text": "

sftcd: we have done \"the email folks can catch up later\" before all right

", "time": "2022-11-10T10:15:06Z"}, {"author": "Benjamin Schwartz", "text": "

@Daniel Gillmor Why not apply the same logic to RSA?

", "time": "2022-11-10T10:15:22Z"}, {"author": "Jabber", "text": "

sftcd: @jonathon: I'd be sad if we provide yet more reasons to make that worse

", "time": "2022-11-10T10:15:32Z"}, {"author": "Eric Rescorla", "text": "

I honestly, cannot remember whether what we do with FFDHE right now.

", "time": "2022-11-10T10:15:40Z"}, {"author": "Florence D", "text": "

@Daniel Gillmor could you add your suggestion to the notes please? I don't think I've captured it well

", "time": "2022-11-10T10:16:16Z"}, {"author": "David Benjamin", "text": "

(Agreed with EKR and MT; Chrome also would not apply different TLS policies between https URLs and http->https upgrades. It'd cause a lot of problems with the security model.)

", "time": "2022-11-10T10:16:29Z"}, {"author": "Daniel Gillmor", "text": "

Florence: i'll try.

", "time": "2022-11-10T10:16:55Z"}, {"author": "Paul Wouters", "text": "

at $dayjob, our meassurement for TLS ciphersuites was we had 16 out of 2B connections not doing modern AEAD / ECDHE

", "time": "2022-11-10T10:17:14Z"}, {"author": "Sean Turner", "text": "

@Florence D thanks for asking DKG to do that. The audio is horrible up here at the front.

", "time": "2022-11-10T10:17:28Z"}, {"author": "Richard Barnes", "text": "

16 / 2B seems pretty justifiably negligible

", "time": "2022-11-10T10:17:55Z"}, {"author": "David Schinazi", "text": "

Who's opposed to removing FFDHE entirely?

", "time": "2022-11-10T10:18:07Z"}, {"author": "Richard Barnes", "text": "

@David: I think Nimrod said Viktor opposed

", "time": "2022-11-10T10:18:26Z"}, {"author": "Carrick Bartle", "text": "

Yes, that's right

", "time": "2022-11-10T10:18:38Z"}, {"author": "Paul Wouters", "text": "

(dayjob is API connections though, not really dealing with endusers on old software/hardware)

", "time": "2022-11-10T10:18:43Z"}, {"author": "Florence D", "text": "

Thanks

", "time": "2022-11-10T10:18:48Z"}, {"author": "David Benjamin", "text": "

But also to the high-level point, it's always viable for implementations to ignore our recommendations. I'd be surprised if browsers could remove RSA key exchange quite yet, but I'm still in favor of deprecating it.

", "time": "2022-11-10T10:19:07Z"}, {"author": "David Schinazi", "text": "

If only one person is opposed, then that doesn't prevent the chairs from declaring rough consensus

", "time": "2022-11-10T10:19:16Z"}, {"author": "Martin Thomson", "text": "

I just skimmed RFC 7435. Sadly, it doesn't say \"accept a weak cipher over plaintext\". If it said that, then we'd be golden.

", "time": "2022-11-10T10:19:51Z"}, {"author": "Daniel Gillmor", "text": "

opportunistic SMTP STARTTLS clients don't do cert validation

", "time": "2022-11-10T10:20:02Z"}, {"author": "Eric Rescorla", "text": "

Just to elaborate, the reason that you can't use different policies in the Web for opportunistic and not is that those are the same Origin in the RFC 6454 sense. And so if you have a weak algorithm used with upgrade then it can affect content loaded over the strong algorithm

", "time": "2022-11-10T10:20:10Z"}, {"author": "Martin Thomson", "text": "

@Daniel Gillmor in that case, why are we even debating this point

", "time": "2022-11-10T10:20:22Z"}, {"author": "Martin Thomson", "text": "

opportunistic can mean \"not secure\"

", "time": "2022-11-10T10:20:42Z"}, {"author": "David Benjamin", "text": "

Section 3 says:
\n With unauthenticated, encrypted communication, OS protocols may
\n employ more liberal settings than would be best practice when
\n security is mandated by policy. Some legacy systems support
\n encryption, but implement only outdated algorithms or protocol
\n versions. Compatibility with these systems avoids the need to resort
\n to cleartext fallback.

", "time": "2022-11-10T10:20:48Z"}, {"author": "Deb Cooley", "text": "

key exchange .ne. authentication

", "time": "2022-11-10T10:20:49Z"}, {"author": "Martin Thomson", "text": "

@David Benjamin awesome, done

", "time": "2022-11-10T10:21:07Z"}, {"author": "Yoav Nir", "text": "

Suggested text: \"FFDHE, kill it with fire!\"

", "time": "2022-11-10T10:22:08Z"}, {"author": "Daniel Gillmor", "text": "

why isn't the section cited by davidben sufficient?

", "time": "2022-11-10T10:22:10Z"}, {"author": "Richard Barnes", "text": "

+1 dkg

", "time": "2022-11-10T10:23:22Z"}, {"author": "Benjamin Schwartz", "text": "

It would be nice to have a pointer to that text in this draft

", "time": "2022-11-10T10:23:40Z"}, {"author": "Daniel Gillmor", "text": "

+1 Ben

", "time": "2022-11-10T10:23:47Z"}, {"author": "Carrick Bartle", "text": "

@Ben agreed

", "time": "2022-11-10T10:24:09Z"}, {"author": "Daniel Gillmor", "text": "

please do not say \"only safe groups\" or \"large enough\"

", "time": "2022-11-10T10:24:51Z"}, {"author": "David Benjamin", "text": "

Do we need a pointer to that text in every deprecation draft? I mean, it's just one sentence, so I won't die on the hill but the nice thing about generic text like this is we can stop worrying about this for every deprecation, when the objection is generic anyway.

", "time": "2022-11-10T10:24:54Z"}, {"author": "Martin Thomson", "text": "

I don't think that the \"large enough\" or \"safe group\" options are viable.

", "time": "2022-11-10T10:24:57Z"}, {"author": "Daniel Gillmor", "text": "

clients cannot verify that. just point to a single list.

", "time": "2022-11-10T10:25:14Z"}, {"author": "Jabber", "text": "

sftcd: wrt opportunistic, if someone's not seen it: RFC7435

", "time": "2022-11-10T10:25:17Z"}, {"author": "Jonathan Hoyland", "text": "

Consensus call on \"Do we want a big room next time?\"

", "time": "2022-11-10T10:25:34Z"}, {"author": "Daniel Gillmor", "text": "

bad Martin squatting on option points

", "time": "2022-11-10T10:26:17Z"}, {"author": "David Schinazi", "text": "

I would humbly propose: poll #1: should we deprecate? (raise your hand means you want to deprecate some or all of FFDHE, not raise means you want another option such as opportunistic) and poll #2: should we deprecate all groups? (raise hand = deprecate FFDHE entirely, not raise = only deprecate some)

", "time": "2022-11-10T10:26:36Z"}, {"author": "Martin Thomson", "text": "

https://www.rfc-editor.org/rfc/rfc7435.html#page-7

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

And to update on this point: the purpose of deprecating this thing is to tell those people they ought to configure properly

", "time": "2022-11-10T10:28:42Z"}, {"author": "Richard Barnes", "text": "

+100 EKR

", "time": "2022-11-10T10:29:32Z"}, {"author": "Jonathan Hoyland", "text": "

EAP-TLS makes me afraid. It undermines the assumptions that all the proofs use.

", "time": "2022-11-10T10:29:50Z"}, {"author": "Mike Ounsworth", "text": "

Eric Rescorla said:

\n
\n

And to update on this point: the purpose of deprecating this thing is to tell those people they ought to configure properly

\n
\n

Ehh, you're assuming that \"old stuff\" even has an ECDH implementation, but I digress b/c those ancient things are not worth holding up the future for.

", "time": "2022-11-10T10:30:36Z"}, {"author": "Daniel Gillmor", "text": "

my support is intended to include support for either \"deprecate all FFDHE\" or \"deprecate all FFDHE except for a narrow list of known groups\"

", "time": "2022-11-10T10:30:51Z"}, {"author": "Eric Rescorla", "text": "

@Mike Ounsworth well, those people ought to upgrade. What's the chance that that has a bunch of SEV 1 vulns anyway

", "time": "2022-11-10T10:31:17Z"}, {"author": "Yoav Nir", "text": "

I like how our options are \"raise hand\" / \"do not raise hand\" / neither raise hand nor do not raise hand.

", "time": "2022-11-10T10:31:22Z"}, {"author": "David Schinazi", "text": "

Could we get a sense of the room for deprecate all vs deprecate some? (my second poll above)

", "time": "2022-11-10T10:31:42Z"}, {"author": "Martin Thomson", "text": "

This tool is terrible. Chairs should be able to set the options.

", "time": "2022-11-10T10:31:59Z"}, {"author": "Mike Ounsworth", "text": "

Eric Rescorla said:

\n
\n

Mike Ounsworth well, those people ought to upgrade. What's the chance that that has a bunch of SEV 1 vulns anyway

\n
\n

Nearly 100%.
\nPoint made.

", "time": "2022-11-10T10:32:40Z"}, {"author": "Daniel Gillmor", "text": "

Ounsworth: please treat \"configure appropriately\" to include \"ensure your cryptographic software dependencies were built in the last decade\"

", "time": "2022-11-10T10:32:51Z"}, {"author": "Yoav Nir", "text": "

Also, \"neither\" got ~60 votes so it's the clear winner

", "time": "2022-11-10T10:32:52Z"}, {"author": "Vittorio Bertola", "text": "

(@Martin Thomson the tool was made this way because \"we do not take votes\" and so it mimicks what used to happen in a physical room)

", "time": "2022-11-10T10:33:22Z"}, {"author": "Martin Thomson", "text": "

There is a case for constrained devices that don't have space for an EC implementation alongside their FF implementation. These are actively updated, but not able to add EC safely. (Just as proof that you can invent an argument in favour of just about anything, not that we should preserve FFDHE)

", "time": "2022-11-10T10:34:28Z"}, {"author": "Martin Thomson", "text": "

@Vittorio Bertola that is even worse. The options should reflect what people intend.

", "time": "2022-11-10T10:35:09Z"}, {"author": "Yoav Nir", "text": "

\"Think of the constrained devices\" is the IETF version of \"think of the children\"

", "time": "2022-11-10T10:35:37Z"}, {"author": "Vittorio Bertola", "text": "

Looks like a discussion for shmoo (perhaps - not sure who has authority over this)

", "time": "2022-11-10T10:35:53Z"}, {"author": "David Schinazi", "text": "

@Yoav lol

", "time": "2022-11-10T10:36:21Z"}, {"author": "Eric Rescorla", "text": "

Has anyone considered doing CBOR? /ducks

", "time": "2022-11-10T10:36:38Z"}, {"author": "Martin Thomson", "text": "

To be clear, not raising a hand requires no action, but the tool allows people to take an explicit action to not raise their hand. This is both silly and confusing.

", "time": "2022-11-10T10:36:41Z"}, {"author": "Daniel Gillmor", "text": "

Yoav wins best quote of IETF 115

", "time": "2022-11-10T10:36:50Z"}, {"author": "David Schinazi", "text": "

No EKR, ducks have not considered using CBOR

", "time": "2022-11-10T10:36:53Z"}, {"author": "Jonathan Hammell", "text": "

Yoav Nir said:

\n
\n

I like how our options are \"raise hand\" / \"do not raise hand\" / neither raise hand nor do not raise hand.

\n
\n

This is equivalent to Y / N / D

", "time": "2022-11-10T10:37:34Z"}, {"author": "Yoav Nir", "text": "

I thought it was Y / D / N respectively

", "time": "2022-11-10T10:38:05Z"}, {"author": "Deb Cooley", "text": "

hmmm yes/no/discourage

", "time": "2022-11-10T10:38:40Z"}, {"author": "Deb Cooley", "text": "

or yes/no/meh

", "time": "2022-11-10T10:38:46Z"}, {"author": "Jonathan Hoyland", "text": "

@sftcd Don't worry, we're screaming on the inside :scream: :joy:

", "time": "2022-11-10T10:38:51Z"}, {"author": "Daniel Gillmor", "text": "

good ol' Optional[bool]

", "time": "2022-11-10T10:38:53Z"}, {"author": "Martin Thomson", "text": "

If the tool said \"Positive\"/\"Negative\"/\"Not enough information\"/\"Don't care\" it would be much more useful.

", "time": "2022-11-10T10:39:15Z"}, {"author": "Jonathan Hoyland", "text": "

Yes / No / If you must

", "time": "2022-11-10T10:39:18Z"}, {"author": "Martin Thomson", "text": "

But I don't get why we can't have free form text for options.

", "time": "2022-11-10T10:39:45Z"}, {"author": "Daniel Gillmor", "text": "

MT: then we have to argue what the difference between \"not enough info\" and \"don't care\" and the people who don't click any button

", "time": "2022-11-10T10:39:54Z"}, {"author": "Martin Thomson", "text": "

@Daniel Gillmor the only invariant here is that the options will be inadequate and argued over in great detail

", "time": "2022-11-10T10:40:26Z"}, {"author": "Richard Barnes", "text": "

can we just define a generic equivalence between TXT records and .well-known ?

", "time": "2022-11-10T10:41:08Z"}, {"author": "Richard Barnes", "text": "

https://example.com/.well-known/txt

", "time": "2022-11-10T10:41:26Z"}, {"author": "Daniel Gillmor", "text": "

speaking as someone with experience in the Debian general resolution process, which allows any number of alternates on the ballot, it is really confusing when there are 6 subtly different options and you're trying to express preferences among them.

", "time": "2022-11-10T10:41:28Z"}, {"author": "Martin Thomson", "text": "

@Richard Barnes I might find that problematic. Which is authoritative?

", "time": "2022-11-10T10:41:37Z"}, {"author": "Richard Barnes", "text": "

Whichever one you ask

", "time": "2022-11-10T10:42:07Z"}, {"author": "Richard Barnes", "text": "

love the one you're with, man

", "time": "2022-11-10T10:42:15Z"}, {"author": "Daniel Gillmor", "text": "

would each participant rank the various options? how would you combine the rankings? condorcet method?

", "time": "2022-11-10T10:42:19Z"}, {"author": "Martin Thomson", "text": "

I know. We can solve this with more engineering.

", "time": "2022-11-10T10:42:58Z"}, {"author": "Jonathan Hoyland", "text": "

@Richard Barnes That sounds like a fabulous way to achieve a protocol confusion attack.

", "time": "2022-11-10T10:42:59Z"}, {"author": "Mike Ounsworth", "text": "

Does this thread about meetecho polls win \"most esoteric debate of 115\" ?

", "time": "2022-11-10T10:43:25Z"}, {"author": "Richard Barnes", "text": "

to be clear, only a 40% serious suggestion. i can't be expected to be coherent before 05:45

", "time": "2022-11-10T10:43:38Z"}, {"author": "Arnaud Taddei", "text": "

@Daniel, Borda?

", "time": "2022-11-10T10:43:39Z"}, {"author": "Eric Rescorla", "text": "

@Daniel Gillmor approval voting

", "time": "2022-11-10T10:43:43Z"}, {"author": "Jonathan Hoyland", "text": "

@Mike Ounsworth Not even in the top 10 :joy:

", "time": "2022-11-10T10:43:49Z"}, {"author": "Deb Cooley", "text": "

I do like that @david S's title changes depending on the topic

", "time": "2022-11-10T10:43:50Z"}, {"author": "David Schinazi", "text": "

I'm an enthusiasm enthusiast

", "time": "2022-11-10T10:44:04Z"}, {"author": "Daniel Gillmor", "text": "

Richard, it's always before 05:45

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

LOL @david

", "time": "2022-11-10T10:44:21Z"}, {"author": "Daniel Gillmor", "text": "

(yes, i was frustrated by Gremlins as a child)

", "time": "2022-11-10T10:44:25Z"}, {"author": "Richard Barnes", "text": "

@Daniel that explains a few things

", "time": "2022-11-10T10:44:29Z"}, {"author": "Jonathan Hoyland", "text": "

I'm very tempted to open my talk with \"Jonathan Hoyland: Not a morning enthusiast.\"

", "time": "2022-11-10T10:44:38Z"}, {"author": "David Schinazi", "text": "

:)

", "time": "2022-11-10T10:45:04Z"}, {"author": "Richard Barnes", "text": "

headline in the Register: Mozilla Says We Should All Be Publishing our TLS Keys

", "time": "2022-11-10T10:45:25Z"}, {"author": "Paul Wouters", "text": "

which webpage. there are so many clusters of nss documentation :) :)

", "time": "2022-11-10T10:45:56Z"}, {"author": "Richard Barnes", "text": "

NSS has documentation?

", "time": "2022-11-10T10:46:09Z"}, {"author": "Richard Barnes", "text": "

i mean, other than pk11pub.h

", "time": "2022-11-10T10:46:20Z"}, {"author": "Daniel Gillmor", "text": "

ouch

", "time": "2022-11-10T10:46:21Z"}, {"author": "Eric Rescorla", "text": "

Yes, it does

", "time": "2022-11-10T10:46:30Z"}, {"author": "Richard Barnes", "text": "

this seems plausible

", "time": "2022-11-10T10:47:08Z"}, {"author": "Deb Cooley", "text": "

but what is your title?????

", "time": "2022-11-10T10:47:14Z"}, {"author": "Daniel Gillmor", "text": "

\"yes enthusiast\", he just got cut off

", "time": "2022-11-10T10:47:32Z"}, {"author": "Bas Westerbaan", "text": "

:joy:

", "time": "2022-11-10T10:47:45Z"}, {"author": "Daniel Gillmor", "text": "

PLEASE DO NOT ENABLE AUTOMATICALLY AND AT SCALE

", "time": "2022-11-10T10:48:07Z"}, {"author": "Jonathan Hoyland", "text": "

There is at least one stack where I've had to implement this.

", "time": "2022-11-10T10:48:33Z"}, {"author": "Jonathan Hoyland", "text": "

When not to do it: Basically always.

", "time": "2022-11-10T10:49:06Z"}, {"author": "Paul Wouters", "text": "

disable automatically after 20 tls connections? :)

", "time": "2022-11-10T10:49:09Z"}, {"author": "Benjamin Schwartz", "text": "

Security Considerations: Don't do this.

", "time": "2022-11-10T10:49:14Z"}, {"author": "David Schinazi", "text": "

I should have said \"enthusiastic yes\"

", "time": "2022-11-10T10:49:27Z"}, {"author": "Richard Barnes", "text": "

sftcd has graduated from the IETF classic \"i didn't read the doc, but...\" to \"i didn't realize there was a doc\". one small step...

", "time": "2022-11-10T10:49:32Z"}, {"author": "Jonathan Hoyland", "text": "

@Paul Wouters That's very optimistic of you. Most pages make dozens and dozens of subrequests.

", "time": "2022-11-10T10:49:37Z"}, {"author": "Daniel Gillmor", "text": "

this is about symmetric keys, not asymmetric secret keys

", "time": "2022-11-10T10:49:59Z"}, {"author": "Jonathan Hoyland", "text": "

Quite often I want to see an entire page load.

", "time": "2022-11-10T10:50:03Z"}, {"author": "Andrei Popov", "text": "

It's a bit strange to publish a document that explains how to do something we don't want deployed.

", "time": "2022-11-10T10:50:23Z"}, {"author": "Paul Wouters", "text": "

ok, fair enough. maybe use 10s then :)

", "time": "2022-11-10T10:50:34Z"}, {"author": "Daniel Gillmor", "text": "

your webpages load in 10s\u203d

", "time": "2022-11-10T10:50:47Z"}, {"author": "Dennis Jackson", "text": "

To reframe: we have a cross-application file format which is already well used. The question is just where the doc lives.

", "time": "2022-11-10T10:50:55Z"}, {"author": "Jonathan Hoyland", "text": "

I mean, we don't plan to run QLog on every QUIC connection, but we still publish it

", "time": "2022-11-10T10:50:56Z"}, {"author": "Jabber", "text": "

sftcd: now that I know it exists I might even read it:-)

", "time": "2022-11-10T10:51:07Z"}, {"author": "David Schinazi", "text": "

In browsers the idea that you can go into settings and turn this mode on (it makes a big red banner in the UI) and it dumps a file with \"this TCP 5-tuple = this key hex blob\"

", "time": "2022-11-10T10:51:22Z"}, {"author": "Jonathan Hoyland", "text": "

Although there was some discussion of running QLog on everything with ring buffer.s

", "time": "2022-11-10T10:51:30Z"}, {"author": "Jabber", "text": "

sftcd: I'd be v. opposed to this work being done elsewhere - it's for debugging TLS

", "time": "2022-11-10T10:52:05Z"}, {"author": "Jonathan Hoyland", "text": "

@David Schinazi I thought you had to start the browser with the command line flag?

", "time": "2022-11-10T10:52:08Z"}, {"author": "David Schinazi", "text": "

Oh you're right Jonathan

", "time": "2022-11-10T10:52:32Z"}, {"author": "Jonathan Hoyland", "text": "

Sorry, environment variable.

", "time": "2022-11-10T10:52:59Z"}, {"author": "David Schinazi", "text": "

Or that

", "time": "2022-11-10T10:53:52Z"}, {"author": "Eric Rescorla", "text": "

environment flags

", "time": "2022-11-10T10:54:04Z"}, {"author": "Dennis Jackson", "text": "

I think Firefox needs to be compiled with a debug flag. Otherwise we don't support it.

", "time": "2022-11-10T10:54:15Z"}, {"author": "Ira McDonald", "text": "

Datatracker still lists Expired drafts

", "time": "2022-11-10T10:54:36Z"}, {"author": "Florence D", "text": "

Please check the notes!

", "time": "2022-11-10T10:55:22Z"}, {"author": "Florence D", "text": "

I tried to capture the discussion but there was a lot of it :smile:

", "time": "2022-11-10T10:55:38Z"}]