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

From: Peter Gutmann <[email-masked]>
Date: Thu, 26 Sep 2013 04:54:37 +0000

Martin Rex <[email-masked]> 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.

Peter.

---

From: "Paul Bakker" <[email-masked]>
Date: Thu, 26 Sep 2013 08:41:02 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter
> Gutmann
> Sent: donderdag 26 september 2013 6:55
> To: <[email-masked]>
> Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-
> mac-00.txt
> 
> >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:
> >
> 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

---

From: "Paul Bakker" <[email-masked]>
Date: Thu, 26 Sep 2013 11:42:50 +0200

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:
> 
> [email-masked] wrote on ent: donderdag 26 september 2013 6:55:
>>> Peter's draft, the MAC no longer operates on the TLSComressed PDU,
>>> but on the TLSCiphertext PDU -- which results in:
>>> 
for a
> number of reasons.
>   "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!
> 
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.
> 
So
> please reconsider solving the issue this way.
> 
> Paul