Discuss impact of ECH

[tfpauly]

ECH use can make the client be SVCB-reliant instead of SVCB-optional. At the very least, the algorithm will be impacted by being SVCB-reliant.

[tfpauly]

Note that this can impact the current section 6 on connection attempts

[bashi]

Suppose that the default server of www.example.com doesn’t support ECH, but it has an alternative endpoint at svc1.example.net that supports ECH.

www.example.com.  3600 IN SVCB 1 svc1.example.net. ech="..."
www.example.com.  3600 IN    A 192.0.2.2
www.example.com.  3600 IN AAAA 2001:db8::2

svc1.example.net. 3600 IN SVCB 1 . ipv4hint=192.0.2.3 ipv6hint=2001:db8::3
svc1.example.net. 3600 IN    A 192.0.2.3
svc1.example.net. 3600 IN AAAA 2001:db8::3

An ECH-capable client issues A, AAAA and SVCB queries in paralell. If the client receives response(s) for A and/or AAAA before SVCB, the client can take two approaches:

• Speculatively start connection attempts first (after the "Resolution Delay", if A resolved first) and wait for a SVCB response. If the SVCB record contains “ech”, abandon any connections using the addresses from A/AAAA for www.example.com. The client should not finish the algorithm until a SVCB is received, even when one of connection attempts succeeds.
• Wait for a SVCB response before starting connection attempts. If the response contains “ech”, modify the sorted list to remove addresses came from A/AAAA for www.example.com.

In both cases, the client handles SVCB resolution failures including timeout. The client may treat SVCB resolution failures as fatal or nonfatal.

I think we want to start connection attempts speculatively. Thoughts?

[DavidSchinazi]

That depends on priorities: if the user (or user agent) cares more about privacy, speculatively starting connection attempts will leak the TLS ClientHello, whereas waiting would have provided ECH keys. If the user (or user agent) cares more about performance, than starting speculatively will save time. I could imagine a browser doing speculative connection attempts in general but disabling them in incognito mode for example.

[bashi]

I should have clarified what connection attempt means. I meant a connection attempt as a TCP handshake (not including a TLS ClientHello). I thought that ECH-capable clients should wait for a SVCB response before sending ClientHello even they speculatively started TCP handshakes.

This brings up another question for me. IIUC Happy Eyeballs v2 is only applicable to TCP. Do we want to extend the scope of v3 to QUIC/H3? If we include QUIC/H3, we may want to break a connection attempt into more granular steps:

1. Underlying transport protocol handshake, applicable only to TCP
2. TLS handshake

For example, a strict ECH-capable SVCB-reliant client would want to wait for an SVCB response before 1 and 2. A more relaxed ECH-capable client may start 1 before an SVCB response and would wait for the response before 2. SVCB-optional clients may start both 1 and 2 before an SVCB response, with some delay.

[DavidSchinazi]

For TCP, I totally agree with you - it's possible to send the TCP SYN before SVB and then wait before sending the TLS ClientHello.

I think that this new document should discuss QUIC, so we might need to differentiate between the TLS/TCP and the QUIC case.

[tfpauly]

Opened #10 to talk about QUIC

[nidhijaju]

Based on the above discussion, it seems there are three ways of approaching privacy in Happy Eyeballs with regards to ECH:

1. You care about maximum privacy and wait for ECH keys no matter what before proceeding.
2. You care about performance and privacy, so you start the TCP handshake and then wait for ECH keys until you make TLS/QUIC (with a timeout?).
3. You don't wait for ECH keys and just start attempting connections.

I think they're kind of implied in https://tfpauly.github.io/draft-happy-eyeballs-v3/draft-happy-eyeballs-v3.html#section-6.1-3, but we don't really talk about the privacy impacts of sending a TCP SYN ahead of receiving a SVCB RR (i.e. additional exposure of IP addresses that you might otherwise have never contacted).

Also, wondering if we should talk about a timeout for 2) above.

[ericorth]

Is the context of this discussion this part of draft-ietf-dnsop-svcb-https-12.html#section-3.1:

If DNS responses are cryptographically protected (e.g. using DNSSEC or TLS [DoT][DoH]), and SVCB resolution fails due to an authentication error, SERVFAIL response, transport error, or timeout, the client SHOULD abandon its attempt to reach the service, even if the client is SVCB-optional. Otherwise, an active attacker could mount a downgrade attack by denying the user access to the SvcParams.

???

For further context, the specific downgrade attack we were worried about when drafting that paragraph is that a network-level attacker could using timing/size analysis to figure out which QUIC packets contained the HTTPS response and block just those while allowing A/AAAA through. The client would then get A and AAAA, but HTTPS would either be blackholed or return one of the errors listed above, depending on how and where the attacker blocks the HTTPS packets.

So if the client then proceeds to attempt connection past the point where ECH could have been used, it means you've given attackers the ability to block ECH without piercing the encrypted DoH connection. So we're not just talking a privacy loss of sometimes missing out on ECH when the response doesn't arrive in time. We're talking a security compromise scenario where the attacker can completely and deliberately prevent ECH from ever being used.

@davidben Since I believe he was also in many of those conversations and might have thoughts.

[ekinnear]

IETF 123:

• Only applies to secure DNS (since otherwise trivial to drop ECHConfig). If you see packets going by and drop 1/3 of them, you have a 33% chance of dropping the ECHConfig enough for the client to get started without it.
• Proposal: If using secure DNS, require HTTPS response before proceeding.
• Alternative: Introduce a longer timer.
  • Attackers may be willing to wait and slow you down, so a longer timeout makes the user experience slower but doesn't provide meaningfully greater protection.
  • EK: What if you waited long enough that any packets being persistently dropped would cause the DoH connection to close?
• Desire to find a way to mitigate the attack, rather than waiting as long as possible.
  • One approach: include both queries and responses in the same packet. You have to coalesce all the queries & responses. Can't necessarily guarantee that DoH resolver is going to coalesce, since it should answer what it can promptly. Also puts additional requirements on the resolver that only apply to encrypted transports, which may be hard to get implemented.
• RFC 9460 currently requires the wait-for-HTTPS-response behavior.