[{"author": "Tim Chown", "text": "

please take notes to https://notes.ietf.org/notes-ietf-123-happy

", "time": "2025-07-24T07:34:21Z"}, {"author": "Eric Kinnear", "text": "

meetecho: We've got the raspberry pi bar showing at the top of our slides, any way to hide that?

", "time": "2025-07-24T07:38:42Z"}, {"author": "Tim Chown", "text": "

diffs -00 to -01: https://author-tools.ietf.org/iddiff?url1=draft-ietf-happy-happyeyeballs-v3-00&url2=draft-ietf-happy-happyeyeballs-v3-01&difftype=--html

", "time": "2025-07-24T07:38:53Z"}, {"author": "Lorenzo Miniero", "text": "

@Eric Kinnear on it

", "time": "2025-07-24T07:39:10Z"}, {"author": "Eric Kinnear", "text": "

Thank you!

", "time": "2025-07-24T07:39:29Z"}, {"author": "Eric Kinnear", "text": "

Looks great, much appreciated :)

", "time": "2025-07-24T07:40:54Z"}, {"author": "Benjamin Schwartz", "text": "

\"Clients resolve AAAA and/or A records for the selected TargetName and MAY choose between them using an approach such as Happy Eyeballs [HappyEyeballsV2].\"

", "time": "2025-07-24T07:51:14Z"}, {"author": "Benjamin Schwartz", "text": "

@Erik It just says \"The RECOMMENDED value for the Resolution Delay is 50 milliseconds.\"

", "time": "2025-07-24T07:57:31Z"}, {"author": "Benjamin Schwartz", "text": "

For comparison, RFC 9460 says \"Clients implementing this optimization SHOULD wait for 50 milliseconds before starting optimistic pre-connection, as per the guidance in [HappyEyeballsV2].\"

", "time": "2025-07-24T07:58:07Z"}, {"author": "Dave Plonka", "text": "

Long queue - On this slide of Tommy's page 7 of 25, does anyone else thing these two options (about when to move on) are not mutually exclusive (as written)?

\n

It seems to me that it is kinda saying HTTPS has to come back w/in resolutution delay (otherwise the 2nd case in the \"OR\" will take over)

", "time": "2025-07-24T08:03:56Z"}, {"author": "Dave Plonka", "text": "

From a spec to write to, by my reading, I would want the cases to be clearly exclusive of each other.

", "time": "2025-07-24T08:04:50Z"}, {"author": "Dave Plonka", "text": "

Does the first case imply RD hasn't expired?

", "time": "2025-07-24T08:06:52Z"}, {"author": "Stephen Farrell", "text": "

with that 50ms timer, if I have a bunch of applications that don't do happy eyeballs or use HTTPS RRs, then the stub may have A/AAAA answers but not HTTPS answers leading to e.g. not attempting ECH if talking to recursive is slowish - is that roughly correct?

", "time": "2025-07-24T08:06:56Z"}, {"author": "Mike Blanche", "text": "

to Tommy's point on \"we want to do the left hand side as much as possible\" that should maybe be mentioned in the draft to highlight that to the reader in case anyone starts optimising for the right hand side

", "time": "2025-07-24T08:07:37Z"}, {"author": "Ond\u0159ej Caletka", "text": "

@Dave: I think your reading is correct. The left case is indeed inside the resolution delay

", "time": "2025-07-24T08:07:48Z"}, {"author": "Dave Plonka", "text": "

OK, well we can submit an edit, then, that makes the cases either side of the \"OR\" more clearly exclusive, IMO.

", "time": "2025-07-24T08:08:17Z"}, {"author": "Tim Chown", "text": "

a reminder the issue tracker is at https://github.com/ietf-wg-happy/draft-happy-eyeballs-v3/issues if you want to see which issues are open, or add new ones.

", "time": "2025-07-24T08:09:04Z"}, {"author": "Dave Plonka", "text": "

tnx @Tim

", "time": "2025-07-24T08:09:26Z"}, {"author": "Tim Chown", "text": "

if you want me to ask a specific question because you can speak in meetecho, make that clear.

", "time": "2025-07-24T08:09:54Z"}, {"author": "Tim Chown", "text": "

*can't

", "time": "2025-07-24T08:10:00Z"}, {"author": "Ond\u0159ej Caletka", "text": "

@Stephen I guess that is really the case, but what to do against it than just increasing the resolution delay?

", "time": "2025-07-24T08:10:08Z"}, {"author": "Stephen Farrell", "text": "

@tim: I'm in the room but you closed the line:-)

", "time": "2025-07-24T08:10:13Z"}, {"author": "Tim Chown", "text": "

ah, eric did :)

", "time": "2025-07-24T08:10:25Z"}, {"author": "Stephen Farrell", "text": "

@ondrej: dunno:-)

", "time": "2025-07-24T08:10:27Z"}, {"author": "Eric Kinnear", "text": "

Yep, there's room to bikeshed some of the spelling in the issue

", "time": "2025-07-24T08:11:02Z"}, {"author": "Eric Kinnear", "text": "

And chat :)

", "time": "2025-07-24T08:11:15Z"}, {"author": "Tim Chown", "text": "

but i think the answer to your question is yes, Stephen.

", "time": "2025-07-24T08:11:16Z"}, {"author": "Tim Chown", "text": "

if the connection races ahead without the ECH knowledge, it wont use ECH

", "time": "2025-07-24T08:11:30Z"}, {"author": "Tim Chown", "text": "

@Eric we should be sure to capture/check the chat log after.

", "time": "2025-07-24T08:12:01Z"}, {"author": "Eric Kinnear", "text": "

And +1, I think the answer is yes, if you're the only one asking for SVCB/HTTPS, then you may see things take longer

", "time": "2025-07-24T08:12:14Z"}, {"author": "Eric Kinnear", "text": "

(Chat is stored as part of the meeting proceedings for later reference)

", "time": "2025-07-24T08:13:00Z"}, {"author": "Tim Chown", "text": "

:+1:

", "time": "2025-07-24T08:13:29Z"}, {"author": "Tim Chown", "text": "

@Stephen there is also the catchall text that says \"The logic for prioritizing and falling back between groups of addresses with different security properties and protocol properties is implementation-defined.\"

", "time": "2025-07-24T08:15:21Z"}, {"author": "Benjamin Schwartz", "text": "

Stephen Farrell said:

\n
\n

with that 50ms timer, if I have a bunch of applications that don't do happy eyeballs or use HTTPS RRs, then the stub may have A/AAAA answers but not HTTPS answers leading to e.g. not attempting ECH if talking to recursive is slowish - is that roughly correct?

\n
\n

No, if you support ECH you MUST wait for SVCB before proceeding with TLS ... but you MAY start TCP before you receive SVCB, since TCP doesn't reveal any information that might be modified by the SVCB record.

", "time": "2025-07-24T08:15:39Z"}, {"author": "Stephen Farrell", "text": "

@ben: I just scanned the draft but didn't see that - might've missed it though

", "time": "2025-07-24T08:16:14Z"}, {"author": "Tim Chown", "text": "

i dont recall seeing that

", "time": "2025-07-24T08:16:26Z"}, {"author": "Erik Nygren", "text": "

@ben: But I guess that means you can't proceed with QUIC (eg, if you have a cached Alt-Svc)?

", "time": "2025-07-24T08:16:48Z"}, {"author": "Benjamin Schwartz", "text": "

Stephen Farrell said:

\n
\n

@ben: I just scanned the draft but didn't see that - might've missed it though

\n
\n

https://www.ietf.org/archive/id/draft-ietf-happy-happyeyeballs-v3-01.html#:~:text=If%20the%20client%20is%20either%20an%20SVCB%2Dreliant%20client%20or%20a%20SVCB%2Doptional%20client%20that%20might%20switch%20to%20SVCB%2Dreliant%20connection%20establishment%20during%20the%20process%2C%20the%20client%20MUST%20wait%20for%20SVCB%20records%20before%20proceeding%20with%20the%20cryptographic%20handshake.

", "time": "2025-07-24T08:17:03Z"}, {"author": "Stephen Farrell", "text": "

(that URL is v. odd in this browser:-)

", "time": "2025-07-24T08:17:25Z"}, {"author": "Tim Chown", "text": "

ah, thanks.

", "time": "2025-07-24T08:17:34Z"}, {"author": "Tim Chown", "text": "

so scrub my previous answer :)

", "time": "2025-07-24T08:17:44Z"}, {"author": "Eric Kinnear", "text": "

Takes you to this paragraph, with the last sentence highlighted: https://www.ietf.org/archive/id/draft-ietf-happy-happyeyeballs-v3-01.html#section-6.1-3

", "time": "2025-07-24T08:17:49Z"}, {"author": "Benjamin Schwartz", "text": "

Stephen Farrell said:

\n
\n

(that URL is v. odd in this browser:-)

\n
\n

OK, https://www.ietf.org/archive/id/draft-ietf-happy-happyeyeballs-v3-01.html#section-6.1-3

", "time": "2025-07-24T08:17:55Z"}, {"author": "Daniel Gillmor", "text": "

i don't think #:~: fragment syntax is universally supported

", "time": "2025-07-24T08:18:27Z"}, {"author": "Stephen Farrell", "text": "

ah, thanks - ok that looks nicer from my POV

", "time": "2025-07-24T08:19:26Z"}, {"author": "Tim Chown", "text": "

it does - useful tip thanks

", "time": "2025-07-24T08:19:54Z"}, {"author": "Stephen Farrell", "text": "

by \"nicer\" I meant the text in 6.1.3, not the URLs:-)

", "time": "2025-07-24T08:20:48Z"}, {"author": "Benjamin Schwartz", "text": "

CNAME load balancing :sob:

", "time": "2025-07-24T08:21:14Z"}, {"author": "Tim Chown", "text": "

@stephen well, both :)

", "time": "2025-07-24T08:21:39Z"}, {"author": "Ond\u0159ej Caletka", "text": "

But I guess it would be just resolved by falling back to IPv4 quickly

", "time": "2025-07-24T08:21:53Z"}, {"author": "Daniel Gillmor", "text": "

@meetecho, can you show the speaker? i don't see yaroslav

", "time": "2025-07-24T08:22:17Z"}, {"author": "Tim Chown", "text": "

ah yes, seems to be a mic thats not covered.

", "time": "2025-07-24T08:22:45Z"}, {"author": "Daniel Gillmor", "text": "

\u2639

", "time": "2025-07-24T08:23:11Z"}, {"author": "Daniel Gillmor", "text": "

there we go

", "time": "2025-07-24T08:23:20Z"}, {"author": "Daniel Gillmor", "text": "

thanks!

", "time": "2025-07-24T08:23:21Z"}, {"author": "Tim Chown", "text": "

perfect, thanks @meetecho

", "time": "2025-07-24T08:23:26Z"}, {"author": "Ond\u0159ej Caletka", "text": "

I mean if you end up with server.example.com HTTPS 1 . ipv4hint=192.0.2.1
\nand you resolve that server.example.com AAAA 2001:db8::1 which happens to be in different CDN without ECH support, you just try it, it would fail quickly and you would move on to the IPv4 endpoint, no?

", "time": "2025-07-24T08:24:05Z"}, {"author": "Alessandro Ghedini", "text": "

Well, maybe not specifically for that reason, but I remember discussing the issue at the time

", "time": "2025-07-24T08:25:16Z"}, {"author": "Daniel Gillmor", "text": "

i don't think your argument makes sense, Ben. the server might offer different priorities based on things unrelated to ECH, without intending to publish the inner CH.

", "time": "2025-07-24T08:27:05Z"}, {"author": "Daniel Gillmor", "text": "

Mike, we aren't specifying that here, are we? i don't think the draft states whether the client's security or protocol choices take preference over each other.

", "time": "2025-07-24T08:31:04Z"}, {"author": "Erik Nygren", "text": "

What is critical is that you don't mix-and-match (eg, use IP addresses not somehow associated with a SVCB record, or use an ECH from one SVCB record to an address not associated with that SVCB record)

", "time": "2025-07-24T08:31:14Z"}, {"author": "Stephen Farrell", "text": "

don't make your backup better then:-)

", "time": "2025-07-24T08:34:01Z"}, {"author": "Daniel Gillmor", "text": "

Stephen++

", "time": "2025-07-24T08:35:32Z"}, {"author": "Mike Bishop", "text": "

Sounds like there's an element of filtering out entries that are simply unacceptable \u2014 H1 for WebTransport, for example.

", "time": "2025-07-24T08:36:48Z"}, {"author": "Stephen Farrell", "text": "

and new parameters can be added to SVCB later that'd affect this

", "time": "2025-07-24T08:36:57Z"}, {"author": "Eric Kinnear", "text": "

(no hats) +1 DKG, especially since application is something you might be willing to try in parallel, but security seems best sequential (since exposing SNI on one attempt while trying ECH on another seems rather silly)

", "time": "2025-07-24T08:37:14Z"}, {"author": "Mike Bishop", "text": "

And if the client has a config to say non-ECH is unacceptable when ECH exists, that's a local policy.

", "time": "2025-07-24T08:37:36Z"}, {"author": "Daniel Gillmor", "text": "

sorry, ben \u2639

", "time": "2025-07-24T08:38:02Z"}, {"author": "Benjamin Schwartz", "text": "

:melting_face:

", "time": "2025-07-24T08:38:38Z"}, {"author": "Daniel Gillmor", "text": "

use the mic please

", "time": "2025-07-24T08:40:29Z"}, {"author": "Erik Nygren", "text": "

@_**Ond\u0159ej Caletka: This would be a misconfiguration for server.example.com to use TargetName . if the A/AAAA records for server.example.com are from multiple CDNs. The alternatives are:

\n", "time": "2025-07-24T08:40:37Z"}, {"author": "Daniel Gillmor", "text": "

there's a lot of talk happening in the room that isn't making it into the mics. please try to include those of us who are remote!

", "time": "2025-07-24T08:42:44Z"}, {"author": "Eric Kinnear", "text": "

+1, thanks DKG. The main missing comment was that \"you should stay in your PvD instead of resolving on one interface/network/PvD and then connecting on another\"

", "time": "2025-07-24T08:43:20Z"}, {"author": "Erik Nygren", "text": "

SVCB (9460 section 8) does call out:

\n
\n

A ServiceMode RR is considered \"compatible\" by a client if the client recognizes all the mandatory keys and their values indicate that successful connection establishment is possible. Incompatible RRs are ignored (see step 5 of the procedure defined in Section 3).

\n
\n

which calls for filtering out things that wouldn't work.
\n(In response to something a ways up the thread)

", "time": "2025-07-24T08:46:53Z"}, {"author": "Tim Chown", "text": "

v6-mostly means the operator is trying to reduce use of ipv4, it may be that the v4 performance on that link is better than nat64, but this is an example of operator preference over client performance.

", "time": "2025-07-24T08:49:17Z"}, {"author": "Erik Nygren", "text": "

Where this gets messy is when it's client synthesized IPv6 (not DNS64-synthesized)

", "time": "2025-07-24T08:50:08Z"}, {"author": "Tim Chown", "text": "

i recall at a uk university, v6 mostly moved the v6 traffic from 60% to 80%, but still 20% are 'legacy' v4.

", "time": "2025-07-24T08:50:21Z"}, {"author": "Tim Chown", "text": "

there's 4 slides on downgrade attacks, questions after the 4th :)

", "time": "2025-07-24T08:52:27Z"}, {"author": "Tim Chown", "text": "

sorry, 5.

", "time": "2025-07-24T08:52:56Z"}, {"author": "Tim Chown", "text": "

questions at 'proposal' slide

", "time": "2025-07-24T08:53:08Z"}, {"author": "Benjamin Schwartz", "text": "

This attack is discussed in https://datatracker.ietf.org/doc/html/rfc9460#section-3.1-1

", "time": "2025-07-24T08:53:20Z"}, {"author": "Stephen Farrell", "text": "

the attacker here could be between recursive and authoritative even if the client uses e.g. DoH

", "time": "2025-07-24T08:53:36Z"}, {"author": "Daniel Gillmor", "text": "

even with encrypted transport, the network can figure out which is which unless the DNS channel coalesces into a single QUIC packet or TLS record, or does adequate padding.

", "time": "2025-07-24T08:55:18Z"}, {"author": "Erik Nygren", "text": "

Enterprise Security and Parental Controls products will almost certainly do this to strip ECH (either on the secure resolver, or on the insecure channel).

", "time": "2025-07-24T08:55:54Z"}, {"author": "Eric Kinnear", "text": "

Isn't the whole point to stall/not be downgraded? How does a longer timer help?

", "time": "2025-07-24T08:55:59Z"}, {"author": "Eric Kinnear", "text": "

Locking the queue momentarily

", "time": "2025-07-24T08:56:33Z"}, {"author": "Eric Kinnear", "text": "

Lorenzo: Did you have a follow-up question for Ben?

", "time": "2025-07-24T08:57:52Z"}, {"author": "Daniel Gillmor", "text": "

how does retransmission or next connection attempt interact with early data?

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

Here is the MUST that we need to obey:

\n
\n

Accordingly, ECH-capable SVCB-optional clients MUST switch to SVCB-reliant connection establishment if SVCB resolution succeeded (as defined in Section 3 of [SVCB]) and all alternative endpoints have an \"ech\" SvcParam.

\n
\n

(section 5.1 of https://datatracker.ietf.org/doc/html/draft-ietf-tls-svcb-ech-08#name-disabling-fallback which is in the publication queue)

", "time": "2025-07-24T09:00:48Z"}, {"author": "Daniel Gillmor", "text": "

seems sufficient to me

", "time": "2025-07-24T09:09:30Z"}, {"author": "Daniel Gillmor", "text": "

it doesn't preclude coalescing, does it?

", "time": "2025-07-24T09:10:48Z"}, {"author": "Daniel Gillmor", "text": "

i think we should just encourage coalescing the queries at least when using encrypted transport for DNS.

", "time": "2025-07-24T09:11:18Z"}, {"author": "Daniel Gillmor", "text": "

that seems like the strongest defense that the client can offer.

", "time": "2025-07-24T09:11:37Z"}, {"author": "Benjamin Schwartz", "text": "

It's also the most efficient behavior.

", "time": "2025-07-24T09:12:05Z"}, {"author": "Eric Kinnear", "text": "

meetecho: Can we adjust the camera to the presenter :)

", "time": "2025-07-24T09:13:16Z"}, {"author": "Tim Chown", "text": "

that's https://arxiv.org/pdf/2412.00263

", "time": "2025-07-24T09:13:23Z"}, {"author": "Daniel Gillmor", "text": "

thanks Tim

", "time": "2025-07-24T09:13:31Z"}, {"author": "Eric Kinnear", "text": "

(Thank you!)

", "time": "2025-07-24T09:15:55Z"}, {"author": "Eric Kinnear", "text": "

\"there's a D right there and that means it's going to give dual stack answers back to the client\"

", "time": "2025-07-24T09:17:44Z"}, {"author": "Eric Kinnear", "text": "

(while away from mic, pointing at the slide)

", "time": "2025-07-24T09:17:51Z"}, {"author": "Daniel Gillmor", "text": "

David++

", "time": "2025-07-24T09:19:35Z"}, {"author": "Stephen Farrell", "text": "

good stuff all right

", "time": "2025-07-24T09:20:06Z"}, {"author": "Daniel Gillmor", "text": "

yeah this is a major contribution

", "time": "2025-07-24T09:20:20Z"}, {"author": "Patrick Sattler", "text": "

We are also happy to get feedback on what features could be useful in the future

", "time": "2025-07-24T09:22:36Z"}, {"author": "Tim Chown", "text": "

:+1:

", "time": "2025-07-24T09:23:00Z"}, {"author": "Philipp Tiesel", "text": "

For the record: Node.js uses happy eyeballs by default for all tcp connections

", "time": "2025-07-24T09:29:09Z"}, {"author": "Stephen Farrell", "text": "

reporting to random things seems like a potential DoS vector

", "time": "2025-07-24T09:29:18Z"}, {"author": "Benjamin Schwartz", "text": "

This seems like an interesting potential use case for the DAP protocol

", "time": "2025-07-24T09:30:26Z"}, {"author": "Stephen Farrell", "text": "

suggested privacy approach: don't report anything:-)

", "time": "2025-07-24T09:30:29Z"}, {"author": "Tim Chown", "text": "

:P

", "time": "2025-07-24T09:30:38Z"}, {"author": "Daniel Gillmor", "text": "

it's more efficient too

", "time": "2025-07-24T09:30:50Z"}, {"author": "Tim Chown", "text": "

certainly needs to be togglable, and default off. like other 'reporting' options from OSes

", "time": "2025-07-24T09:31:13Z"}, {"author": "Daniel Gillmor", "text": "

that MUST is going to be impossible to enforce

", "time": "2025-07-24T09:31:55Z"}, {"author": "Erik Nygren", "text": "

If we didn't need to worry about privacy, sending an ICMP message over the address family that succeeded indicating that the other address family failed is something that network operators who cared could potentially easily work with. (I wonder if excluding any actual details of the addresses would be good enough to at least detect there is an issue, but wouldn't help diagnose it.)

", "time": "2025-07-24T09:33:06Z"}, {"author": "Mike Bishop", "text": "

Threshold encryption is an interesting tool here \u2014 low-volume reports stay private, but top hits in the aggregate will emerge.

", "time": "2025-07-24T09:33:27Z"}, {"author": "Benjamin Schwartz", "text": "

:+1:

", "time": "2025-07-24T09:34:26Z"}, {"author": "Tim Chown", "text": "

ok, great

", "time": "2025-07-24T09:34:37Z"}, {"author": "Benjamin Schwartz", "text": "

Mike Bishop said:

\n
\n

Threshold encryption is an interesting tool here \u2014 low-volume reports stay private, but top hits in the aggregate will emerge.

\n
\n

That's DAP!

", "time": "2025-07-24T09:34:50Z"}]