I'm struggling to understand the issue you're raising. There's typically nothing special about the CDN to origin TLS interaction. If the origin supports ESNI, why couldn't it advertise that? The CDN node could just pick it up like any other TLS client would.*
The one way in which CDN to origin interactions may differ greatly from client to origin interactions is the aggregation of many sessions to the same origin inside the same connection, but this is at the application layer. This aggregation may improve privacy by decoupling incoming traffic from upstream requests through persistent connections and/or pre-cached content. Can you more precisely define your concern? Kyle *Not clear that it would be helpful, since the origin is probably obvious from the destination IP, but I think the whole ESNI discussion presumes traffic analysis is either hopelessly naïve or impossible, so I'll just stipulate that and proceed from there. On Wed, Oct 9, 2019, 7:55 AM Rob Sayre <say...@gmail.com> wrote: > On Wed, Oct 9, 2019 at 6:51 PM Salz, Rich <rs...@akamai.com> wrote: > >> >> - A link from CDN to Origin is just a particularly easy-to-deploy use >> case, since client certificates are already in wide use and IPv6 tends to >> work flawlessly. >> >> >> >> It does? Gee, cool. >> > > This response sounds like anger. I'm sorry I've caused you to feel angry. > > It might be best to discuss technical concerns. Do you think an SNI field > sent with a client certificate is a bad idea? I'm not a cryptographer, so I > thought I would suggest the approach and see what people thought. > > thanks, > Rob > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
