Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Bryan Ford <[e-mail]>]

On 02 Dec 2015, at 00:54, Fabrice Gautier <[e-mail]> wrote:
> On Tue, Dec 1, 2015 at 7:27 AM, Bryan A Ford <[e-mail] <mailto:[e-mail]>> wrote:
>> On 12/1/15 4:02 AM, Fabrice Gautier wrote:
>>> 1) What would be the implications of this for DTLS? (Knowing that one difference between TLS and DTLS is the record header)
>> 
>> Good question.  Fortunately my proposal should be fairly easy to adapt
>> to DTLS, with one small trick. […]
> 
> Hum.... I wouldn't qualify this as a "fairly simple" solution.

A reasonable but subjective position, which I think we should further discuss later if/when this (or some) WG actually revisits DTLS. :)

>>> 2) In some implementations the record framing/parsing and encryption/decryption are down at different layers. Would this proposal make this type of implementation impossible?
>> 
>> Not that I'm aware of, but I might need more information about the
>> specific layering approaches you're thinking of and how "strongly
>> enforced" that layering might be.
> 
> For example:
>  A TLS library might be logically separated into two main parts:
> 1) A record parsing block, that just take a stream of bytes as in
> input (eg: from a socket) and output a series a record.
> 2) A decrypt function, that take as input full encrypted record and
> output a decrypted one.
> 
> There may be various reason to do this: flexibility, clean layering,
> maintainability, testability, etc...
> 
> Another reason, maybe performance. For example, a network stack might
> not want to send partial records to the application to decrypt. Having
> a simple way for a network stack to implement TLS framing maybe
> beneficial. Currently it would be fairly simple to implement TLS
> record parsing in a TCP stack. But with your proposal it seems it
> would mean the parsing layer would need to get keys and do crypto.

In my first proposal, with headers encrypted with a stream cipher (or AEAD used as one), I think this kind of layering should still be quite feasible, with the one caveat that the TLS record parsing layer does indeed need to make one new “call” into the crypto-related code (to get the header) in addition to the one it already does (to pass the body and header to the crypto code for body-decryption and integrity-check).  And only on the receive path; the send path seems pretty much unaffected.  This doesn’t seem like a big layering problem to me, but again subjective opinions may vary.

In my second proposal, with headers fully encrypted and integrity-checked along with the body, I think the opportunity for the clean layering you propose comes back and perhaps gets even better: it’s just that the record writing/parsing now happens *inside* rather than outside the encryption boundary.  In other words, their order is reversed: the sender invokes the record-writing code first, then the AEAD encryption code to encrypt everything (header and data) at once; the receiver flow invokes the AEAD decryption code first to decrypt everything, then invokes the separately-modularized record parsing code on the already fully decrypted and integrity-checked record content.  This seems even cleaner to me than the current approach, where the record parsing code has to do some (very careful!) parsing of the record before it’s been authenticated, then invoke decryption, then do some more internal parsing on the decrypted AEAD body (e.g., the encrypted content-type within).

B