Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

[Hubert Kario <[e-mail]>]

On Tuesday, 15 August 2017 18:27:27 CEST Colm MacCárthaigh wrote:
> On Tue, Aug 15, 2017 at 1:55 PM, Hubert Kario <[e-mail]> wrote:
> > On Tuesday, 15 August 2017 00:55:50 CEST Colm MacCárthaigh wrote:
> >> On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario <[e-mail]> wrote:
> >> ... and even today with very low
> >> latency networks and I/O schedulers it remains very difficult to
> >> measure that kind of timing difference remotely.
> > 
> > simply not true[1], you can measure the times to arbitrary precision with
> > any real world network connection, it will just take more tries, not
> > infinite tries
> 
> Surely the Nyquist limits apply? The fundamental resolution of
> networks is finite. Clock cycles are measured in partial billionths of
> a second, but even 10Gbit/sec networks use framing (85 byte minimum)
> in a way that gives you a resolution of around 70 billionths of a
> second. Nyquist says that to measure a signal you need a sampling
> resolution twice that of the signal itself ... that's about 2 orders
> of magnitude of distance to cover in this case.

Nyquist applies to a single sample, not to multiple sampling of the same 
signal.

In other words, if I sample a signal 4 times, and once I get 0 and 3 times I 
get 1, then assuming uniform distribution[1] I can deduce that the signal is 
closer to 0.75 than it is to 1, 0 or 0.5.

 1 - yes, it's a "spherical cow in a vacuum" example

> >> But per the post, the
> >> larger point is that it is prudent to be cautious.
> > 
> > exactly, unless you can show that the difference is not measurable, under
> > all conditions, you have to assume that it is.
> > 
> >> > When you are careful on the application level (which is fairly simple
> >> > when
> >> > you just are sending acknowledgement message), the timing will still be
> >> > leaked.
> >> 
> >> There are application-level and tls-implementation-level approaches
> >> that can prevent the network timing leak. The easiest is to only write
> >> TLS records during fixed period slots.
> > 
> > sure it is, it also limits available bandwidth and it will always use that
> > amount of bandwidth, something which is not always needed
> 
> Constant-time schemes work by taking the maximum amount of time in
> every case. This fundamentally reduces the throughput; because small
> payloads don't get a speed benefit.

My point is that if I don't care about the side channel of presence or absence 
of the communication, then I am limited by the size of the maximal record, not 
amount of records I can send in a second. So my bandwidth is limited in 
"Transaction Per Second" sense, not actual bandwidth (measured in bytes per 
second)
 
> > we are not concerned if the issue can be workarouded, we want to be sure
> > that the TLS stack does not undermine application stack work towards
> > constant time behaviour
> 
> The TLS stack can take a constant amount of time to encrypt/decrypt a
> record, regardless of padding length, but it's very difficult to see
> how it can pass data to/from the application in constant time; besides
> the approach I outlined, which you don't like.

As I said in a different email, in C you pass a pointer and length, that can 
be returned in constant time quite easily (even in read(3)-like API).

encryption is indeed much harder

> Note that these problems get harder with larger amounts of padding.
> Today the lack of padding makes passive traffic analysis attacks very
> easy. It's extremely feasible for an attacker to categorize request
> and content lengths (e.g. every page on Wikipedia) and figure out what
> page is user is browsing. That's a practical attack, that definitely
> works, today, and it's probably the most practical and most serious
> attack that we do know works. The fix for that attack is padding, and
> quite large amounts are needed to defeat traffic analysis. But that
> will make the timing challenges harder. In that context: it's
> important to remember; so far those timing attacks have not been
> practical. We don't want to optimize for the wrong problem.

True, that being said, I'd prefer if we did release protocol in which we can't 
poke holes before the official release...
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic