Re: Proposal for doing unauthenticated encryption inside of HTTP/2

On Tue, Dec 03, 2013 at 09:32:37AM -0800, Paul Hoffman wrote:
> On Tue, Dec 3, 2013 at 9:11 AM, Martin Thomson <martin.thomson@gmail.com>wrote:
> 
> >
> > Why did you choose to submit a draft that doesn't tackle the key
> > question of what is being encrypted?
> >
> 
> Because the goal is to "encrypt more", and there is disagreement about what
> "more" means. The WG seemed more wedged on how to encrypt than what to
> encrypt. I trust the WG to resolve the latter if they figure out the former.

Just encrypting the complete frames and appending tags doesn't work. For two
reasons:
1) For some AEAD modes, decrypting the start of frame without knowing length might
not be possible (albeit it seems to be possible for most common ones, like GCM
and EAX, and maybe also OCB).
2) Pretty much no crypto library implements unauhenticated partial decryption of
AEAD schemes.

Also, that kind of thing would be really trivial in AtE- (or E&A)-type authenticated
encryption, but unfortunately crypto people tend to really hate AtE/E&A (mostly
because padding often gets screwed up, resulting all sorts of vulernabilities[1]).

So in practice, one would have to have duplicate length values in the clear (or
swap order of some header fields and have the length in clear in front, as I
would dislike to have frame type in the clear)...


As for IVs, for most schemes that aren't flaky for other reasons (e.g. CBC-based
ones are flaky), one can just use incrementing nonces. For CBC, I don't even
pretend to understand what it takes to use it securely[2]...


Also, for switching modes, maybe a new frame type to signal key switch (a'la TLS)?
That wouldn't add any latency, because it always can be bundled with pre-existing
flight.


[1] TLS has had padding oracles and Lucky13. Both from padding done in a bad
way.

[2] TLS has had BEAST there (from messed up CBC mode in TLS 1.0).


-Ilari

Received on Tuesday, 3 December 2013 19:24:41 UTC