On Thu, May 11, 2017 at 08:01:58PM +0200, Hubert Kario wrote:
> > 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.
No zero-knowledge schemes come to mind that are suitable to this task.
What can work, but costs latency is to do anon-(EC)DH key agreement
first, and only *then* exchange certificates under the established
keys and sign the session transcripts as required. That is enable
encryption first, and authentication second, with SNI sent after
you have an unauthenticated encrypted channel.
Yes, an active MiTM attack could capture the SNI, but it would
prevent full session establishment, and so would be tamper-evident.
(One might imagine that initial opportunistic crypto being TCPinc,
with channel bindings extracted into a light-weight authentication
protocol on top, that no longer needs to do the key agreement bits).
The TLS 1.3 draft protocol, while eschewing weaker crypto primitives,
seems optimized more for lower-latency than for greater resistance
to traffic analysis. I don't think that you can have both.
To really address the issue, one needs a more complete architecture,
that combines all the relevant bits of TCP, TLS and HTTP, ....
Such holistic (r)evolution is extremely difficult.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
