Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Hubert Kario <[e-mail]>]

On Tuesday 01 December 2015 00:14:14 Jacob Appelbaum wrote:
> On 11/30/15, Hubert Kario <[e-mail]> wrote:
> > On Monday 30 November 2015 10:58:48 Bryan A Ford wrote:
> >> On 11/30/15 2:40 AM, Peter Gutmann wrote:
> >> > Nikos Mavrogiannopoulos <[e-mail]> writes:
> >> >> I believe your proposal is a nice example of putting the cart
> >> >> before the horse. Before proposing something it should be clear
> >> >> what do you want to protect from, what is the threat?
> >> > 
> >> > Exactly.  If you want to thwart traffic analysis, you need to do
> >> > something like what's done by designs like Aqua ("Towards
> >> > Efficient
> >> > Traffic-analysis Resistant Anonymity Networks"), or ideas from
> >> > any
> >> > of the other anti-traffic- analysis work that's emerged in the
> >> > past
> >> > decade or two.
> >> 
> >> I'm well aware of Aqua and "the other anti-traffic-analysis work
> >> that's emerged in the past decade or two": in fact I led one of the
> >> 
> >> major recent systematic projects in that space.  See for example:
> >> 	http://dedis.cs.yale.edu/dissent/
> >> 	http://cacm.acm.org/magazines/2015/10/192387-seeking-anonymity-in-> >> 	an->>> 
> >> internet-panopticon/fulltext
> >> 
> >> > You get traffic
> >> > analysis resistance by, for example, breaking data into
> >> > fixed-length
> >> > packets, using cover traffic, and messing with packet timings,
> >> > not
> >> > by
> >> > encrypting TLS headers.
> >> 
> >> Packet padding and header encryption are both important,
> >> complementary security measures: you get security benefits from
> >> each that you don't get from the other.  Yes, you need padding to
> >> obtain systematic protection from traffic analysis - when for
> >> whatever reason not all implementations are always padding to the
> >> exact same standardized record length, header encryption makes
> >> padded streams less trivially distinguishable from unpadded
> >> streams, and makes streams with different record sizes less
> >> trivially distinguishable from each other.
> > 
> > the header contains only one piece of information, and it is public
> > already - the amount of data transmitted*
> 
> I'm pretty sure TLS has a lot more data...

in TLS v1.3 no, it doesn't. All encrypted packets must have the 
plaintext record type set to Application Data[1], same for version - 
it's frozen now at 3.1 (TLS1.0)[2], both are used just as a magic value.

> > this goes well past the TLS WG charter, if only because it requires
> > very close cooperation with the application layer
> > 
> > so while the padding mechanism should be there, we really can't
> > describe how it needs to be used, as it can't be made universal nor
> > is it necessary for all use cases
> 
> I think it should be described how it needs to be used...

Yes, I misspoke. What I meant is that we can't mandate its use as it is 
an application layer issue. We definitely should describe how it needs 
to be used on TLS level.

> >  * - sure, the record layer boundaries can tell something about the
> >  data> 
> > being transmitted, but so can the presence of data transmission
> > taking place in the first place (think of a station sending reports
> > only when it detects something while keeping connection open the
> > whole time)
> Yes, they tell something and that something is better removed.

then we need Best Current Practice for applications describing to them 
how TLS needs to be used, e.g. make sure that they are doing writes as 
big as possible, checking if timing of responses doesn't leak much 
information, etc. Forcing TLS implementation to combine writes will 
easily cause serious problems with interactivity of sessions...

> >> One thing that would greatly help Tor and all similar,
> >> padded protocols is if they could "blend in" even just a little bit
> >> better with the vast bulk of ordinary TLS-encrypted Web traffic,
> >> and
> >> that's one of the big opportunities we're talking about here.
> > 
> > the initial message in handshake in TLS MUST stay the same thus it
> > is
> > impossible to make it look like Tor. Not to thwart the Pervasive
> > Monitoring threat of TLA agencies.
> 
> That Tor claim is strange and seemingly false in any case. Also, I've
> said it before quoting the RFC but I'll say it again: Pervasive
> Monitoring is an attack.

Not claiming it isn't. But some things (like compression) are best done 
at application layer, not TLS layer.
 
> >> If you think it is practical for the TLS 1.3 standard to specify a
> >> single, fixed record size that all implementations of TLS 1.3 must
> >> use (i.e., explicitly freeze not only the version field but the
> >> length field), then that would be great for traffic analysis
> >> protection and on that basis I would support that proposal.  But
> >> that frankly seems to me likely a bit too much to ask given the
> >> diversity of TLS implementations and use-cases.  Tell me if you
> >> believe otherwise.> 
> > That will just round up to a multiple of 256 bytes the data sizes
> > transmitted. Hardly an improvement over the current 16 byte blocks.
> 
> Closer to 512 bytes is better.

Either hardly helps if you're not transferring packets with null data to 
really hide the amount of data transferred.

 1 - https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-5.2.2
   opaque_type
      The outer opaque_type field of a TLSCiphertext record is always
      set to the value 23 (application_data) for outward compatibility
      with middleboxes used to parsing previous versions of TLS.  The
      actual content type of the record is found in fragment.type after
      decryption.
 2 - https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-5.2.2
   record_version
      The record_version field is identical to
      TLSPlaintext.record_version and is always { 3, 1 }.  Note that the
      handshake protocol including the ClientHello and ServerHello
      messages authenticates the protocol version, so this value is
      redundant.

-- 
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