Repository: sftcd/wkesni
Pull request #39: better split mode text
Author: login: sftcd
Created: 2025-04-02T15:40:32Z | Merged: 2025-04-02T21:42:07Z

I tried to simplify and improve the split-mode text. It still needs work for sure, but this might be easier to discuss. We should (later I guess) add back something about multi-CDN deployments.


Diff:
diff --git a/draft-ietf-tls-wkech.txt b/draft-ietf-tls-wkech.txt
index 3b8800d..cd25234 100644
--- a/draft-ietf-tls-wkech.txt
+++ b/draft-ietf-tls-wkech.txt
@@ -73,20 +73,21 @@ Table of Contents
    2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
    3.  Example uses of the well-known URI for ECH  . . . . . . . . .   4
      3.1.  Shared-mode deplpoyment.  . . . . . . . . . . . . . . . .   4
-     3.2.  Split-mode, multi-CDN deplpoyment.  . . . . . . . . . . .   5
+     3.2.  Split-mode deployment.  . . . . . . . . . . . . . . . . .   5
    4.  The origin-svcb well-known URI  . . . . . . . . . . . . . . .   7
    5.  The JSON structure for origin service binding info  . . . . .   7
-   6.  Zone Factory behaviour  . . . . . . . . . . . . . . . . . . .  10
-   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
-   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
-   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
-     9.1.  Well-known endpoint registration  . . . . . . . . . . . .  12
-     9.2.  JSON Service Binding Info . . . . . . . . . . . . . . . .  13
-   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
-     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
-     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
-   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  15
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
+   6.  Zone Factory behaviour  . . . . . . . . . . . . . . . . . . .  11
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
+   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
+   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
+     9.1.  Well-known endpoint registration  . . . . . . . . . . . .  13
+     9.2.  JSON Service Binding Info . . . . . . . . . . . . . . . .  14
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
+     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
+   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  16
+   Appendix B.  Examples . . . . . . . . . . . . . . . . . . . . . .  17
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17
 
 1.  Introduction
 
@@ -108,7 +109,6 @@ Table of Contents
 
 
 
-
 Farrell, et al.          Expires 4 October 2025                 [Page 2]
 
 Internet-Draft           Well-Known URI for SVCB              April 2025
@@ -257,15 +257,15 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
    its cached copy of the JSON resource.  If the resource has changed,
    it repeats this process.
 
-3.2.  Split-mode, multi-CDN deplpoyment.
+3.2.  Split-mode deployment.
 
    The following diagram, and this entire section, is a place-holder
    just to have something on which to base discussion, and will change.
 
-
-
-
-
+   In this section, we describe one possible way in which ECH split-mode
+   could be deployed and make use of this .well-known scheme.  There are
+   of course various other deployment options that might be more
+   effective.
 
 
 
@@ -287,17 +287,17 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
                        | backend.example.com|
                        |                    |
                        +--------------------+
-                           ^^           ^^
-                           ||    VPN    ||
-                           VV           VV
-              +--------------------+ +--------------------+
-              |                    | |                    |
-    TLS       |   2001:DB8::1111   | |   2001:DB8::FFFF   | Client-
-   Client <-->|backend.example.com | | backend.example.com| facing
-              |  cfs.cdn1.example  | |  cfs.cdn2.example  | servers
-              +--------------------+ +--------------------+
+         (1) backend       ^^           ^^   (2) backend publishes
+             reads CFS'    ||    VPN    ||       backend's
+             .well-known   VV           VV       .well-known
+                       +--------------------+
+                       |                    |
+        TLS            |   2001:DB8::1111   |
+        Client <---->  |backend.example.com |
+                       |   cfs.lb.example   |
+                       +--------------------+
                            ^            ^
-        (1) ZF reads       |            |  (2) ZF checks
+        (3) ZF reads       |            |  (4) ZF checks
             .well-known    V            V      ECHConfig
                        +--------------------+
                        |                    |
@@ -305,7 +305,7 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
                        |                    |
                        +--------------------+
                                  |
-                                 | (3) ZF publishes new HTTPS RR
+                                 | (5) ZF publishes new HTTPS RR
                                  V
                        +--------------------+
                        |                    |
@@ -313,23 +313,23 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
                        |                    |
                        +--------------------+
 
-          Figure 2: Shared-Mode Topology with Zone Factory and DNS
+          Figure 2: Split-Mode Topology with Zone Factory and DNS
 
    In this topology, the overall process is as in the previous section,
-   but with the following differences:
+   but with the following differences: but with the following
+   differences:
 
-   1.  There are two client-facing servers (in different CDNs) for the
-       one "REAL" backend server that hosts the actual web resources.
+   1.  The client-facing server, (CFS), is a load-balancer and only does
+       ECH decryption.  The load-balancer is called cfs.lb.example.
 
-   2.  ECH split-mode is assumed to be supported by both CDNs.
+   2.  Traffic between the CFS and backend is protected using some kind
+       of VPN.
 
-   3.  The "REAL" backend.example.com content is hosted on some
-       machine(s) accessible from the client-facing servers via a VPN.
-
-   4.  The ZF notes that backend.example.com has multiple AAAA RR values
-       published, so queries for the .well-known at each of those.  In
-       this case the values received differ.
+   3.  The A/AAAA values for backend.example.com and cfs.lb.example are
+       the same.
 
+   4.  backend.example.com content is hosted on some machine(s)
+       accessible via the CFS and via the VPN.
 
 
 
@@ -338,10 +338,21 @@ Farrell, et al.          Expires 4 October 2025                 [Page 6]
 Internet-Draft           Well-Known URI for SVCB              April 2025
 
 
-   5.  The ZF next attempts to connect to each CFS using the relevant
-       ECH values and confirms that they are all working.
+   5.  backend.example.com wants to acquire the ECH config information
+       from the CFS by querying the CFS' .well-known URL, in this case
+       https://cfs.lb.example/.well-known/origin-svcb
+
+   6.  backend.example.com then publishes its chosen JSON (presumably
+       including the relevant ECH config information) at
+       https://backend.example.com/.well-known/origin-svcb That resource
+       is hosted on the "real" backend.example.com machine.
 
-   6.  Note tha the ZF is not aware that ECH split-mode is in use.
+   7.  The ZF attempts to connect to https://backend.example.com using
+       the generated HTTPS record(s), including the relevant ECH values,
+       and confirms that all is working before updating the zone.
+
+   Note that the in this example ZF does not necessarily know that ECH
+   split-mode is in use.
 
 4.  The origin-svcb well-known URI
 
@@ -355,8 +366,34 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
    If no new ECHConfig value verifies (as per Section 6), then the zone
    factory MUST NOT modify the zone.
 
+   With this scheme, web origins can only "speak for themselves" so that
+   if the backend is e.g. at port 8443 rather then the default 443, then
+   the ZF MUST access https://backend.example.com:8443/.well-known/
+   origin-scvb when considering modifications to the HTTPS/SVCB records
+   for _8443._https.example.com.  As a consequence, a ZF will need to be
+   configured to periodically refresh the JSON resource for each origin
+   separately, that is, a ZF cannot "discover" from port 443 that some
+   other service, for which the ZF is expected to update the DNS, is
+   also present on another port on the same host.
+
 5.  The JSON structure for origin service binding info
 
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al.          Expires 4 October 2025                 [Page 7]
+
+Internet-Draft           Well-Known URI for SVCB              April 2025
+
+
        {
            "regeninterval": 3600,
            "endpoints": [{
@@ -385,15 +422,6 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
 
                     Figure 4: Sample JSON with aliasing
 
-
-
-
-
-Farrell, et al.          Expires 4 October 2025                 [Page 7]
-
-Internet-Draft           Well-Known URI for SVCB              April 2025
-
-
    The JSON file at the well-known URI MUST contain an object with two
    keys: "regeninterval", whose value is a number, and "endpoints" whose
    value is an array of objects.  All other keys MUST be ignored.
@@ -404,6 +432,24 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
    used by the ZF to generate DNS TTL values and to determine when to
    next poll the origin for updates.
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al.          Expires 4 October 2025                 [Page 8]
+
+Internet-Draft           Well-Known URI for SVCB              April 2025
+
+
    More precise expiration times are common (e.g., the "notAfter" field
    in certificate lifetime validity, discussed in Section 4.1.2.5 of
    [RFC5280]), but are too stringent for this use-case.  The ZF cannot
@@ -443,16 +489,23 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
    HTTPS records [RFC9460] in natural JSON while minimizing the risk of
    invalid configurations.
 
+   The following keys are defined for ServiceMode entries:
+
+   target:  The value is a string containing a fully qualified domain
 
 
-Farrell, et al.          Expires 4 October 2025                 [Page 8]
+
+
+
+
+
+
+
+Farrell, et al.          Expires 4 October 2025                 [Page 9]
 
 Internet-Draft           Well-Known URI for SVCB              April 2025
 
 
-   The following keys are defined for ServiceMode entries:
-
-   target:  The value is a string containing a fully qualified domain
       name corresponding to the HTTPS record's TargetName with the final
       "." removed.  The default value is the empty string (""),
       corresponding to a TargetName of ".".  To avoid complex conversion
@@ -496,25 +549,32 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
    These definitions, taken with the ZF behaviour (Section 6) specified
    below, provide the following important properties:
 
+   *  Origins can express any useful configuration that is representable
+      by HTTPS records, including multiple endpoints representing
+      different ports, providers, etc.
 
 
 
 
 
-Farrell, et al.          Expires 4 October 2025                 [Page 9]
+Farrell, et al.          Expires 4 October 2025                [Page 10]
 
 Internet-Draft           Well-Known URI for SVCB              April 2025
 
 
-   *  Origins can express any useful configuration that is representable
-      by HTTPS records, including multiple endpoints representing
-      different ports, providers, etc.
-
    *  Origins that simply alias to a single target can indicate this
       without copying the ECHConfig and other parameters, avoiding the
       maintenance burden of staying synchronized with the target's key
       rotations and configuration updates.
 
+   Note that there are multiple, and possibly confusing, port numbers
+   involved here.  The port that is part of the web origin in the .well-
+   known URL is part of the QNAME that will be used by clients in
+   accessing the origin's HTTPS/SVCB resource records.  The "port" field
+   in the RR value, and in the JSON structure, is the value to be used
+   in specifying an "alternative endpoint" as defined in section 1.3
+   [RFC9460].
+
 6.  Zone Factory behaviour
 
    If the ZF is unable to convert the JSON into a DNS zone fragment
@@ -551,17 +611,16 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
    A ZF SHOULD publish all the endpoints that are presented in the JSON
    file that pass the checks above.
 
-   A ZF SHOULD set a DNS TTL less than regeninterval, i.e. short enough
-   so that any cached DNS resource records are likely to have expired
-   before the JSON object's content is likely to have changed.  The ZF
-
 
 
-Farrell, et al.          Expires 4 October 2025                [Page 10]
+Farrell, et al.          Expires 4 October 2025                [Page 11]
 
 Internet-Draft           Well-Known URI for SVCB              April 2025
 
 
+   A ZF SHOULD set a DNS TTL less than regeninterval, i.e. short enough
+   so that any cached DNS resource records are likely to have expired
+   before the JSON object's content is likely to have changed.  The ZF
    MUST attempt to refresh the JSON object and regenerate the zone
    before this time.  This aims to ensure that ECHConfig values are not
    used longer than intended by backend.
@@ -610,10 +669,7 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
 
 
 
-
-
-
-Farrell, et al.          Expires 4 October 2025                [Page 11]
+Farrell, et al.          Expires 4 October 2025                [Page 12]
 
 Internet-Draft           Well-Known URI for SVCB              April 2025
 
@@ -630,11 +686,6 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
       configuration, potentially resulting in an unexpected tracking
       vector.
 
-   The .well-known URI chosen here means that services running on
-   different ports of the same backend are trusting the service running
-   on the default port (443) for that backend to provide correct
-   endpoint information.
-
    As described, in mutlti-CDN and simlar scenarios, a ZF might only
    test ECH success against one of the CDNs unless the ZF can make use
    of the ipv4hints and/or ipv6hint values, or the ZF has out of band
@@ -669,7 +720,12 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
 
 
 
-Farrell, et al.          Expires 4 October 2025                [Page 12]
+
+
+
+
+
+Farrell, et al.          Expires 4 October 2025                [Page 13]
 
 Internet-Draft           Well-Known URI for SVCB              April 2025
 
@@ -725,7 +781,7 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
 
 
 
-Farrell, et al.          Expires 4 October 2025                [Page 13]
+Farrell, et al.          Expires 4 October 2025                [Page 14]
 
 Internet-Draft           Well-Known URI for SVCB              April 2025
 
@@ -781,7 +837,7 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
 
 
 
-Farrell, et al.          Expires 4 October 2025                [Page 14]
+Farrell, et al.          Expires 4 October 2025                [Page 15]
 
 Internet-Draft           Well-Known URI for SVCB              April 2025
 
@@ -837,7 +893,7 @@ Appendix A.  Change Log
 
 
 
-Farrell, et al.          Expires 4 October 2025                [Page 15]
+Farrell, et al.          Expires 4 October 2025                [Page 16]
 
 Internet-Draft           Well-Known URI for SVCB              April 2025
 
@@ -849,7 +905,12 @@ Internet-Draft           Well-Known URI for SVCB              April 2025
    Version 06 changed the name and some of the text because it is no
    longer ECH-specific.
 
-   Version 07 has editorial changes and clarifications.
+   Version 07 clarifies that origins only speak for themselves and has
+   editorial changes and clarifications.
+
+Appendix B.  Examples
+
+   TBD - add some examples with names, JSON etc. and brief explanations.
 
 Authors' Addresses
 
@@ -888,9 +949,4 @@ Authors' Addresses
 
 
 
-
-
-
-
-
-Farrell, et al.          Expires 4 October 2025                [Page 16]
+Farrell, et al.          Expires 4 October 2025                [Page 17]
diff --git a/draft-ietf-tls-wkech.xml b/draft-ietf-tls-wkech.xml
index 0419639..854c4ff 100644
--- a/draft-ietf-tls-wkech.xml
+++ b/draft-ietf-tls-wkech.xml
@@ -230,28 +230,36 @@ Client <----------->|                    | facing
 
         </section>
 
-        <section title="Split-mode, multi-CDN deplpoyment.">
+        <section title="Split-mode deployment.">
 	  <t>
           The following diagram, and this entire section, is a place-holder just
           to have something on which to base discussion, and will change.</t>
-<figure title="Shared-Mode Topology with Zone Factory and DNS" anchor="split-mode"><artwork><![CDATA[
+
+        <t>
+            In this section, we describe one possible way in which ECH
+            split-mode could be deployed and make use of this .well-known
+            scheme. There are of course various other deployment options that
+            might be more effective.
+        </t>
+
+<figure title="Split-Mode Topology with Zone Factory and DNS" anchor="split-mode"><artwork><![CDATA[
 
                     +--------------------+
                     |        REAL        |
                     | backend.example.com|
                     |                    |
                     +--------------------+
-                        ^^           ^^
-                        ||    VPN    ||
-                        VV           VV
-           +--------------------+ +--------------------+
-           |                    | |                    |
- TLS       |   2001:DB8::1111   | |   2001:DB8::FFFF   | Client-
-Client <-->|backend.example.com | | backend.example.com| facing
-           |  cfs.cdn1.example  | |  cfs.cdn2.example  | servers
-           +--------------------+ +--------------------+
+      (1) backend       ^^           ^^   (2) backend publishes
+          reads CFS'    ||    VPN    ||       backend's
+          .well-known   VV           VV       .well-known
+                    +--------------------+
+                    |                    |
+     TLS            |   2001:DB8::1111   |
+     Client <---->  |backend.example.com |
+                    |   cfs.lb.example   |
+                    +--------------------+
                         ^            ^
-     (1) ZF reads       |            |  (2) ZF checks
+     (3) ZF reads       |            |  (4) ZF checks
          .well-known    V            V      ECHConfig
                     +--------------------+
                     |                    |
@@ -259,7 +267,7 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     |                    |
                     +--------------------+
                               |
-                              | (3) ZF publishes new HTTPS RR
+                              | (5) ZF publishes new HTTPS RR
                               V
                     +--------------------+
                     |                    |
@@ -268,23 +276,54 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: but with the following differences:
+    <ol>
+        <li>
+            The client-facing server, (CFS), is a load-balancer and
+            only does ECH decryption. The load-balancer is
+            called cfs.lb.example.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.lb.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the CFS and via the VPN.
+        </li>
+        <li>
+            backend.example.com wants to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.lb.example/.well-known/origin-svcb
+        </li>
+        <li>
+            backend.example.com then publishes its chosen JSON
+            (presumably including the relevant ECH config information)
+            at https://backend.example.com/.well-known/origin-svcb
+            That resource is hosted on the "real" backend.example.com
+            machine.
+        </li>
+        <li>
+            The ZF attempts to connect to https://backend.example.com using
+            the generated HTTPS record(s), including the
+            relevant ECH values, and confirms that all is
+            working before updating the zone.
+        </li>
+    </ol>
+</t>
+
+<t>
+    Note that the in this example ZF does not necessarily know that ECH
+    split-mode is in use.
+</t>
+
 	 </section>
     </section>
 
@@ -781,5 +820,8 @@ Client <-->|backend.example.com | | backend.example.com| facing
       </t>
 
     </section>
+    <section title="Examples">
+        <t>TBD - add some examples with names, JSON etc. and brief explanations.</t>
+    </section>
   </back>
 </rfc>


Reviews:
user: login: richsalz
body: fine with me!
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-04-02T15:51:30Z
user: login: bemasc
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T19:05:05Z
user: login: sftcd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T20:34:15Z
user: login: sftcd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T20:37:35Z
user: login: sftcd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T20:38:04Z
user: login: sftcd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T20:39:09Z
user: login: sftcd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T20:40:23Z
user: login: sftcd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T20:41:34Z
user: login: bemasc
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T20:41:48Z
user: login: sftcd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T20:42:17Z
user: login: bemasc
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T20:42:22Z
user: login: sftcd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T20:58:18Z
user: login: sftcd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T20:59:14Z
user: login: sftcd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T21:00:05Z
user: login: sftcd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-02T21:06:00Z
user: login: bemasc
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-04-02T21:30:25Z

Review comments:
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: I don't think it makes sense to use the term "CDN" to describe ECH split-mode.  A split mode client-facing server cannot store or cache the content, so it is not really a "content distribution network".  I would call it a "load balancer", as it falls between the TCP-terminating and [TLS-terminating](https://aws.amazon.com/blogs/aws/new-tls-termination-for-network-load-balancers/) load balancer behaviors.
created_at: 2025-04-02T18:47:01Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: This is possible, if the CFS is also being used as a DDoS defense filter (for example) and offers straight TCP forwarding.  However, a pure ECH CFS would not necessarily have this capability, and the IP addresses of backend.example.com would point to the backend directly.

I think the latter configuration is probably easier to understand, overall.
created_at: 2025-04-02T18:50:03Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: ```suggestion
            accessible via the client-facing servers and via the VPN.
```
created_at: 2025-04-02T18:50:14Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: I think it might be clearer to actually show that JSON here.
created_at: 2025-04-02T18:51:13Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
+        </li>
+        <li>
+            backend.example.com then publishes it's chosen JSON
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: ```suggestion
            backend.example.com then publishes its chosen JSON
```
created_at: 2025-04-02T18:51:45Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
+        </li>
+        <li>
+            backend.example.com then publishes it's chosen JSON
+            (presumably including the relevant ECH config information)
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: Note that this is only* necessary if the backend's HTTPS record differs from the CFS's.  For example, this could be necessary if the CFS support HTTP/1.1, HTTP/2, and HTTP/3, but the backend only supports HTTP/1.1 and HTTP/2.

This could also be necessary if the HTTPS records are currently identical but could _become_ non-identical in the future (e.g. the backend worries that the CFS might add HTTP/3 support without warning...)

*In theory.  In practice, Safari and Firefox support AliasMode today but Chrome does not.
created_at: 2025-04-02T18:54:50Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: There are several hidden assumptions here:

1. The CFS operates its own HTTP origin on the split mode endpoint.
2. The CFS HTTP origin uses WKECH with a zone factory.
3. The CFS HTTP origin's configuration is suitable for reuse by the backends, which are _not_ this orign's zone factory.

This seems like a "reasonable" configuration to me, but none of it is guaranteed normatively.  I think we should either (1) drop this from the example, and simply note that the ECHConfig, supported transports, and other parameters must be communicated between the CFS and backend by private arrangement, or (2) normatively specify (at "MAY") the use of WKECH for communication between components of an HTTP forwarding chain, with appropriate modifications at each step (which is rather tricky, see #21).
created_at: 2025-04-02T19:03:29Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
+        </li>
+        <li>
+            backend.example.com then publishes it's chosen JSON
+            (presumably including the relevant ECH config information)
+            at https://backend.example.com/.well-known/origin-svcb
+            That resource is hosted on the "real" backend.example.com 
+            machine.
+        <li>
+            The ZF attempts to connect to the backend using the 
+            published IP address, using the relevant ECH values and confirms
+            that all is working.
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: ```suggestion
            The ZF attempts to connect to https://backend.example.com using the 
            generated HTTPS record(s), including the relevant ECH values, and confirms
            that all is working before updating the zone.
```
created_at: 2025-04-02T19:04:54Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
path: draft-ietf-tls-wkech.xml
user: login: sftcd
body: Sure, will change
created_at: 2025-04-02T20:34:15Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
path: draft-ietf-tls-wkech.xml
user: login: sftcd
body: If the IP address of backend.example.com is not the same as cds.example then the HTTPS RR for backend has to do the re-direction, right? That's also possible but a bit more complicated to explain I think. (And IIUC that kind of re-direct is not currently supported by browsers or has that changed?)

Also, the HTTPS RR re-direct case involves a different ASCII-art picture:-)
created_at: 2025-04-02T20:37:35Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
path: draft-ietf-tls-wkech.xml
user: login: sftcd
body: ack
created_at: 2025-04-02T20:38:04Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
path: draft-ietf-tls-wkech.xml
user: login: sftcd
body: Maybe, but the JSON hasn't really been introduced yet in the doc. How's about we add some examples in an appendix with that kind of detail later?
created_at: 2025-04-02T20:39:09Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
+        </li>
+        <li>
+            backend.example.com then publishes it's chosen JSON
+            (presumably including the relevant ECH config information)
path: draft-ietf-tls-wkech.xml
user: login: sftcd
body: yep to the above (didn't know FF has alias mode, must test:-)
created_at: 2025-04-02T20:40:23Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
path: draft-ietf-tls-wkech.xml
user: login: sftcd
body: yep, none of this is normative, this is to help us figure out what ought be normative and eventually to help introduce the reader to that.

I'll add a bit of "this isn't normative" text
created_at: 2025-04-02T20:41:34Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: I think this whole section is examples, which should go _after_ the specification for that reason.
created_at: 2025-04-02T20:41:48Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
+        </li>
+        <li>
+            backend.example.com then publishes it's chosen JSON
+            (presumably including the relevant ECH config information)
+            at https://backend.example.com/.well-known/origin-svcb
+            That resource is hosted on the "real" backend.example.com 
+            machine.
+        <li>
+            The ZF attempts to connect to the backend using the 
+            published IP address, using the relevant ECH values and confirms
+            that all is working.
path: draft-ietf-tls-wkech.xml
user: login: sftcd
body: sure
created_at: 2025-04-02T20:42:17Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: Yes, it would work in Safari and Firefox today but not Chrome.

I'm OK with keeping this example, but then we need some more text to explain what is going on.
created_at: 2025-04-02T20:42:22Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
+        </li>
+        <li>
+            backend.example.com then publishes it's chosen JSON
path: draft-ietf-tls-wkech.xml
user: login: sftcd
body: yup
created_at: 2025-04-02T20:58:18Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
path: draft-ietf-tls-wkech.xml
user: login: sftcd
body: see if what I added is enough, no probs adding more caveats but not sure we wanna try explain too much at this point in the doc
created_at: 2025-04-02T20:59:14Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
path: draft-ietf-tls-wkech.xml
user: login: sftcd
body: this section is examples:-) motivating ones and comes before the spec (for now anyway)
created_at: 2025-04-02T21:00:05Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
+        </li>
+        <li>
+            backend.example.com then publishes it's chosen JSON
+            (presumably including the relevant ECH config information)
path: draft-ietf-tls-wkech.xml
user: login: sftcd
body: I tried FF nightly with https://alias.esni.defo.ie and it doesn't work. Might well be the DNS setup I guess - that's the 1st time I've checked that with a browser.
created_at: 2025-04-02T21:05:59Z
author_association: COLLABORATOR
diff_hunk: @@ -268,23 +276,54 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: but with the following differences:
+    <ol>
+        <li>
+            The client-facing server, (CDS), is a load-balancer and
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: ```suggestion
            The client-facing server (CFS), is a load-balancer and
```
created_at: 2025-04-02T21:18:15Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
+        </li>
+        <li>
+            backend.example.com then publishes it's chosen JSON
+            (presumably including the relevant ECH config information)
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: Safari shows this:
<img width="528" alt="Screenshot 2025-04-02 at 5 26 40 PM" src="https://github.com/user-attachments/assets/5bb4c743-c9fb-459f-b1dd-4336f8b18031" />

created_at: 2025-04-02T21:27:01Z
author_association: COLLABORATOR
diff_hunk: @@ -259,23 +259,50 @@ Client <-->|backend.example.com | | backend.example.com| facing
                     +--------------------+
 ]]></artwork></figure>
 
-     <t>
-		In this topology, the overall process is as in the previous section,
-		but with the following differences:
-        <ol>
-           <li>There are two client-facing servers (in different CDNs) for the
-               one "REAL" backend server that hosts the actual web resources.</li>
-           <li>ECH split-mode is assumed to be supported by both CDNs.</li>
-           <li>The "REAL" backend.example.com content is hosted on some machine(s)
-               accessible from the client-facing servers via a VPN.</li>
-           <li>The ZF notes that backend.example.com has multiple AAAA RR values
-               published, so queries for the .well-known at each of those. In this
-               case the values received differ.</li>
-	       <li>The ZF next attempts to connect to each CFS using the relevant ECH values and confirms
-	           that they are all working. </li>
-           <li>Note tha the ZF is not aware that ECH split-mode is in use.</li>
-	    </ol>
-     </t>
+<t>
+    In this topology, the overall process is as in the previous section,
+    but with the following differences: 
+    <ol>
+        <li>ECH split-mode is supported by the CDN.</li>
+        <li>
+            The client-facing server, e.g. in a CDN, for the backend
+            server only does ECH decryption.
+        </li>
+        <li>
+            Traffic between the CFS and backend is protected using
+            some kind of VPN.
+        </li>
+        <li>
+            The A/AAAA values for backend.example.com and
+            cfs.cdn.example are the same.
+        </li>
+        <li>
+            backend.example.com content is hosted on some machine(s)
+            accessible via the client-facing servers and the via the VPN.
+        </li>
+        <li>
+            backend.example.com has to acquire the ECH config
+            information from the CFS by querying the CFS'
+            .well-known URL, in this case
+            https://cfs.cds.example/.well-known/origin-svcb
path: draft-ietf-tls-wkech.xml
user: login: bemasc
body: Personally, I don't see why the motivating examples are needed, but who has time to argue about it.
created_at: 2025-04-02T21:30:02Z
author_association: COLLABORATOR

PR comments:
user: login: sftcd
created_at: 2025-04-02T20:52:12Z
body: I pushed a version that tries to address the issues above. Ping if it's ok/needs work.
author_association: COLLABORATOR
user: login: sftcd
created_at: 2025-04-02T21:33:02Z
body: > Personally, I don't see why the motivating examples are needed, but who has time to argue about it.

I think it'll help us think about the more complicated examples. But yeah no point arguing much:-)
author_association: COLLABORATOR
user: login: sftcd
created_at: 2025-04-02T21:34:48Z
body: > Safari shows this:

Same in FF. I wonder if I've setup the DNS RRs right. Typically, I've done it wrong 1st time I try something new:-)

```
$ dig +short https alias.esni.defo.ie
0 cover.defo.ie.
$ dig +short https cover.defo.ie
1 . ipv4hint=213.108.108.101 ech=AED+DQA8rwAgACBiUpG+S72k5fpH69paFqChnsZHDxtKAwX+uDPHDVwOMwAEAAEAAQANY292ZXIuZGVmby5pZQAA ipv6hint=2a00:c6c0:0:116:5::10
```
author_association: COLLABORATOR