Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

["Paul Bakker" <[e-mail]>]

Please disregard my previous reply. Let's blame it on my lack of sleep ;)
(I read TLSPlaintext instead of TLSCiphertext)

Paul Bakker wrote on 2013-09-26:
> 
> [e-mail] wrote on ent: donderdag 26 september 2013 6:55:
>> Martin Rex <[e-mail]> writes:
>> 
>>> When changing from mac-pad-encrypt to encrypt-mac, as suggested by
>>> Peter's draft, the MAC no longer operates on the TLSComressed PDU,
>>> but on the TLSCiphertext PDU -- which results in:
>>> 
>>>       HMAC_hash(MAC_write_secret, seq_num + TLSCiphertext.type +
>>>                     TLSCiphertext.version + TLSCiphertext.length +
>>>                     TLSCiphertext.fragment));
>> 
>> So all that's necessary is to change the text to reflect this, and
>> perhaps a note to point it out?  That's fairly simple to do.
> 
> I'm rather new to the list and late for this party..
> 
> But 'skipping' a layer (the TLSCompressed one in this case) is a bad idea
for a
> number of reasons.
> 
> Code path verification.
> In case this comes to fruition, instead of the clean:
>   "Assemble Data -> Compress -> Cipher -> Send",  we get
>   "Assemble Data -> Maybe hash in some specific cases -> Compress ->
> Encrypt and sometimes hash in some specific cases -> Send"
> 
> This makes checking code correctness a step harder, aside from the fact
> that suddenly cryptographic information (which used to be only required
> in the Cipher layer) suddenly needs to be available on other points as
> well.. Meaning more coupling between layers and functions. This is bad
> in my opinion!
> 
> Aside from the fact it's not pretty, there is a reason for having nice
separate
> layers, the fact that you can re-use / re-write the 'old buffer' and do
need to
> use unnecessary extra space. Violating that contract by letting layers
access
> the full data of another layer it should not see, requires extra storage
space,
> which on most embedded systems is very scarce.
> 
> I understand the issue, but in my opinion this is not the way to solve it.
So
> please reconsider solving the issue this way.
> 
> Paul