Re: [TLS] In support of encrypting SNI

[Watson Ladd <[e-mail]>]

On Thu, May 15, 2014 at 9:38 PM, Martin Rex <[e-mail]> wrote:
> 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).
>

There are proposals out there (DH channel, authentication through
signing shared key) that require the server to do two exponentiations,
at the cost of multiple round trips. That's more performant in CPU
time than RSA-2048, and doesn't involve DNS keys. (Yes, I'm aware most
people don't use ECDSA: but why moan about speed when you haven't
already used the fastest option there is?).

Furthermore, many of the proposed changes in TLS 1.3 reduce
complexity: one padding scheme instead of three, dramatically reduced
numbers of allowed flows, obviate the need for secure renegotiation by
fixing the underlying problem, eliminate ciphers whose security has
been called into question, remove some little-used certificate
options, and hopefully simplify administration even further.

If you want simplicity CurveCP can be implemented in ~1,00 lines of
C+100*140 characters of underlying crypto. It has similar security
properties to the handshakes were are discussing now, and much more
performance.

I share your concern about ubiquity in HTTP: that's being fixed with
opportunistic HTTPS/not popping up a great big warning sign for
self-signed certificates. I don't think protocol complexity is what's
holding back deployment today so much as the cost of certificates
(which DANE addresses) and the complexity and hassle of management of
keys.

Sincerely,
Watson Ladd

> -Martin
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin