Re: [TLS] "Encrypted" SNI

[Hubert Kario <[e-mail]>]

On Thursday, 11 May 2017 16:31:26 CEST Brian Sniffen wrote:
> Daniel Kahn Gillmor <[e-mail]> writes:
> > On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
> >> It certainly was. But then the clear text SNI is a gaping privacy hole
> >> in TLS, the kind of issue that should keep us awake at night until it is
> >> resolved. We need to make sure that we make progress, rather than rehash
> >> the old arguments. Maybe we should invest some time and document the
> >> various proposals in a draft. I am willing to work on that. Any other
> >> volunteers?
> > 
> > I agree with Christian's assessment of the problem, and i'd be
> > interested in collaborating on such a draft.
> 
> Who's the audience for that draft?  If it's meant to document the blind
> alleys we've found, perhaps we could list both alleys, and the walls at
> the end:
> 
>   - hash the name [adversaries can hash too]
>   - hash the name with a salt [adversaries can check the salted hash
>     too, as if operating all the banned sites]
>   - encrypt the SNI under the pre-shared key
> 
> But beware of:
> 
>   - the adversary can replay this SNI and see what site he gets
>   - DDoS risk: servers can't be try lots of crypto (no asymmetric ops,
>     no operations that scale linearly with number of sites hosted)

Doesn't that create a Catch 22?

I need to get the key to encrypt the SNI. But if we don't want the names to 
leak, how do I authenticate the key without telling the server what 
certificate I will accept to authenticate the key?

That doesn't look to me like a problem we can solve with typical symmetric or 
asymmetric crypto - it looks to me like more of a zero-knowledge proof issue.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic