From 763299aba72e6c116fafd33282274a9ce0206b7c Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Tue, 4 Jun 2024 15:06:40 -0400 Subject: [PATCH] Add an example encoding, for both presentation and wire formats Fixes #8. --- draft-ietf-tls-key-share-prediction.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/draft-ietf-tls-key-share-prediction.md b/draft-ietf-tls-key-share-prediction.md index f096c84..e734a81 100644 --- a/draft-ietf-tls-key-share-prediction.md +++ b/draft-ietf-tls-key-share-prediction.md @@ -68,6 +68,8 @@ The presentation `value` of the SvcParamValue is a comma-separated list ({{Appen The wire format of the SvcParamValue is a sequence of 2-octet numeric values in network byte order. An empty list of values is invalid. +For example, a TLS server which prefers `x25519` (29) and also supports `secp256r1` (23) would a `tls-supported-groups` SvcParamValue containing 29 and 23. The presentation `value` would be "29,23". The wire format of the SvcParamValue would be four octets, represented in hexadecimal as `001d0017`. + ## Configuring Services Services SHOULD include supported TLS named groups, in order of decreasing preference in the `tls-supported-groups` parameter of their HTTPS or SVCB endpoints. As TLS preferences are updated, services SHOULD update the DNS record to match. Services MAY include GREASE values {{!RFC8701}} in this list.