On Fri, Aug 28, 2015 at 04:27:28PM +0200, Viktor S. Wold Eide wrote:
> > I don't think this matches most TLS use cases very well, since the client
> > generally isn't authenticated at all, so there's no point in the server
> > progressively
> > revealing more.
> >
> >
> Although the client generally is not authenticated currently, TLS 1.3 and
> DTLS 1.3 are likely to stay for a long time and then to be used for lots of
> different use cases, including more peer-to-peer interaction. For some
> use-cases, including peer-to-peer interaction, being able to progressively
> reveal more information would improve protection. Whether this is a
> worthwhile tradeoff or not, depends on many different factors. I think it
> is both relevant and interesting to see to what extent (D)TLS 1.3 would
> support such use cases.
It seems that with TLS 1.3 the client MUST send SNI, presumably in
the clear. Typically there's not much else of interest in the
server certificate to hide. I don't see a realistic way to hide
the server identity even from passive wiretap via TLS.
Encryption of the TCP layer, plus TLS channel-binding (or
super-encryption) might be necessary to limit the metadata leakage
to just the transport layer endpoint addresses. With IPsec the
leakage is just the network layer addresses.
Is anyone looking into leveraging TCPinc (when available) in TLS?
Extract channel-binding data from the socket, authenticate it with
TLS, and perhaps use TLS with NULL ciphers and if possible a
simplified handshake...
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
