Thanks, Benoit
[hope it's ok. to cross-port and redirect replies to TLS]
I have not followed TLS 1.3 in detail, so a quick question first:
Will TLS 1.3 still permit servers to send their certificate and/or SNI in the
clear as an option or
will it force server operators to encrypt either/or ? If it does not permit
server applications
to indicate what to encrypt, then i would really love to know which shared
web-hosters did
explicitly express support for TLS 1.3.
Use case: (i can't believe this hasn't been discussed _forever_, but i do not
subscribe to TLS...)
Operators of "client-side" networks want to be able to enforce policies which
"web-services"
their clients can communicate with. As soon as the IP address used to host a
web-service runs
multiple web-services (domain-names), this is today done by inspecting the TLS
1.2 server certificate
or SNI.
Web hosters whose services do share IP addresses across domain name should be
very interested to
ensure such inspection works, because else a single misbehaving web-service
they host will easily
cause all their web-services to be blacklisted by any of the varied
organizations that create
blacklists: because blacklisting can then only be applied on a per-IP address.
Of course, IPv6 could make this need somewhat obsolete because there should be
no reason to
share IPv6 addresses across domain-names, but i am not aware what todays common
practice are with IPv6
in this respect.
Cheers
Toerless
On Thu, Jun 01, 2017 at 04:38:46PM +0200, Benoit Claise wrote:
> Dear all,
>
> You should be aware that the TLS list is debating encrypting SNI so
> that the host name cannot be seen from TLS sessions.
> https://www.ietf.org/mail-archive/web/tls/current/msg23251.htm
>
> If you're aware of valid (valid in the IETF-sense) operational
> practices that require the host name visible, we should enter the
> debate.
>
> Regards, Benoit
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
