[TLS] dealing with AEAD partial delivery [was: Re: Comments on]

[Daniel Kahn Gillmor <[e-mail]>]

On 02/18/2014 07:56 AM, Niels Möller wrote:
> I think there's a difference between on one hand, truncation due to
> random failures of your own, reasonably trusted, hardware. And on the
> other hand, truncation caused the enemy attacking the communication
> channel for some evil purpose.

I agree that there is a difference between those cases in the abstract
sense.  But from the recipient's point of view, these cases are often
indistinguishable from one another.  I'm not sure that any AEAD api
should try to distinguish between them.

> If we really want to make progress with this discussion, I guess we must
> also distinguish between file types where appending data doesn't change
> the meaning of earlier data (e.g, a typical log file), and file types
> where appending data can change the meaning radically (e.g., consider a
> document format where you can add data at the end of the file which adds
> a mark "this document is fake" on top of every page when the file is
> displayed or printed).

I think this distinction is also likely to be hard for generic tools
(tools which want to be context-independent) to make.  But, just going
with a non-exhaustive, first-pass comparison approach, there are some
unsettling results:

text/html is a content-type that meets the
"sensitive-append/risky-truncation" definition, since new html elements
(not to mention javascript) can effectively obscure or override previous
html elements, at least in common visual renderers; text/plain arguably
meets the "insensitive-append/safe-truncation" definition, since new
elements never directly collide with old elements (though a postscript
to a human-drafted document that says "PS ha ha just kidding" changes
the semantics of the earlier content significantly).

Looking at the behavior of modern browsers using https with GCM
(ECDHE-RSA-AES128-GCM-SHA256), they render both text/html and text/plain
data streams as they receive them, and they do not provide any
indication to the user that they believe the data to be truncated, even
when receiving an early TCP connection termination, or when a
Content-Length: header is not satisfied, or when (in the case of
text/html) the html document is not properly closed.

So content truncation attacks appear to be already possible in current
implementations, despite any guarantees provided by AEAD.  Note that I
haven't tried to attack the AEAD itself at the TLS record layer, but i'm
observing that common utilities like browsers don't propagate truncation
errors up to the user already. :(

Perhaps this angle on the issue is best moved over to the uta working
group, since it's about what to do in the application layer with certain
kinds of TLS failures.

	--dkg