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

[Hubert Kario]

On Tuesday, 15 August 2017 17:28:22 CEST Eric Rescorla wrote:
> I generally agree with Ilari. To recap what I said on the PR:
> I think it would be fine to sharpen the point about padding leaking
> information and I'd take a short PR for that.

I've prepared https://github.com/tlswg/tls13-spec/pull/1074 with that in mind.

> I don't believe it's
> necessary either to require that it be constant time (for the reasons I
> indicated on-list and already documented in the spec) or to describe a
> specific algorithm, especially at this point on the document life cycle.
> 
> -Ekr
> 
> 
> 
> On Tue, Aug 15, 2017 at 6:54 AM, Ilari Liusvaara 
> 
> wrote:
> > On Tue, Aug 15, 2017 at 03:31:56PM +0200, Hubert Kario wrote:
> > > I've created a Pull Request that introduces requirement for constant
> > > time
> > > processing of padding and an example on how to do it:
> > > 
> > > https://github.com/tlswg/tls13-spec/pull/1073
> > 
> > -1
> > 
> > Except doing the depad in constant-time is useless if you just re-
> > introduce the timing leaks at the next step. Actually not introducing
> > timing leaks in TLS library requires special API for passing the data
> > to application... API that has had no reason to exist so far, and is
> > more complicated to use than current read or zerocopy callback APIs.
> > 
> > And even if you have such special API, it is extremely doubtful how
> > many applications could use it correctly. Constant-time processing of
> > variable-length data is extremely hard (LUCKY13 anyone?)
> > 
> > Oh, and then there are timing leaks when sending data too...
> > 
> > 
> > -Ilari
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] OCSP status_request_v2 extension

[Benjamin Kaduk]

On 08/14/2017 01:26 PM, Ilari Liusvaara wrote:
> On Mon, Aug 14, 2017 at 08:03:08PM +0200, Hubert Kario wrote:
>> Current (21) draft references RFC 6961 in multiple places, in particular
>>  * Section 4.4.2:
>>  Valid extensions
>>  include OCSP Status extensions ([RFC6066] and [RFC6961])
>>  * and therein implicitly:
>>  If
>>  an extension applies to the entire chain, it SHOULD be included in
>>  the first CertificateEntry.
>>
>> at the same time section B.3.1 ExtensionType and table from Section 4.2 do 
>> not 
>> list status_request_v2 as a valid extension.
>>
>>
>> If the intention was to deprecate status_request_v2, I think the references 
>> to 
>> RFC 6961 should be a bit more cautious. If it wasn't (as old messages sent 
>> to 
>> the list would indicate), quite a bit of text is missing.
> The introduction suggests that TLS 1.3 intends to deprecate
> status_request_v2.
>

Yes, the intention was to deprecate status_request_v2.

-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hubert Kario]

On Tuesday, 15 August 2017 18:27:27 CEST Colm MacCárthaigh wrote:
> On Tue, Aug 15, 2017 at 1:55 PM, Hubert Kario  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  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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Tue, Aug 15, 2017 at 1:55 PM, Hubert Kario  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  wrote:
>> > the difference in processing that is equal to just few clock cycles is
>> > detectable over network[1]
>>
>> The post you reference actually says the opposite; "20 CPU cycles is
>> probably too small to exploit"
>
> exactly what we though about cbc padding at the time TLS 1.1 was published...

I'm not going to defend the poor design of TLS1.1 padding, but it does
remain unexploitable over real-world networks. The Lucky13 attack that
you reference is practical against DTLS, but not TLS. It is worth
understanding the nuance, because the differences can help us continue
to make TLS more robust and hint where to optimize. The property that
has protected has TLS Vs DTLS is non-replayability, so it's important
we keep that.

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

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

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

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.

-- 
Colm

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

I generally agree with Ilari. To recap what I said on the PR:
I think it would be fine to sharpen the point about padding leaking
information and I'd take a short PR for that. I don't believe it's
necessary either to require that it be constant time (for the reasons I
indicated on-list and already documented in the spec) or to describe a
specific algorithm, especially at this point on the document life cycle.

-Ekr



On Tue, Aug 15, 2017 at 6:54 AM, Ilari Liusvaara 
wrote:

> On Tue, Aug 15, 2017 at 03:31:56PM +0200, Hubert Kario wrote:
> > I've created a Pull Request that introduces requirement for constant time
> > processing of padding and an example on how to do it:
> >
> > https://github.com/tlswg/tls13-spec/pull/1073
>
> -1
>
> Except doing the depad in constant-time is useless if you just re-
> introduce the timing leaks at the next step. Actually not introducing
> timing leaks in TLS library requires special API for passing the data
> to application... API that has had no reason to exist so far, and is
> more complicated to use than current read or zerocopy callback APIs.
>
> And even if you have such special API, it is extremely doubtful how
> many applications could use it correctly. Constant-time processing of
> variable-length data is extremely hard (LUCKY13 anyone?)
>
> Oh, and then there are timing leaks when sending data too...
>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hubert Kario]

On Tuesday, 15 August 2017 15:54:15 CEST Ilari Liusvaara wrote:
> On Tue, Aug 15, 2017 at 03:31:56PM +0200, Hubert Kario wrote:
> > I've created a Pull Request that introduces requirement for constant time
> > processing of padding and an example on how to do it:
> > 
> > https://github.com/tlswg/tls13-spec/pull/1073
> 
> -1
> 
> Except doing the depad in constant-time is useless if you just re-
> introduce the timing leaks at the next step. Actually not introducing
> timing leaks in TLS library requires special API for passing the data
> to application...

In C you pass data to application using pointer to memory location and a 
length variable. Padding influences only the length variable value. How 
exactly can you do that in _non_ constant time?

> API that has had no reason to exist so far, and is
> more complicated to use than current read or zerocopy callback APIs.

with current read(3), you require the application to provide a buffer the size 
of the whole padded data, you copy the whole padded data, you return a length 
that truncates the content type and padding.

I fail to see how is that a "special API"

> And even if you have such special API, it is extremely doubtful how
> many applications could use it correctly. Constant-time processing of
> variable-length data is extremely hard (LUCKY13 anyone?)

right, so because it is hard, we should just throw our hands in the air and 
walk away?

The point is that, if possible, we shouldn't undermine the work of 
applications that *do* have constant-time processing of variable-length data.

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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Tue, Aug 15, 2017 at 03:31:56PM +0200, Hubert Kario wrote:
> I've created a Pull Request that introduces requirement for constant time 
> processing of padding and an example on how to do it:
> 
> https://github.com/tlswg/tls13-spec/pull/1073

-1

Except doing the depad in constant-time is useless if you just re-
introduce the timing leaks at the next step. Actually not introducing
timing leaks in TLS library requires special API for passing the data
to application... API that has had no reason to exist so far, and is
more complicated to use than current read or zerocopy callback APIs.

And even if you have such special API, it is extremely doubtful how
many applications could use it correctly. Constant-time processing of
variable-length data is extremely hard (LUCKY13 anyone?)

Oh, and then there are timing leaks when sending data too...


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hubert Kario]

I've created a Pull Request that introduces requirement for constant time 
processing of padding and an example on how to do it:

https://github.com/tlswg/tls13-spec/pull/1073

On Friday, 11 August 2017 16:11:10 CEST Nikos Mavrogiannopoulos wrote:
> Imagine the following scenario, where the server and client have this
> repeated communication N times per day:
> 
> client server
> --X-->
> <--Y--
> 
> 
> the client puts in X a message A of 1 byte or B of 1024 bytes, and pads
> it to the maximum size of TLS record. The server replies with the
> message "ok" (same every time), padded to the maximum size just after
> it reads X.
> 
> However, TLS 1.3 detects the message size by iterating through all the
> padding bytes, and thus there is a timing leak observed by the time
> difference between receiving X and sending Y. Thus as an adversary I
> could take enough measurements and be able to distinguish between X
> having the value A or B.
> 
> While I'd expect these iterations to be unmeasurable in desktop or
> server hardware, I am not sure about the situation in low-end IoT
> hardware. Is the design choice for having the padding removal depending
> on padding length intentional?
> 
> There is mentioning of possible timing channels in:
> https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix-E.3
> However I don't quite understand how is this section intended to be
> read. The sentence for example: "Because the padding is encrypted
> alongside the actual content, an attacker cannot directly determine the
> length of the padding, but may be able to measure it indirectly by the
> use of timing channels exposed during record processing", what is its
> intention? Is it to acknowledge the above timing leak?
> 
> Shouldn't instead be guidance in section 'Implementation Pitfalls' on
> how to remove padding in a way that there are no timing leaks? (the
> timing leak here is not in crypto algorithms, but TLS itself). Ideally
> TLS 1.3 itself shouldn't use data-size depending calculations itself
> such as the one described here.
> 
> regards,
> Nikos
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hubert Kario]

On Tuesday, 15 August 2017 00:55:50 CEST Colm MacCárthaigh wrote:
> On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario  wrote:
> > the difference in processing that is equal to just few clock cycles is
> > detectable over network[1]
> 
> The post you reference actually says the opposite; "20 CPU cycles is
> probably too small to exploit"

exactly what we though about cbc padding at the time TLS 1.1 was published...

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

> 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

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

 1 - http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls