[{"author": "Benjamin Kaduk", "text": "

meetecho please pan

", "time": "2022-07-28T21:36:10Z"}, {"author": "Benjamin Kaduk", "text": "

Thanks!

", "time": "2022-07-28T21:36:27Z"}, {"author": "Benjamin Kaduk", "text": "

Write the draft, see if TLS wants it, take it here otherwise.

", "time": "2022-07-28T21:39:44Z"}, {"author": "Benjamin Kaduk", "text": "

Why support a protocol version that's mandatory to implement under the BCP guidance for TLS usage?

", "time": "2022-07-28T21:40:54Z"}, {"author": "Benjamin Kaduk", "text": "

MT advocating renego, oh my.
\nThough I do seem to recall that there is some RFC that says it's okay so long as there is no application data preceding it.

", "time": "2022-07-28T21:42:22Z"}, {"author": "Martin Thomson", "text": "

Yes, HTTP/2 does that.

", "time": "2022-07-28T21:44:30Z"}, {"author": "Benjamin Kaduk", "text": "

Ah, right. Thanks.

", "time": "2022-07-28T21:44:49Z"}, {"author": "Martin Thomson", "text": "

What Bob is saying is good advice.

", "time": "2022-07-28T21:45:55Z"}, {"author": "Benjamin Kaduk", "text": "

Yes, that was good advice from Bob.

", "time": "2022-07-28T21:46:06Z"}, {"author": "Martin Thomson", "text": "

https://www.rfc-editor.org/rfc/rfc9261.html

", "time": "2022-07-28T21:47:16Z"}, {"author": "Martin Thomson", "text": "

That architecture document clearly needs tons of work.

", "time": "2022-07-28T21:49:37Z"}, {"author": "Jabber", "text": "

mcr: is now a stuckee author on the architecture.

", "time": "2022-07-28T21:50:14Z"}, {"author": "Wes Hardaker", "text": "

@martin: yes, that's known -- the architecture document is far less complete.

", "time": "2022-07-28T21:54:52Z"}, {"author": "Martin Thomson", "text": "

This idea that TLS 1.3 is big and complex is a lie. It is only the differences from TLS 1.2 that make it challenging. The core protocol is fairly straightforward.

", "time": "2022-07-28T21:56:04Z"}, {"author": "Martin Thomson", "text": "

...unless you want 0-RTT.

", "time": "2022-07-28T21:56:14Z"}, {"author": "Benjamin Kaduk", "text": "

For your next act, tell me that QUIC is not big and complex. :wink:

", "time": "2022-07-28T21:56:35Z"}, {"author": "Benjamin Kaduk", "text": "

Also, I would like to know what tooling Jacques used to get the kerning on these slides.

", "time": "2022-07-28T21:57:41Z"}, {"author": "Martin Thomson", "text": "

QUIC is a nightmare of complexity :)

", "time": "2022-07-28T21:57:51Z"}, {"author": "Andrew Fregly", "text": "

I turned up my headset volume

", "time": "2022-07-28T21:57:55Z"}, {"author": "Benjamin Kaduk", "text": "

@Andrew Fregly just remember to turn it back down before anyone else talks

", "time": "2022-07-28T21:58:50Z"}, {"author": "Martin Thomson", "text": "

I think that the kerning is a font thing based on what I'm seeing.

", "time": "2022-07-28T21:59:09Z"}, {"author": "Nick Sullivan", "text": "

Note that this might need more than just an extension. A new certificate_type would likely need to be defined.

", "time": "2022-07-28T21:59:16Z"}, {"author": "Benjamin Kaduk", "text": "

Is Nick talking about Jacques' thing or Viktor's thing?

", "time": "2022-07-28T21:59:40Z"}, {"author": "Nick Sullivan", "text": "

Viktor's thing.

", "time": "2022-07-28T21:59:50Z"}, {"author": "Martin Thomson", "text": "

Are these domain name SANs?

", "time": "2022-07-28T22:00:00Z"}, {"author": "Benjamin Kaduk", "text": "
\n

kerning is a font thing based on what I'm seeing

\n
\n

Hmm, https://datatracker.ietf.org/doc/slides-114-dance-leveraging-dnssec-for-digital-identity-trust-registries/02/ shows only a PDF upload, and viewing the PDF natively I think I see the same as you. Which seems to implicate the \"conversion\" step that is used to turn the slides from the datatracker into jpgs used by the streaming software.

", "time": "2022-07-28T22:02:06Z"}, {"author": "Nick Sullivan", "text": "

Question Viktor's draft that I might have missed. Is TLS 1.2 supported because we expect that some (D)TLS implementations do not have (D)TLS 1.3 support but will be willing to implement this draft before deploying 1.3?

", "time": "2022-07-28T22:03:38Z"}, {"author": "Martin Thomson", "text": "

@Nick Sullivan That's essentially the answer I got when I just asked. I think that that is a reasonable thing, particularly for existing deployments, who might only be looking to provide an alternative trust anchor system.

", "time": "2022-07-28T22:05:01Z"}, {"author": "Benjamin Kaduk", "text": "

Given OpenSSL's stance on DTLS 1.3, that seems to be a likely candidate.

\n

And I think the points that I found most compelling were not really about the codebase being unwilling to write in the 1.3 support, but rather that there is a deployed base where the incremental update within 1.2 is feasible but there are logistical constraints (e.g., flash storage, QA certification) that prevent the deployed devices from updating to 1.3.

", "time": "2022-07-28T22:05:11Z"}, {"author": "Martin Thomson", "text": "

People are welcome to use the NSS DTLS 1.3 implementation. We're not done yet, but it's close.

", "time": "2022-07-28T22:05:40Z"}, {"author": "Tim Wicinski", "text": "

Not thrilled about another RR at a zone apex.

", "time": "2022-07-28T22:07:09Z"}, {"author": "Martin Thomson", "text": "

I don't understand why you can't rely on configuration for trust anchors.

", "time": "2022-07-28T22:07:31Z"}, {"author": "Jim Fenton", "text": "

I can picture political problems with IANA having country-specific trust registries

", "time": "2022-07-28T22:07:37Z"}, {"author": "Martin Thomson", "text": "

@Jim Fenton Why would you even expect to be able to trust $COUNTRY for this purpose?

", "time": "2022-07-28T22:07:59Z"}, {"author": "Martin Thomson", "text": "

...whatever this purpose really is.

", "time": "2022-07-28T22:08:12Z"}, {"author": "Jim Fenton", "text": "

@Martin Exactly my point.

", "time": "2022-07-28T22:08:23Z"}, {"author": "Martin Thomson", "text": "

Put differently, why does the flow of trust follow the DNS hierarchy?

", "time": "2022-07-28T22:09:01Z"}, {"author": "Hugo Salgado", "text": "

Tim Wicinski said:

\n
\n

Not thrilled about another RR at a zone apex.

\n
\n

Or you can start in _trustregistry.arpa too

", "time": "2022-07-28T22:09:33Z"}, {"author": "Jabber", "text": "

mcr: Paul, IANA because DNSSEC.

", "time": "2022-07-28T22:10:46Z"}, {"author": "Tim Wicinski", "text": "

I will ask \"why not a TXT Record\" and I will now show myself out

", "time": "2022-07-28T22:13:00Z"}, {"author": "Benjamin Kaduk", "text": "

Excellent, so then you won't be here to hear me propose a new RRTYPE in the parent zone!
\n<ducks>

", "time": "2022-07-28T22:13:29Z"}, {"author": "Jacques Latour", "text": "

yes, root zone because of DNSSEC

", "time": "2022-07-28T22:13:32Z"}, {"author": "John O'Brien", "text": "

I was thinking, \"Why not a PTR RR?\", and will show my self out after Tim.

", "time": "2022-07-28T22:13:47Z"}, {"author": "Rolf Sonneveld", "text": "

I don't see the speaker

", "time": "2022-07-28T22:14:52Z"}, {"author": "Michael B", "text": "

There's a lot of acronyms here...

", "time": "2022-07-28T22:14:53Z"}, {"author": "Benjamin Kaduk", "text": "

I think at least half of them are \"standard\" IETF things, at least. But yes, lots of acronyms.

", "time": "2022-07-28T22:15:25Z"}, {"author": "Rolf Sonneveld", "text": "

Thanks, I now see him

", "time": "2022-07-28T22:15:47Z"}, {"author": "Jim Fenton", "text": "

Acronyms are a strong tradition for aircraft things

", "time": "2022-07-28T22:16:05Z"}, {"author": "Benjamin Kaduk", "text": "

IKO is one I'm not familiar with.

", "time": "2022-07-28T22:16:31Z"}, {"author": "Benjamin Kaduk", "text": "

or rather, ICAO, the internet informs me.

", "time": "2022-07-28T22:16:50Z"}, {"author": "Michael B", "text": "

Ah, I missed a few that were defined in the first slide.

", "time": "2022-07-28T22:17:27Z"}, {"author": "Jabber", "text": "

mcr: thinks ICAO should be pronounced I-COW.

", "time": "2022-07-28T22:24:29Z"}, {"author": "Jim Fenton", "text": "

I've heard it pronounced that way, yes.

", "time": "2022-07-28T22:24:51Z"}, {"author": "Martin Thomson", "text": "

Apple has a policy of not announcing upcoming products.

", "time": "2022-07-28T22:25:02Z"}, {"author": "Jabber", "text": "

mcr: iCOW

", "time": "2022-07-28T22:25:30Z"}, {"author": "Martin Thomson", "text": "

If size is a thing, then cTLS.

", "time": "2022-07-28T22:26:11Z"}, {"author": "Jabber", "text": "

mcr: Apple's take on animal-free meat, perhaps.

", "time": "2022-07-28T22:26:14Z"}, {"author": "Benjamin Kaduk", "text": "

OpenSSL raw public key support is in https://github.com/openssl/openssl/pull/18185

", "time": "2022-07-28T22:27:23Z"}]