I struggle a bit to understand how this thread is related to the SNI Encryption Requirements document. Rob, you raise the question of using and possibly hiding the SNI when using TLS to protect communication between servers. That's a fine debate, but I don't see how this specific usage of TLS and SNI affects the draft or change the requirements on SNI encryption mechanics. We also have an interesting process issue, because this draft already went through WG last call, IETF last call, and IESG review. At this stage, it would take a huge issue to stop the presses and rework the document.
-- Christian Huitema On 10/9/2019 7:20 AM, Rob Sayre wrote: > > > On Wed, Oct 9, 2019 at 9:17 PM Paul Yang <kaishen...@alipay.com > <mailto:kaishen...@alipay.com>> wrote: > > > >> On Oct 9, 2019, at 9:46 PM, Rob Sayre <say...@gmail.com >> <mailto:say...@gmail.com>> wrote: >> >> On Wed, Oct 9, 2019 at 8:43 PM Paul Yang <kaishen...@alipay.com >> <mailto:kaishen...@alipay.com>> wrote: >> >> >> From my understandings, either IPv4 or IPv6 should have >> nothing to do with the concept “virtual host” >> >> >> Hi Paul, >> >> That is correct. However, the scarcity of IPv4 addresses is one >> major factor driving the need for virtual hosts. > > Yes, that’s right. So even IPv6 addresses are enormous enough to > hold every domain name, we still can’t assume it’s all used in > this way in practice. An administrator can always configure the > origin server as hosting multiple domain names on one IPv6 > address. It may not be very reasonable for doing so, but it could > be done in that way. Actually popular web servers as NGINX > supports such kind of configurations, for instance. > > For TLS protocol, when being used between an IPv6 CDN node and an > origin server, the SNI still need to be present in ClientHello to > address the above circumstance; otherwise, the IPv6 origin may > fail to choose the right host/certificate to finish the handshake. > > > Hello, > > I agree that it needs to be possible to include the SNI in > ClientHello, but not required. > > 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
