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

"Paul Bakker" <p.j.bakker@offspark.com> Thu, 26 September 2013 09:43 UTC

Return-Path: <p.j.bakker@offspark.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4E021F9A19 for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 02:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level:
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoH5bpBnZkae for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 02:43:04 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 3C08E11E817B for <tls@ietf.org>; Thu, 26 Sep 2013 02:43:02 -0700 (PDT)
Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <p.j.bakker@offspark.com>) id 1VP7zx-0004We-1u; Thu, 26 Sep 2013 11:36:37 +0200
From: "Paul Bakker" <p.j.bakker@offspark.com>
To: "'Peter Gutmann'" <pgut001@cs.auckland.ac.nz>, <tls@ietf.org>
References: <9A043F3CF02CD34C8E74AC1594475C735567DBC6@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To:
Date: Thu, 26 Sep 2013 11:42:50 +0200
Message-ID: <01ef01ceba9c$c749f360$55ddda20$@offspark.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFhE9Rc+YY/ht8jD1tO4dwRZdRURgKXZ0P9mp5WjrA=
Content-Language: nl
X-SA-Exim-Connect-IP: 82.161.132.220
X-SA-Exim-Mail-From: p.j.bakker@offspark.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl)
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2013 09:43:10 -0000

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:
> 
> tls-bounces@ietf.org wrote on ent: donderdag 26 september 2013 6:55:
>> Martin Rex <mrex@sap.com> 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