Is this ECH-specific anymore?

[davidben]

It looks like this is really an HTTPS/SVCB provisioning mechanism, not just ECH, but the title talks about ECH. E.g. draft-davidben-tls-key-share-prediction could also benefit from some kind of automatic server -> DNS pipeline.

Should the document be re-titled?

[richsalz]

@davidben raised an important issue on the list: https://mailarchive.ietf.org/arch/msg/tls/pSJEXscoGr1Y1Au48QdkJvxvNtc/

Assuming we can resolve the extension model (I currently have no opinions) I am in favor of doing this.

[bemasc]

I was imagining extensibility as follows:

• SvcParamKeys are mapped automatically (no opt-in)
• Keys are strings
• Value-lists are JSON Arrays.
• Values are represented by their 8-bit-clean presentation values via isomorphic decoding.
• Generic keys ("key65535") are allowed just like in the DNS zone file format.

This is a generic mechanism, but the keys where this would be particularly useful are "ech", "alpn", and this new keyshare thing, all of which are TLS-related, we could retitle it something like "TLS Parameter Updates for DNS Service Bindings".

[sftcd]

even though we've merged #20 probably good to leave this issue open to tee up discussion at IETF-120

[richsalz]

I think the only point now remaining is what the new title should be?

[richsalz]

Comments from ilari and that same thread https://mailarchive.ietf.org/arch/msg/tls/_tdKF8dKnH448oyoMVtzPU3hPmk/

It seems to me that SvcParamKey's can be divided into three groups:

1. Properties of the server that don't affect protocol.

E.g., ech, tls-supported-groups, no-default-alpn

These should be picked by the DNS frontend.

2. Properites related to location of the server.

E.g., port, ipv4hint, ipv6hint

These should not be picked by the DNS frontend, but instead should be
set by the DNS frontend configuration (or at least specify how to set
these).

3. Gateway-special properties

E.g., alpn

These would initially seem to be server properties. However, these can
affect the protocol used (e.g., h2 and h3 are very different), so in
some situations, DNS frontend needs to handle it specially.

One such situation is if the server is gatewayed. In such situation,
the DNS frontend needs to drop all the alpn values not supported in the
gateway (especially h3 needs to be dropped).

Servers can also be gatewayed in IPv4 but direct in IPv6. In that
situation, the DNS fronted needs to duplicate the records, with IPv4
side having filtered alpn values and IPv6 side having all the alpn
values.

There seems to be no guarantees about which category future SvcParamKeys
fall into. While the second group just should not be specified at all,
a new parameter in the third group could cause problems, as not
filtering those correctly can cause breakage.

[davidben]

Yeah, I expect there'll be a lot more to sort out here. I don't have a coherent proposal here, just a half-formed thought, but I've been musing on whether maybe the right design is for the DNS frontend to be configured with the list of SvcParams it wishes to delegate to the serving frontend, so you get an allowlist at that layer? Not sure how necessary that is (is there actually a trust boundary to be concerned with here?), but could be a direction to explore. Presumably some configuration would already be needed to turn this overall thing on.

Then again, explicit configuration also increases the server operator burden when new things are introduced. It's one more thing you have to get right when deploying whatever new TLS ideas we have. It's nice when you have a class of things that are defined to have comparable properties so that this delegation can be done once.

[bemasc]

It sounds like this thread is about the "configuration fusion" problem, combining information from the various intermediaries into a single HTTPS record. The issue for that is #21.

[sftcd]

so I think the ietf-120 session answered the question - this isn't ECH-specific really, so we should change the name, but we'll try plough ahead with the document as-is and see if anyone wants to add text on things other than ECH that could be managed this way. I think that means we can close this. I've opened #35 for the name thing.