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

Alfredo Pironti <alfredo@pironti.eu> Thu, 26 September 2013 09:32 UTC

Return-Path: <alfredo@pironti.eu>
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 4122D21F9AA4 for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 02:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.426
X-Spam-Level:
X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1]
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 Aa9cg+dDzg4C for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 02:32:07 -0700 (PDT)
Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A69FB11E8172 for <tls@ietf.org>; Thu, 26 Sep 2013 02:32:06 -0700 (PDT)
Received: by mail-qe0-f44.google.com with SMTP id 3so597365qeb.3 for <tls@ietf.org>; Thu, 26 Sep 2013 02:32:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AwOWZiEZJu0eP979ASjTTpTK5h4NemI0DAydbp8I2PY=; b=Ss9ebPVr4ssBfQBqnIY/RNj6dBoaD6RvJV4lh2WRcyZnrq2yJy86XCTIpKQnHV3cX6 oXnvZE1Gnb75GWGxe6QaC1Yps4fKbUKhI0xXqnop2WS9I+cdRa9t5rjcOQqYbxNAJz8A /G38sYPMc2K/5bhz2LYKGi3wmf0p806pO8ohs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AwOWZiEZJu0eP979ASjTTpTK5h4NemI0DAydbp8I2PY=; b=YZTYaCHb4wsikSKoCPoGPIzQ9U4jp763jEDZbCAo+6VWivsc4+KoNC+k+8ZHcMcjGz CcpeImVBJhg/qZIrpwrzoEpLliqd9TZgaPT9Wt2dsKUJYh7jFkPmMMbbCYrfByX5l5q8 7WYXkoGIv7IwnnJO7fYtbIQcN4hWy1nMcg1sOvaGnZUVSTiaZJNKgSlqqnsxIWEQjaUt 8VEINf3NQyaMLHqhkHsCoX61b16MVX8W4onLBCB8G1c56QgiFThj9/sa6cxkJu1Ye3+a T/9ophmdyJF0AshYkhr02ZLndfdjpAyg1EsFSajVFcczf4jHlpJnKMMYhlkRItQgQS3n VUJQ==
X-Gm-Message-State: ALoCoQkoN/eelYNEmnCbQXXn8NmCtig5o/MGmGmPbhC89cDrMg80Qd+GzYUUca75ObOEXAgLPEg2
MIME-Version: 1.0
X-Received: by 10.49.48.168 with SMTP id m8mr8392543qen.25.1380187925718; Thu, 26 Sep 2013 02:32:05 -0700 (PDT)
Received: by 10.49.108.103 with HTTP; Thu, 26 Sep 2013 02:32:05 -0700 (PDT)
X-Originating-IP: [128.93.188.195]
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735567D458@uxcn10-6.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C735567D458@uxcn10-6.UoA.auckland.ac.nz>
Date: Thu, 26 Sep 2013 11:32:05 +0200
Message-ID: <CALR0uiKbAEmWR2R7kEik=PGwwoAGVH+TAQk8G13yw5TPGPUVXQ@mail.gmail.com>
From: Alfredo Pironti <alfredo@pironti.eu>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset=UTF-8
Cc: "<tls@ietf.org>" <tls@ietf.org>
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:32:11 -0000

At this point, it seems to me that both [1] and [2] solve the padding
bug, and both are straightforward to implement.

On the plus side, [2] also offers length-hiding, which is going to be
useful in TLS 1.3, when more parts of the handshake are moved to the
encrypted stage. (E.g., the size of an encrypted certificate is
usually enough to reveal the identity; or look at the NPN ad-hoc
padding strategy to protect the next protocol name).

Actually, the padding bug could also be solved by using salsa/chacha
(which I support); additionally implementing also [1] may be less
useful (redundant) in this case; implementing [2] would still inject
padding features into salsa/chacha (and AEAD), for those who need
length-hiding.

Again, if you don't care about length hiding, you don't *have to*
implement the length-hiding interface to be compliant with [2]; just
follow the data format and you're padding-bug free and interoperable
-- and you can implement length-hiding logic at a later time when your
users ask for it.

[1] http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-03
[2] http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02

Best,
Alfredo

On Wed, Sep 25, 2013 at 2:08 PM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
> Alfredo Pironti <alfredo@pironti.eu> writes:
>
>>Fix is however not too difficult: in the MAC, include the whole
>>"plaintext+padding" length, so that it can be computed directly form the
>>ciphertext length, without need to decrypt it first.
>
> Oh, I see.  It already is, in fact I'd never even considered that you could do
> it any other way, and given the results of the interop tests so far I guess
> no-one else has either.  I'll add a clarification to the draft about this.
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls