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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Fri, 2017-08-11 at 14:45 -0400, Daniel Kahn Gillmor wrote:
> On Fri 2017-08-11 18:43:15 +0200, Nikos Mavrogiannopoulos wrote:
> > I don't argue with this but this is not the approach TLS 1.3 took.
> > It
> > provides a generic padding mechanism to be used across application
> > protocols.
> 
> The design approach that TLS 1.3 took was to provide a mechanism for
> padding at the TLS layer, not to prescribe padding at the application
> layer.  You actually probably need both to defend against traffic
> analysis in the big picture.
> 
> Thoughtful, well-designed application-layer padding is likely to be
> better than generic TLS-layer padding.  But not all applications can
> actually accomodate padding (and it's not clear that folks have done
> the
> thoughtful work even on those applications which *can* accomodate
> padding).
> 
> TLS offers a generic mechanism to support the cases where the
> application can't do padding, or where the implementer has no control
> over (or insight into) the application itself.  It'll probably leak
> in
> the way you describe, but it'll probably also be better than
> cleartext.
> 
> Furthermore, there are TLS messages that are not application data at
> all -- so those parts *have* to be padded at the TLS layer, as the
> application cannot directly affect their size.
> 
> A robust and safe padding approach needs to take into account all
> layers
> of the stack at once and coordinate between them.  Without the
> padding
> mechanism in TLS, it wouldn't be possible to coordinate across the
> whole stack.

Typically protocol design which is build on top of other protocols
assumes that they operate as reasonably. I doubt a TLS implementor who
knows about this timing leak will be the one designing the application
protocol on top, so my bet is that we are going to see application
protocols defined which take advantage of that padding and believing
they offer a plaintext length protection.

That's why, I'd urge to underline this timing leak in the document
rather than hiding it in generic timing leak considerations text. We
already have experience with that. TLS 1.1 documented a similar leak
prominently:
"Implementation Note: Canvel et al. [CBCTIME] have demonstrated a ..."

Note however that documenting the problem itself didn't help in that
case, all implementations were vulnerably to the later lucky13 attack.
The best IMHO is to document the way to address the timing leak.

regards,
Nikos