Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a variety of examples #18

Merged
merged 3 commits into from
Oct 21, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
93 changes: 92 additions & 1 deletion draft-ietf-tls-svcb-ech.md
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ In wire format, the value of the parameter is an ECHConfigList ({{Section 4 of !
ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAEAAWQ
VZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA="
~~~
{: title="ECH SvcParam with a public_name of "ech-sites.example.com"}
{: title="ECH SvcParam with a public_name of "ech-sites.example.com""}

# Server behavior

Expand Down Expand Up @@ -90,6 +90,97 @@ Origins that publish an "ech" SvcParam in their HTTPS record SHOULD also publish

If all HTTPS records for an alt-authority contain "ech" SvcParams, the client MUST adopt SVCB-reliant behavior (as in {{disabling-fallback}}) for that RRSet. This precludes the use of certain connections that Alt-Svc would otherwise allow, as discussed in {{Section 9.3 of !SVCB}}.

# Examples

~~~
$ORIGIN simple.example. ; Simple example zone
@ 300 IN A 192.0.2.1
AAAA 2001:db8::1
HTTPS 1 . ech=ABC...
www 300 IN A 192.0.2.1
AAAA 2001:db8::1
HTTPS 1 . ech=ABC...
Comment on lines +97 to +102

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought one of the points of the HTTPS record was that you didn have to keep manually adding A/AAAA sync ups between the apex and www. of a zone ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HTTPS records allow apex aliasing (as in the next example), but only for clients that support HTTPS records. These examples mostly assume that compatibility with non-HTTPS-record-aware clients is required.

In this case, we could avoid duplicating the A/AAAA records by making www a CNAME to the apex (as in the multi-CDN example), but I thought that might not be the best choice for our simplest example.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we just be clear that this retains compatibility (see suggestion above),

~~~
{: title="Simple example zone with the same configuration on the apex and web domain. It is compatible with clients that do or do not support HTTPS records."}

~~~
$ORIGIN heterogeneous.example. ; Example zone with two pools of servers
pool1 300 IN A 192.0.2.1
AAAA 2001:db8:1::a
pool2 300 IN A 192.0.2.2
AAAA 2001:db8:2::a
service 300 IN SVCB 1 pool1 ech=ABC...
SVCB 1 pool2 ech=DEF...
A 192.0.2.1
A 192.0.2.2
AAAA 2001:db8:1::a
AAAA 2001:db8:2::a
~~~
{: title="Service that allows clients to choose between two server pools with different ECH configurations."}

~~~
$ORIGIN cdn.example. ; CDN operator zone
pool 300 IN A 192.0.2.1
AAAA 2001:db8::1
HTTPS 1 . ech=ABC...

$ORIGIN customer.example. ; CDN customer's zone
@ 3600 IN HTTPS 0 pool.cdn.example.
; Apex IP records for compatibility with clients that do not support
; HTTPS records.
@ 300 IN A 192.0.2.1
AAAA 2001:db8::1

www 300 IN CNAME pool.cdn.example.
~~~
{: title="ECH usage pattern for an aliasing-based CDN."}

~~~
$ORIGIN secret.example. ; High confidentiality zone
www 3600 IN HTTPS 1 backend ech=ABC... mandatory=ech
backend 300 IN A 192.0.2.1
AAAA 2001:db8::1
~~~
{: title="A domain that is only reachable using ECH."}

~~~
$ORIGIN cdn1.example. ; First CDN operator zone
pool 300 IN A 192.0.2.1
AAAA 2001:db8::1
HTTPS 1 . ech=ABC...

$ORIGIN cdn2.example. ; Second CDN operator zone
pool 300 IN A 192.0.2.2
AAAA 2001:db8::2
HTTPS 1 . ech=DEF...

;; Multi-CDN customer zone (version 1)
$ORIGIN customer.example.
@ 3600 IN HTTPS 0 pool.cdn1.example.
; Apex IP records for compatibility with clients that do not support
; HTTPS records.
@ 300 IN A 192.0.2.1
AAAA 2001:db8::1
www 3600 IN CNAME pool.cdn1.example.

;; Multi-CDN customer zone (version 2)
@ 3600 IN HTTPS 0 pool.cdn2.example.
@ 300 IN A 192.0.2.2
AAAA 2001:db8::2
www 3600 IN CNAME pool.cdn2.example.
~~~
{: title="Multi-CDN configuration using server-side selection."}

~~~
$ORIGIN dns.example. ; DNS server example.
@ 3600 IN A 192.0.2.1
AAAA 2001:db8::1
HTTPS 1 . ech=ABC... alpn=h3 dohpath=/q{?dns}

_dns 3600 IN SVCB 1 @ ech=ABC... alpn=dot,doq,h3 dohpath=/q{?dns}
~~~
{: title="Example of a DNS server that supports ECH."}

# Security Considerations

A SVCB RRSet containing some RRs with "ech" and some without is vulnerable to a downgrade attack: a network intermediary can block connections to the endpoints that support ECH, causing the client to fall back to a non-ECH endpoint. This configuration is NOT RECOMMENDED. Zone owners who do use such a mixed configuration SHOULD mark the RRs with "ech" as more preferred (i.e. lower SvcPriority value) than those without, in order to maximize the likelihood that ECH will be used in the absence of an active adversary.
Expand Down
Loading