Re: [TLS] In support of encrypting SNI

[[e-mail] (Martin Rex)]

Stephen Farrell wrote:
> 
> Say if the client sent "hash-algId,H(tolower(SNI)||stuff)"
> or similar rather than sending just "SNI" (where "stuff"
> is maybe something to distinguish http vs imap perhaps).

The underlying idea is in principle correct:
if the client does not want to disclose the server's hostname, then the
client plain and simple MUST NOT send that hostname in TLS extension SNI.

It is conceivable that the client could send something else instead,
that the server could use for dispatching the TLS session to the
correct virtual host (independent of whether that is physicial or
logical routing of the TLS session).


> 
> And of course if we had a structure like "f-algId,f(SNI)"
> then other algs (e.g. encrypt with public key from DNS)
> could be added later if we can't use 'em now, so even
> adding this minimal bit of "protection" might provide
> the right hooks for later, better work.

While something like publishing an RSA public key in DNS and
using an encryption transform with random padding (PKCS#1 BT02 or OAEP)
could provide the functionality, this would also significantly
increase the server's workload (make TLSv1.3 session resumes as
expensive as TLSv1.2 static RSA full handshakes) and make the
key management (the rollover) a magnitude more difficult from
what it is now (not counting the accompanying code complexity).


If the whole SNI-hiding scheme would depend on the necessary key being
available in the DNS, then those servers that have only a single
server credential or that need high performance could avoid the
entire bloat, and that would be the most important aspect of this.


Personally, I consider pretty much all of the ideas that have been
floated so far, to be magnitudes of complexity beyond what I could
risk shipping to our customers from the usability viewpoint.
TLS key management is already the number one support issue today,
and the first customers started suffering from server load when
moving from RSA-1024 to RSA-2048 (even for static RSA key exchanges)
when there were problems with TLS session caching on TLS clients.


For our current TLS implementation, I can update&replace the server
credential (key,cert and cert chain) as well as trust anchors for
the verification of client certs in "full flight" (i.e. zero downtime),
but for multiple server keys distributed through different protocols
(DNS OOB plus TLS inband), I can not even conceive a robust / zero
downtime key management and key rollover.



Actually, I'm much more worried about the services on the internet
today that still do not use TLS at all (many discussion forums,
online shops and places like ebay), and I have exactly
ZERO problem doing online banking over TLS with static-RSA and RC4-128
or TLSv1.0 and CBC.


And I'm somewhat worried that making TLS more complex, administration
more difficult, troubleshooting harder and performance impact worse
is going to further deter adoption of TLS by the large unwashed masses
of today's HTTP-in-the-clear usage scenarios, similar to how feature bloat,
complexity, and poor usability still deters deployment of IPv6 today.


-Martin