Update spec to include changes to the echcheck test

data-formats/df-006-tlshandshake.md

@@ -32,6 +32,7 @@ code. See this directory's [README](README.md) for the basic concepts.
     "no_tls_verify": false,
     "peer_certificates": [],
     "server_name": "example.com",
+    "echconfig": "",
     "t0": 1.001,
     "t": 1.11,
     "tags": [],
@@ -73,6 +74,14 @@ to verify the server's X.509 certificate. Note that, when this field contains an
 address rather than a domain name, the corresponding value is not included in the TLS
 ClientHello as described by [RFC 6066, Section 3](https://datatracker.ietf.org/doc/html/rfc6066#section-3);
 
+- `outer_server_name`: (`string`; optional): server name used in the OuterClientHello when [TLS ECH](https://www.ietf.org/archive/id/draft-ietf-tls-esni-22.html) is being used. When this is set, the `server_name` field indicates the field used inside of the encrypted client hello.
+
+- `echconfig`: (`string`; optional): echconfig as defined in [TLS ECH
+  Spec](https://www.ietf.org/archive/id/draft-ietf-tls-esni-22.html#name-encrypted-clienthello-confi)
+base64 encoded as it would be presented inside of an SVCB HTTPS SvcParam as per
+[RFC9460](https://www.rfc-editor.org/rfc/rfc9460.html). In the event that only
+[GREASEd ECH](https://www.ietf.org/archive/id/draft-ietf-tls-esni-22.html#name-grease-psk) is being used, it will contain the string litteral `GREASE`.
+
 - `t0` (`float`): number of seconds elapsed since `measurement_start_time`
 measured in the moment in which we started the operation (`t - t0` gives you
 the amount of time spent performing the operation);

nettests/ts-039-echcheck.md

@@ -29,9 +29,14 @@ the `input`.
 # Test description
 
 Before performing the test, this experiment will resolve the given target URL
-and establish a TCP connection. It will then attempt two TLS handshakes - one
-with an ECH extension, and another control handshake without an ECH extension
-present.
+and establish a TCP connection. It will then attempt three TLS handshakes - one
+with an ECH extension and the `public_name` (see: [ECH spec](https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-22#section-6.1-6)) of the `echconfig` for the domain
+in the OuterClientHello, secondly ECH with a different `public_name` than that
+advertised in the `public_name` field, finally a control handshake without an
+ECH extension present.
+
+The SNI used inside of the OuterClientHello can be distinguished by looking at
+the value of `outer_client_hello`.
 
 This experiment does not actually encrypt the Client Hello, but instead
 attempts a GREASE’d (Generate Random Extensions And Sustain Extensibility) ECH
@@ -54,15 +59,19 @@ We will include data following these data formats:
 ```JSON
 {
     "test_keys": {
-        "control": {},
-        "target": {}
+        "tls_handshakes": {},
     }
 }
 ```
 
-- `control` : follows the `df-006-tlshandshake` data format
+- `tls_handshakes` : (since 0.2.0) follows the `df-006-tlshandshake` data format
+
+- `control` : (deprecated since: 0.2.0) follows the `df-006-tlshandshake` data format
+- `target` : (deprecated since: 0.2.0) follows the `df-006-tlshandshake` data format
 
-- `target` : follows the `df-006-tlshandshake` data format
+To distinguish between the tls handshake with ECH or without, you can look at
+the `echconfig` field of the `tls_handshakes` list and check if it's empty or
+not.
 
 ## Possible conclusions