Re: [TLS] draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD ciphers

Juho Vähä-Herttua <juhovh@gmail.com> Thu, 22 August 2013 01:17 UTC

Return-Path: <juhovh@gmail.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 7DC6D11E81AB for <tls@ietfa.amsl.com>; Wed, 21 Aug 2013 18:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 NZOulqMdaiMa for <tls@ietfa.amsl.com>; Wed, 21 Aug 2013 18:17:46 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 87DA921F8424 for <tls@ietf.org>; Wed, 21 Aug 2013 18:17:45 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id w10so1209038lbi.35 for <tls@ietf.org>; Wed, 21 Aug 2013 18:17:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qrpy9F9FT/Mr7/Ahrz6k/ffWrD90KiH3hQ4utP7sPw4=; b=LB0YdGahVdrXb4QZOGi4dSb5l2AMhTh8v8aBsYIBm2wZWfB7Qs7YW7u4cJ2OF/f6A4 INwGBewV+8R9OcbCNQVn1+UqemVVBFZKfLhx2PJGPdurAYBni/3mSdWnijN+ftzc5Py+ pikije9W/S00kGm5m5np3LCSzgxuyNBPBHS6rD+wCs5TOMny5gW2e+aIZDR3qUDqCLBH MJktCpoLhyXx3+OgD4IQXUf7Isesl+Yw48n+MYOn91n2vrwx5bsfOrTIBnvW3hS2V1ju QreFxvKl3DOVNjSFU2Cm98o8mQyhRTf3fmEdxYHS7r4u3j+j9PSnLF7G3NHsGX2h42DZ CKcA==
MIME-Version: 1.0
X-Received: by 10.112.154.70 with SMTP id vm6mr566553lbb.1.1377134264456; Wed, 21 Aug 2013 18:17:44 -0700 (PDT)
Received: by 10.114.4.20 with HTTP; Wed, 21 Aug 2013 18:17:44 -0700 (PDT)
In-Reply-To: <CAL9PXLwHOaFU8kYQ+hqT+3J47yMXE4LxkG=GDyPdZFmfGQ+n-Q@mail.gmail.com>
References: <CALTJjxEjN04jfCb=mjo1ZWPvgX_sw0Dw6v+AMPKdXp=9BbCxow@mail.gmail.com> <CAL9PXLwHOaFU8kYQ+hqT+3J47yMXE4LxkG=GDyPdZFmfGQ+n-Q@mail.gmail.com>
Date: Thu, 22 Aug 2013 09:17:44 +0800
Message-ID: <CA+BytJrToNn-jQoQu3yxbL-A9K4C1PWW8VtA4yoC2B8YT12Nmw@mail.gmail.com>
From: =?ISO-8859-1?Q?Juho_V=E4h=E4=2DHerttua?= <juhovh@gmail.com>
To: Adam Langley <agl@google.com>
Content-Type: multipart/alternative; boundary=089e0115f5a4a41bad04e47f0e48
X-Mailman-Approved-At: Wed, 21 Aug 2013 20:29:56 -0700
Cc: "foleyj@cisco.com" <foleyj@cisco.com>, "tls@ietf.org" <tls@ietf.org>, Ryan Sleevi <sleevi@google.com>
Subject: Re: [TLS] draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD ciphers
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, 22 Aug 2013 01:17:46 -0000

On Thursday, August 22, 2013, Adam Langley wrote:

> On Wed, Aug 21, 2013 at 1:49 PM, Wan-Teh Chang <wtc@google.com<javascript:;>>
> wrote:
> > Is this a known problem with TLS 1.2 AEAD ciphers?
>
> I hit the same issue while planning to move OpenSSL's TLS CBC decoding
> into EVP (a lower-layer of OpenSSL). I couldn't figure out a way
> around it and gave up.


I came across this a few years ago and finally ended up just writing errata
2390, which simply removes the confusing notion of padding from the
specification, because padding didn't seem to be possible.

Personally I think the AEAD interface of TLS is broken, but people on this
list were not concerned at the time, because it is "only used for GCM
anyway". I can understand that, since fixing it now is not trivial.
Patching the specification in some other document easily leads to
confusion, especially when the original document states that padding should
be possible, and therefore the patch should not even be necessary.


Juho