[{"author": "Mirja K\u00fchlewind", "text": "

okay, got it

", "time": "2022-07-29T16:30:04Z"}, {"author": "Jan Evang", "text": "

An early starlink graph linked in this blog post https://crna.substack.com/p/what-is-happening-to-the-internet
\nEdit: also a graph from ip-observatory on tracking the Russian army by observing network outages.

", "time": "2022-07-29T16:46:04Z"}, {"author": "Andrew Campling", "text": "

Please speak directly into the room mic as otherwise it's very heard to hear questions in the room (and probably remotely too)

", "time": "2022-07-29T16:46:14Z"}, {"author": "Dave Plonka", "text": "

Let's cut the queue here for time. No new people in queue pls.

", "time": "2022-07-29T16:46:34Z"}, {"author": "Eric Kinnear", "text": "

@Dave Plonka there's also a button in Meetecho to lock the queue so people can't join

", "time": "2022-07-29T16:47:57Z"}, {"author": "Dave Plonka", "text": "

tnx - I see it now!

", "time": "2022-07-29T16:48:12Z"}, {"author": "Spencer Dawkins", "text": "

Tal's presentation on the effect of the invasion of Ukraine was a thought-provoking talk on Friday of IETF meeting week.

", "time": "2022-07-29T16:57:25Z"}, {"author": "Ian Williams", "text": "

\"I'm going so QUICly,\" I think he meant to say...

", "time": "2022-07-29T17:04:03Z"}, {"author": "Dave Plonka", "text": "

:)

", "time": "2022-07-29T17:04:19Z"}, {"author": "Dave Plonka", "text": "

locked queue ; we'll take Shivan's q

", "time": "2022-07-29T17:05:43Z"}, {"author": "Matt Joras", "text": "

Something to keep in mind about the country variations: you have to remember there's behavioral differences that are correlated with countries. For example, users in certain countries may be much less likely to update their browsers or even restart their browsers. This will have an effect on a browser's configuration, since older versions are less likely to have their configuration updated and opt into QUIC.

", "time": "2022-07-29T17:07:54Z"}, {"author": "Ties de Kock", "text": "

Interesting results in the tables/diagrams faceted by single variables. Makes me wonder about sample size and what the underlying variable causing the divergence is

", "time": "2022-07-29T17:08:02Z"}, {"author": "Chris Box", "text": "

I suspect the measured browser market share is impacted by ad blocking. Ad blocking is likely to be more popular on some browsers than others.

", "time": "2022-07-29T17:10:00Z"}, {"author": "Benjamin Kaduk", "text": "

I'm vaguely curious if Geoff et al are using nginx+boringssl or nginx+quictls, but it shouldn't be relevant for the purposes of this data.

", "time": "2022-07-29T17:10:21Z"}, {"author": "Matt Joras", "text": "

The nginx beta referenced uses boringssl afaik.

", "time": "2022-07-29T17:11:18Z"}, {"author": "Benjamin Kaduk", "text": "

https://www.nginx.com/blog/our-roadmap-quic-http-3-support-nginx/ says it can use either boringssl or the quictls fork of openssl

", "time": "2022-07-29T17:11:55Z"}, {"author": "David Lawrence", "text": "

Can't hear the speaker well in the room

", "time": "2022-07-29T17:12:03Z"}, {"author": "Mirja K\u00fchlewind", "text": "

still?

", "time": "2022-07-29T17:12:11Z"}, {"author": "David Lawrence", "text": "

Yeah still quieter than earlier speakers

", "time": "2022-07-29T17:12:22Z"}, {"author": "Andrew Campling", "text": "

Please ask Usama to lean into the mic

", "time": "2022-07-29T17:12:23Z"}, {"author": "Michael T\u00fcxen", "text": "

It is OK for me...

", "time": "2022-07-29T17:12:25Z"}, {"author": "David Lawrence", "text": "

better!

", "time": "2022-07-29T17:12:37Z"}, {"author": "Jonathan Reed", "text": "

did we lose audio, or is it just me?

", "time": "2022-07-29T17:20:17Z"}, {"author": "Benjamin Schwartz", "text": "

I lost audio...

", "time": "2022-07-29T17:20:18Z"}, {"author": "Sofia Celi", "text": "

lost audio?

", "time": "2022-07-29T17:20:19Z"}, {"author": "Nguyen Hoang", "text": "

is it just me or the sound has gone

", "time": "2022-07-29T17:20:20Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

I just lost audio from the room. Is it just me?

", "time": "2022-07-29T17:20:21Z"}, {"author": "Joerg Ott", "text": "

me too

", "time": "2022-07-29T17:20:23Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Apparently not :-D

", "time": "2022-07-29T17:20:25Z"}, {"author": "Daniam Henriques", "text": "

yeah lost audio remotely

", "time": "2022-07-29T17:20:26Z"}, {"author": "Asad Saeed", "text": "

yup

", "time": "2022-07-29T17:20:32Z"}, {"author": "Ian Williams", "text": "

silent in the room too

", "time": "2022-07-29T17:20:34Z"}, {"author": "Rich Salz", "text": "

network issues in the room

", "time": "2022-07-29T17:20:34Z"}, {"author": "Sofia Celi", "text": "

and also video now

", "time": "2022-07-29T17:20:37Z"}, {"author": "Michael T\u00fcxen", "text": "

Lost audio and video...

", "time": "2022-07-29T17:20:44Z"}, {"author": "Nguyen Hoang", "text": "

oops, 0 kbps

", "time": "2022-07-29T17:20:52Z"}, {"author": "Erik Nygren", "text": "

same. and here I thought it was my client/bluetooth/etc at first

", "time": "2022-07-29T17:20:52Z"}, {"author": "Benjamin Schwartz", "text": "

Netsplit :)

", "time": "2022-07-29T17:21:00Z"}, {"author": "Ian Williams", "text": "

presentation folks are aware

", "time": "2022-07-29T17:21:00Z"}, {"author": "Anna Brunstrom", "text": "

remote presentations seem more reliable :)

", "time": "2022-07-29T17:21:19Z"}, {"author": "Nguyen Hoang", "text": "

second that ;)

", "time": "2022-07-29T17:21:30Z"}, {"author": "Lorenzo Miniero", "text": "

Looks like a network issue, investigating

", "time": "2022-07-29T17:22:01Z"}, {"author": "Sofia Celi", "text": "

second that

", "time": "2022-07-29T17:22:05Z"}, {"author": "Benjamin Kaduk", "text": "

This is not so bad compared to yesterday, when comcast was managing to drop about half of the incoming audio packets.
\n(Maybe due to traversing the Atlantic twice.)

", "time": "2022-07-29T17:22:06Z"}, {"author": "Erik Nygren", "text": "

\"A multi-year longitudinal study on network reliability during IETF meetings\"

", "time": "2022-07-29T17:22:30Z"}, {"author": "Benjamin Kaduk", "text": "

ha!

", "time": "2022-07-29T17:22:43Z"}, {"author": "Christian Huitema", "text": "

I lost audio and video, and meetecho is showing me the title page of the deck

", "time": "2022-07-29T17:23:25Z"}, {"author": "Nguyen Hoang", "text": "

not sure if it's related to the email sent this morning:Everyone,

\n

As the meeting comes to a close, we wanted to update you on the shutdown schedule for the IETF Network. We will be in the process of decommissioning the network all afternoon.

\n

\u2022 The wireless APs that deliver the main IETF networks in the Sheraton meeting rooms will be removed throughout day the as sessions come to a close.
\n\u2022 The Terminal Room will be closing at 3pm today.
\n\u2022 The \u201cietf-hotel\u201d SSID will remain until Sunday early evening if you have extended your stay over the weekend.

\n

We hope you all have a good trip home and look forward to seeing everyone in London!

\n", "time": "2022-07-29T17:23:26Z"}, {"author": "Colin Perkins", "text": "

Someone could probably do some NLP analysis of the complaints about A/V issues in the chat logs :)

", "time": "2022-07-29T17:23:46Z"}, {"author": "Mirja K\u00fchlewind", "text": "

we lost connectivity in the room

", "time": "2022-07-29T17:24:38Z"}, {"author": "Michael T\u00fcxen", "text": "

Back again...

", "time": "2022-07-29T17:24:50Z"}, {"author": "Nguyen Hoang", "text": "

:thumbsup:

", "time": "2022-07-29T17:24:59Z"}, {"author": "Matt Joras", "text": "

the recovery was relatively seamless fwiw, so that's nice

", "time": "2022-07-29T17:25:14Z"}, {"author": "Matt Joras", "text": "

not all systems are so great at coming back cleanly

", "time": "2022-07-29T17:25:34Z"}, {"author": "Dave Plonka", "text": "

locking queue for time

", "time": "2022-07-29T17:25:39Z"}, {"author": "Tommy Jensen", "text": "

I saw mention of a paper but missed the link -- anyone have it handy?

", "time": "2022-07-29T17:27:56Z"}, {"author": "Nguyen Hoang", "text": "

https://datatracker.ietf.org/meeting/114/materials/agenda-114-maprg-05.html

", "time": "2022-07-29T17:28:16Z"}, {"author": "Nguyen Hoang", "text": "

papers' PDF links included

", "time": "2022-07-29T17:28:35Z"}, {"author": "Tommy Jensen", "text": "

Not for this presentation, unfortunately (configanator)

", "time": "2022-07-29T17:28:50Z"}, {"author": "Matt Joras", "text": "

\"everyone is using it\" -- I wish :)

", "time": "2022-07-29T17:28:55Z"}, {"author": "Ties de Kock", "text": "

I don't see the link for this presentation, I assume it's https://arxiv.org/abs/1908.04518 but that's 2019.

", "time": "2022-07-29T17:29:06Z"}, {"author": "Tommy Jensen", "text": "

Looks right, thank you!

", "time": "2022-07-29T17:29:44Z"}, {"author": "Andrew Campling", "text": "

Try https://datatracker.ietf.org/meeting/114/materials/slides-114-maprg-active-tls-fingerprinting-00

", "time": "2022-07-29T17:29:50Z"}, {"author": "Tommy Jensen", "text": "

(I needed previous, which Ties found, but thank you Andrew)

", "time": "2022-07-29T17:31:40Z"}, {"author": "Shivan Sahib", "text": "

Does this work with encrypted client hello?

", "time": "2022-07-29T17:37:01Z"}, {"author": "Benjamin Kaduk", "text": "

Sure, you just have to sample a wider variety of stuff.

", "time": "2022-07-29T17:37:44Z"}, {"author": "Benjamin Schwartz", "text": "

@Shivan Sahib I don't believe ECH would have any effect on this, since the fingerprint is computed by an active client

", "time": "2022-07-29T17:37:50Z"}, {"author": "Benjamin Schwartz", "text": "

If anything, ECH might make this more effective, by providing more diversity in server behavior

", "time": "2022-07-29T17:38:10Z"}, {"author": "Christian Huitema", "text": "

This feels like a great start for a game of whack a mole...

", "time": "2022-07-29T17:38:12Z"}, {"author": "Shivan Sahib", "text": "

Benjamin Schwartz said:

\n
\n

Shivan Sahib I don't believe ECH would have any effect on this, since the fingerprint is computed by an active client

\n
", "time": "2022-07-29T17:39:48Z"}, {"author": "Shivan Sahib", "text": "

Ah right

", "time": "2022-07-29T17:39:53Z"}, {"author": "Rich Salz", "text": "

Cloudflare definitely wrote their own TLS stack and open sourced it. Akamai uses openssl which is widely used. Dunno about fastly.

", "time": "2022-07-29T17:40:02Z"}, {"author": "Benjamin Schwartz", "text": "

It sounds like they're also doing some HTTP fingerprinting, so \"I'm using OpenSSL\" isn't the whole story

", "time": "2022-07-29T17:40:43Z"}, {"author": "Rich Salz", "text": "

ok

", "time": "2022-07-29T17:41:08Z"}, {"author": "Shivan Sahib", "text": "

Reminds me of JA3 https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967/

", "time": "2022-07-29T17:41:32Z"}, {"author": "Spencer Dawkins", "text": "

\"Provided a methodology ... that maximize information extraction from servers\" ... and every SEC person in the room burst into tears ... :upside_down:

", "time": "2022-07-29T17:41:41Z"}, {"author": "Benjamin Kaduk", "text": "

Enh, it's public information (for a certain sense of \"public\")

", "time": "2022-07-29T17:42:19Z"}, {"author": "Sofia Celi", "text": "

Cloudflare uses boringSSL on some cases, openssl on others, and a bunch of GoTLS: https://blog.cloudflare.com/make-ssl-boring-again/ There was a very old TLS 1.3 implementation they open sourced (https://github.com/cloudflare/tls-tris), but not a whole stack as far as I know

", "time": "2022-07-29T17:43:44Z"}, {"author": "Spencer Dawkins", "text": "

Benjamin Kaduk said:

\n
\n

Enh, it's public information (for a certain sense of \"public\")

\n
\n

Sure. I was just reacting to the phrasing on the slide ... :wink:

", "time": "2022-07-29T17:43:56Z"}, {"author": "Benjamin Kaduk", "text": "

Yeah, that's fair :)

", "time": "2022-07-29T17:44:11Z"}, {"author": "Ties de Kock", "text": "

Shivan Sahib said:

\n
\n

Reminds me of JA3 https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967/

\n
\n

Also in use by cloudflare bot detection

", "time": "2022-07-29T17:44:24Z"}, {"author": "Rich Salz", "text": "

kerckhoffs law

", "time": "2022-07-29T17:44:44Z"}, {"author": "Usama Naseer", "text": "

Here's the paper: https://www.usenix.org/conference/nsdi22/presentation/naseer

", "time": "2022-07-29T17:45:37Z"}, {"author": "Rich Salz", "text": "

And ++ to Spencer for using zulip quote and reply feature :)

", "time": "2022-07-29T17:45:50Z"}, {"author": "Tommy Jensen", "text": "

Thank you Usama!

", "time": "2022-07-29T17:46:01Z"}, {"author": "Usama Naseer", "text": "

Unfortunately the network broke during the pres. If anyone is interested, they can read the paper here or connect with me (usama_naseer@brown.edu) or my advisor Theo Benson (theophilus_benson@brown.edu).

", "time": "2022-07-29T17:47:56Z"}, {"author": "Nick Sullivan", "text": "

Correction to above: Cloudflare does not use OpenSSL or tls-tris for public-facing websites.

", "time": "2022-07-29T17:48:07Z"}, {"author": "Dave Plonka", "text": "

Thanks Usama!

", "time": "2022-07-29T17:50:15Z"}, {"author": "Markus Sosnowski", "text": "

Addition to the question of Dave: as far as I know Multi CDNs are implemented through DNS. And in the paper we resolved the names before starting any analysis. So we should have fingerprinted always the servers from a single CDN

", "time": "2022-07-29T17:52:31Z"}, {"author": "Rich Salz", "text": "

@Nick Sullivan heard you had to isolate. Sorry, hope you feel better soon.

", "time": "2022-07-29T17:53:51Z"}, {"author": "Benjamin Kaduk", "text": "

I think the scheme coming out of the CDNI working group does include some non-DNS mechanisms for multiCDN

", "time": "2022-07-29T17:53:57Z"}, {"author": "Jake Holland", "text": "

also, the meeting materials didn't have nick's slides, I think? (https://datatracker.ietf.org/meeting/114/session/maprg)

", "time": "2022-07-29T17:57:31Z"}, {"author": "Sofia Celi", "text": "

they are there now @Jake Holland : https://datatracker.ietf.org/meeting/114/materials/slides-114-maprg-measuring-the-availability-and-response-times-of-public-encrypted-dns-resolvers-00

", "time": "2022-07-29T17:58:18Z"}, {"author": "Andrew Campling", "text": "

Care is needed here: it is not correct to assume that all DNS filtering is bad / evil. For example, it is quite common (at least outside the US) to use DNS filtering to block access to malware or CSAM.

", "time": "2022-07-29T18:04:23Z"}, {"author": "Shivan Sahib", "text": "

I don't think the presentation said anything about that

", "time": "2022-07-29T18:08:04Z"}, {"author": "Sofia Celi", "text": "

+1 to Shivan

", "time": "2022-07-29T18:08:25Z"}, {"author": "Sofia Celi", "text": "

The paper is quite interesting as well: https://arxiv.org/pdf/1911.00563.pdf

", "time": "2022-07-29T18:08:35Z"}, {"author": "Andrew Campling", "text": "

There are perhaps better tools to overcome censorship in non-democratic regimes, for example DNS-over-Tor.

", "time": "2022-07-29T18:10:54Z"}, {"author": "Nguyen Hoang", "text": "

gfwatch.org

", "time": "2022-07-29T18:12:16Z"}, {"author": "Tommy Jensen", "text": "

Define \"better\"; this presentation seems to say DoH is effective as is (assuming pairing with ECH). Why is DNS over Tor better?

", "time": "2022-07-29T18:12:30Z"}, {"author": "Chris Box", "text": "

The final key takeaway (that ECH can only be successful in bypassing authoritarian censorship if it's universal), was already understood by the TLS WG, e.g. https://www.rfc-editor.org/rfc/rfc8744.html#name-do-not-stick-out

", "time": "2022-07-29T18:13:41Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Because it does not suffer from https://dl.acm.org/doi/10.1145/3340301.3341133 . If you think hiding you DNS traffic is going to save you read the paper and think again.

", "time": "2022-07-29T18:13:49Z"}, {"author": "Florence D", "text": "

Shivan Sahib said:

\n
\n

I don't think the presentation said anything about that

\n
\n

No but the conclusion that ECH should be adopted universally doesn't consider that networks/enterprises may be using SNI for cyber security or to block known bad traffic at the moment.

", "time": "2022-07-29T18:13:54Z"}, {"author": "Andrew Campling", "text": "

@Tommy because it is possible to block access to the DoH resolvers. Also, in some contexts, there are downsides in the use of ECH (but that's a longer conversation!).

", "time": "2022-07-29T18:14:21Z"}, {"author": "Florence D", "text": "

Very interesting presentation though :)

", "time": "2022-07-29T18:14:31Z"}, {"author": "Vittorio Bertola", "text": "

I am also a bit sick of these one-sided, ideological, shallow discussions of Internet content filtering. The IETF should be able to have better discussions of this topic.

", "time": "2022-07-29T18:14:51Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

DoH is very easy to detect by just looking at packet sizes and volume flowing up/down between IPs. Very distinguishable from web traffic.

", "time": "2022-07-29T18:15:03Z"}, {"author": "Tommy Jensen", "text": "
\n

If you think hiding you DNS traffic is going to save you read the paper and think again

\n
\n

Quite the generalization. Yes IPs leak info, but that's not the only concern (this was all about gaining access to content, one part of the problems faced today).

", "time": "2022-07-29T18:15:04Z"}, {"author": "Erik Nygren", "text": "

Is there also a chicken-and-egg here? If countries start blocking ECH before it reaches critical mass then it may be undeployable by general websites that need to be reachable in those countries.

", "time": "2022-07-29T18:15:05Z"}, {"author": "Nick Sullivan", "text": "

One thing to consider is that deployments of ESNI vs ECH is that ECHI has GREASE. This means that ECH and non-ECH connections should both contain the ECH extension in the client hello.

", "time": "2022-07-29T18:15:24Z"}, {"author": "Alissa Cooper", "text": "

Nothing in this presentation was ideological. It was the presentation of measurement results.

", "time": "2022-07-29T18:15:46Z"}, {"author": "Vittorio Bertola", "text": "

The last slide was.

", "time": "2022-07-29T18:16:06Z"}, {"author": "Nick Sullivan", "text": "

So if the ECH extension is blocked, it blocks all traffic from a browser that supports ECH, not just the ones with encrypted SNI enabled on the server side.

", "time": "2022-07-29T18:16:12Z"}, {"author": "Erik Nygren", "text": "

Thanks, Nick. I missed that being introduced.

", "time": "2022-07-29T18:16:33Z"}, {"author": "Sofia Celi", "text": "

@Vittorio Bertola I didn't see anything ideological there. I'm failing to see where that point comes from.

", "time": "2022-07-29T18:16:53Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Well, unless the blocking is conditioned on IP, right?

", "time": "2022-07-29T18:16:54Z"}, {"author": "Shivan Sahib", "text": "

I'm still not seeing what was ideological about any of this. If your goals are to maximize X and Y then you should do Z.

", "time": "2022-07-29T18:16:59Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Agreed, I don't see ideology in this talk either. It's just we are spending lots of time on technologies we already know are half broken.

", "time": "2022-07-29T18:17:35Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Anyway, next talk!

", "time": "2022-07-29T18:17:52Z"}, {"author": "Andrew Campling", "text": "

To Vittorio's point, the presentatino did seem to imply that DNS filtering is bad, which ignores its widespread use i nmany markets outside the US, and very widespread use by enterprises.

", "time": "2022-07-29T18:18:00Z"}, {"author": "Nick Sullivan", "text": "

@rich No isolation for me, I've luckily tested negative every day. I've just selectively joined some meetings remotely so I could be at two at once.

", "time": "2022-07-29T18:18:28Z"}, {"author": "Jonathan Reed", "text": "

Andrew Campling said:

\n
\n

To Vittorio's point, the presentatino did seem to imply that DNS filtering is bad, which ignores its widespread use i nmany markets outside the US, and very widespread use by enterprises.

\n
\n

I didn't get that impression at all, and I'm usually one of the first to point out legitimate uses of DNS filtering. But that's just my $0.02

", "time": "2022-07-29T18:18:52Z"}, {"author": "Andrew Campling", "text": "

*presentation

", "time": "2022-07-29T18:19:00Z"}, {"author": "Dave Plonka", "text": "

From Nick's preso: https://noise-lab.github.io/dns-measurement/

", "time": "2022-07-29T18:19:20Z"}, {"author": "Tommy Jensen", "text": "

I liked the question someone posed about types of content being censored. This would help scope the discussion around the value in circumvention efforts, but would likely be impossible to gather without disagreements about the intent of each censor.

", "time": "2022-07-29T18:19:35Z"}, {"author": "Sofia Celi", "text": "

@Dave Plonka I was just trying to find that. ty!

", "time": "2022-07-29T18:20:14Z"}, {"author": "Vittorio Bertola", "text": "

Well, self-selecting the scope of the study as authoritarian countries only is an ideological choice to justify the conclusion that \"ECH has to be deployed everywhere\", which would not be sustainable if the discussion had also considered situations in which ECH creates problems rather than solving them.

", "time": "2022-07-29T18:20:53Z"}, {"author": "Rich Salz", "text": "

That's an interesting point, @Vittorio Bertola .

", "time": "2022-07-29T18:21:42Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Hmm okay, I did not considered this. Interesting.

", "time": "2022-07-29T18:22:19Z"}, {"author": "Tommy Jensen", "text": "

Repeating the research in many more countries across diff continents to see the intersection of censored names would indeed be a good and new view, Vittorio.

", "time": "2022-07-29T18:22:25Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

But honestly I can't see ECH being deployed any time soon. There is huge first-mover disadvantage which gets stronger as more countries block ECH.

", "time": "2022-07-29T18:22:57Z"}, {"author": "Chris Box", "text": "

Pretty sure Seoul is not in North Korea

", "time": "2022-07-29T18:23:10Z"}, {"author": "Eric Rescorla", "text": "

And yet we already see announcements about forms of surveillance that would be prevented by ECH in non-authoritarian countries. Cf. Trustpid

", "time": "2022-07-29T18:23:12Z"}, {"author": "Jim Reid", "text": "

This sort of language is unhelpful Vittorio. The survey wasn't self-selecting. IMO it was more than reasonable to measure the impacts in the places where DNS filtering/censorship is widely used.

", "time": "2022-07-29T18:24:00Z"}, {"author": "Erik Nygren", "text": "

Nick has a good point that if ECH is greased it becomes client implementations that include that greasing that all want to go out around the same time. Not that they'll use ECH but it makes it harder to block. And then server implementations become easier to ramp up more slowly.

", "time": "2022-07-29T18:24:25Z"}, {"author": "Tommy Jensen", "text": "
\n

IMO it was more than reasonable to measure the impacts in the places where DNS filtering/censorship is widely used.

\n
", "time": "2022-07-29T18:25:06Z"}, {"author": "Tommy Jensen", "text": "

hmm, fair

", "time": "2022-07-29T18:25:10Z"}, {"author": "Nguyen Hoang", "text": "

Sorry if my slides weren't clear enough but we didn't self-select or targeted certain countries. We did this study is 85 countries, and reported blocking events we found in those with highest blocking rates.

", "time": "2022-07-29T18:25:14Z"}, {"author": "Andrew Campling", "text": "

To see an exploration of some of the deployment cosiderations relating to ECH, see https://datatracker.ietf.org/doc/draft-campling-ech-deployment-considerations/ and https://datatracker.ietf.org/doc/html/draft-taddei-ech4ent-introduction-00.html

", "time": "2022-07-29T18:25:16Z"}, {"author": "Tommy Jensen", "text": "
\n

We did this study is 85 countries, and reported blocking events we found in those with highest blocking rates.

\n
\n

Are the data all available in the paper (he asked being lazy and wanting to know before end of session when he can open the paper)?

", "time": "2022-07-29T18:26:04Z"}, {"author": "Sofia Celi", "text": "

+1 to Jim and also Nguyen. The paper is quite clear on it.

", "time": "2022-07-29T18:26:10Z"}, {"author": "Rich Salz", "text": "

@Nguyen Hoang Oh, I (at least) missed that. Thanks for the clarification.

", "time": "2022-07-29T18:26:22Z"}, {"author": "Nguyen Hoang", "text": "

the data is here: https://homepage.np-tokumei.net/publication/publication_2022_pam/

", "time": "2022-07-29T18:26:45Z"}, {"author": "Sofia Celi", "text": "

The paper of @Nguyen Hoang prsentation: https://arxiv.org/pdf/1911.00563.pdf

", "time": "2022-07-29T18:26:47Z"}, {"author": "Jim Reid", "text": "

Thanks for the URLs!

", "time": "2022-07-29T18:28:03Z"}, {"author": "Tommy Jensen", "text": "

+1, thank you both!

", "time": "2022-07-29T18:28:37Z"}, {"author": "Shivan Sahib", "text": "

Thanks for the clarification @Nguyen Hoang

", "time": "2022-07-29T18:28:40Z"}, {"author": "Vittorio Bertola", "text": "

Ok, I'll go read the study rather than the presentation then. Still, one can support any desired policy conclusion by focusing on the data that play well to it. If one focused on countries where blocking rates are low, one could rather conclude that ECH is not warranted.

", "time": "2022-07-29T18:29:08Z"}, {"author": "Andrew Campling", "text": "

Nick's presentation is making the case for resolver discovery, as being developed in the IETF ADD working group. :-)

", "time": "2022-07-29T18:29:22Z"}, {"author": "Nguyen Hoang", "text": "

@Andrew Campling, to your point about malware and cooperate network safeguarding, we did think of it and discussed in the Section 7.2 of this paper: https://arxiv.org/pdf/1911.00563.pdf

", "time": "2022-07-29T18:29:33Z"}, {"author": "Florence D", "text": "

Florence D said:

\n
\n

Shivan Sahib said:

\n
\n

I don't think the presentation said anything about that

\n
\n

No but the conclusion that ECH should be adopted universally doesn't consider that networks/enterprises may be using SNI for cyber security or to block known bad traffic at the moment.

\n
\n

Ah, I see this is mentioned in the paper. I look forward to reading it in more detail.

", "time": "2022-07-29T18:29:36Z"}, {"author": "Jake Holland", "text": "

re-running some of it with e.g. endpoints in schools where there's a regulatory requirement to block explicit content would be interesting too

", "time": "2022-07-29T18:30:10Z"}, {"author": "Andrew Campling", "text": "

@Nguyen Thanks for this, much appreciated. I'll be sure to read the paper after the session finishes.

", "time": "2022-07-29T18:30:27Z"}, {"author": "Dave Plonka", "text": "

Thanks much to the presenters who took the time to share their work. Thanks Mirja for the great work soliciting for work that we didn't find via the Call for Contributions this time!

", "time": "2022-07-29T18:30:36Z"}, {"author": "Eric Rescorla", "text": "

I don't believe anybody is proposing adopting ECH universally. In particular, I would expect that networks that control the endpoint can disable ECH.

", "time": "2022-07-29T18:30:39Z"}, {"author": "Ian Williams", "text": "

mic's starting to break up in the room

", "time": "2022-07-29T18:30:42Z"}, {"author": "Benjamin Kaduk", "text": "

remote as well

", "time": "2022-07-29T18:30:54Z"}, {"author": "Tommy Jensen", "text": "

On the final point on screen, that is absolutely true. More encrypted DNS resolvers would be great for de-centralization efforts.

", "time": "2022-07-29T18:31:23Z"}, {"author": "Andrew Campling", "text": "

@Tommy J +1

", "time": "2022-07-29T18:31:42Z"}, {"author": "Benjamin Kaduk", "text": "

Eric Rescorla said:

\n
\n

I don't believe anybody is proposing adopting ECH universally. In particular, I would expect that networks that control the endpoint can disable ECH.

\n
\n

Well, except for the slide that said \"=> Encrypted Client Hello should be adopted universally\"

", "time": "2022-07-29T18:31:59Z"}, {"author": "Shivan Sahib", "text": "

@Nick Feamster seems like deploying encrypted DNS to more orgs would be opposed to making things too big to fail? As mentioned in the previous pres

", "time": "2022-07-29T18:32:16Z"}, {"author": "Eric Rescorla", "text": "

@Benjamin Kaduk OK, I'm not attending the talk, but I assume these people don't speak for browser vendors.

", "time": "2022-07-29T18:32:27Z"}, {"author": "Andrew Campling", "text": "

The discussion on ECh needs to continue, perhaps a topic for IETF 115

", "time": "2022-07-29T18:32:33Z"}, {"author": "Tommy Jensen", "text": "

Perhaps a diff between \"universally adopted by web servers\" and \"universally adopted by sending clients in specific environments\"?

", "time": "2022-07-29T18:32:41Z"}, {"author": "Eric Rescorla", "text": "

The discussion on ECH takes place in TLS.

", "time": "2022-07-29T18:32:44Z"}, {"author": "Eric Rescorla", "text": "

Where there is already consensus to build it

", "time": "2022-07-29T18:32:50Z"}, {"author": "Eric Rescorla", "text": "

You should of course feel free to object in IETF LC

", "time": "2022-07-29T18:32:56Z"}, {"author": "Mirja K\u00fchlewind", "text": "

I thinks that a known meetecho issue with some browsers that audio degrades over time... restart audio helps but we where anyway at the end

", "time": "2022-07-29T18:33:04Z"}]