search

sftcd / wkesni

A well-known URI for publishing ESNIKeys
7 stars 2 forks source link

Is this ECH-specific anymore? #14

Closed davidben closed 1 month ago

davidben commented 9 months ago

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 commented 4 months ago

@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 commented 4 months ago

I was imagining extensibility as follows:

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 commented 3 months ago

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

richsalz commented 3 months ago

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

richsalz commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.