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

Alfredo Pironti <alfredo@pironti.eu> Wed, 25 September 2013 11:01 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 3121F21F9AF8 for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 04:01:44 -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 aBf8m1oUwTEF for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 04:01:40 -0700 (PDT)
Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0B121F9F86 for <tls@ietf.org>; Wed, 25 Sep 2013 04:01:37 -0700 (PDT)
Received: by mail-qc0-f175.google.com with SMTP id v2so3927684qcr.6 for <tls@ietf.org>; Wed, 25 Sep 2013 04:01:37 -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=mon7lICynwSiJ/oYYGZ5LbzbnULwRw0huxbfnDkjHxE=; b=AezHAeH6ZxHvqiLa4KWPALMMMHw6VlCGwG8PPEMC36Xaz8mF1VkfEmKhZMlKl/Oed9 HGS3hNE3yb7Y/QsY/D+UQWbDXcKi3rcpVfahEJtGwTD22PvbKfW4dz/z8Ts5/yGAmrcS ykvsxc5VrUnUkfbpT5A2Rl9bxbu/2eT4+gIlA=
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=mon7lICynwSiJ/oYYGZ5LbzbnULwRw0huxbfnDkjHxE=; b=BkqXGuW9jYzH8Zpm8nDznZorSxI+9g+TRs2le7nJfMsm7rHfr2KV4NRsfMsNXBCkZJ Ay7EWmPPMA7YDi8EMSCMFdMCQn+0KtcBwbpoC/MG0dzOPr3om2jfNArw6JggCYoPMUtm wUtL8BExyvpjoMzj4elFQdcmTnRIoySDCIZVhZnl//KQIbRB4PzmmU77qdyk6Z1bnzJZ i2d6SutWOLLpbcKZyRscq/J4PVXjyqN/z+pC8+IsSd1BBT4Se0kC7fLl9DRsL3H1bcX/ hNzYWlY7SaBOGkqMcEXOaa3AgC3/VwOWnAzP+LPM722ssxyvazoiHP9yLzNzY/mzSq1s qs3Q==
X-Gm-Message-State: ALoCoQlyiXV8/run7gB+AX3WlrVegLaZc5jDromp6GvspvwX/5oisjFbtl3KmXy2aWZnMDLpwN+0
MIME-Version: 1.0
X-Received: by 10.224.92.81 with SMTP id q17mr15474735qam.92.1380106897090; Wed, 25 Sep 2013 04:01:37 -0700 (PDT)
Received: by 10.49.108.103 with HTTP; Wed, 25 Sep 2013 04:01:36 -0700 (PDT)
X-Originating-IP: [128.93.188.195]
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>
Date: Wed, 25 Sep 2013 13:01:36 +0200
Message-ID: <CALR0uiJPZQZ9-RJUmy-GZ-16E4Q3QB_DY=fk_8wEtWio63Fgtw@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: Wed, 25 Sep 2013 11:01:44 -0000

On Wed, Sep 25, 2013 at 12:30 PM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
> Eric Rescorla <ekr@rtfm.com> writes:
>
>>Do you think you could address the questions I asked below?
>
> Sorry, given the email avalanche recently and the fact that I wasn't sure what
> the questions were getting at, I'd put them in the TODO list.
>
>> - Because this draft relies on extensions, it seems not to resist
>>   active attack when clients do insecure version fallback
>>   (see for instance:
>> http://www.ietf.org/mail-archive/web/tls/current/msg09468.html)
>
> Right, but given that the problem is broken clients I'm not sure what the
> issue is.  Anything that falls back to older, less secure versions of
> protocols is going to be vulnerable to things that the newer protocols fix.
>
>> - Maybe I am misreading the draft, but I'm unclear on how you get
>>    the TLSCompressed.length for the MAC computation in Section 3.
>>    Does this have the same issue as was raised for McGrew's CBC AEAD
>>    draft?
>
> What was the issue raised for the AEAD draft?  Since I'm not sure what the
> question is asking, the only real response I can give is that there's a number
> of implementations out there that interoperated without problems, so whatever
> the perceived problem is, it doesn't seem to be much of an issue.

The issue is on the receiving side, about computing the
"TLSCompressed.length" field that you need to put in your local
computation of the MAC. I believe
http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-03
as currently defined suffers the same issue.

On receiving side, currently you can't just take the ciphertext and
additional data and locally derive a MAC from it, because the MAC
contains the TLSCompressed.length field, which is the lenght of the
plaintext *before* padding. So, currently, you need to:
1) decrypt
2) split plaintext from pad to recover the TLSCompressed.length value !!!
3) check the MAC

note that step 2 is performing an operation on sensitive data *before*
the MAC has been checked, which actually exposes a very similar
padding oracle to the one that affects current MtPtE.

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.

As a note, this details are already sorted out in
http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02
where the whole padded length is included in the MAC, and an
"implementation note" paragraph forces the implementer to perform
decryption steps in the right way, avoiding "smart" developers to take
insecure shortcuts.

Best,
Alfredo

>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls