Re: [TLS] Confirming Consensus on supporting only AEAD ciphers

Eric Rescorla <ekr@rtfm.com> Fri, 28 March 2014 14:24 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4D61A0813 for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 07:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIDrxKCW_xAX for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 07:24:08 -0700 (PDT)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id A758C1A0699 for <tls@ietf.org>; Fri, 28 Mar 2014 07:24:07 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id f8so815967wiw.6 for <tls@ietf.org>; Fri, 28 Mar 2014 07:24:05 -0700 (PDT)
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:from:date :message-id:subject:to:cc:content-type; bh=KUCyA9bY7xLL0OVl+oTMyPQ1ypG+4CBPsSXLe4Rvg9A=; b=Iv+AMcJ6BEgHjE21nQn1TnCb1/qHjq1C5xGtpCmpg304J3b2p761ZechdpV2TLnH4g JXeRuF7SHpXdSgtpwW0gd5Cxr2zelA1ITQ2bpzEj3Xt4MXd3BFpLeWp+ock2yhHyOH0r WBKzdfhN53GkGfOpvcNhj3MNb+fTNbw8EJlEodbDpCH1/96DXSGzUEARj2Bf0bJNYE2b b4SKv7bzcAZj7v3rb1uA81gmLywy00PFEBF/dkSVI2q59YSPxxjd9Z2CHXyMMyLkUNGj ER5yHpz0CT+z/BCIExHaXXd/U+bPjzyuSPKtSToJ0DTc17intboeSK5zkmzvwjhUPd0O npGw==
X-Gm-Message-State: ALoCoQl+1CuJFnilQelzngj9svDKqC3qqsbOlRMIL09QGvAXu7KgLjgFAAwIaA6XI2gk3DJtpTjF
X-Received: by 10.180.90.140 with SMTP id bw12mr13173728wib.18.1396016645044; Fri, 28 Mar 2014 07:24:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Fri, 28 Mar 2014 07:23:24 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <CACsn0cnSJ6i5m3eNonXE++fouuryOHzEMAf0xTP8SEruUhu87A@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C7372394B6C@uxcn10-6.UoA.auckland.ac.nz> <F8DB048B-24D0-4B97-85F0-39807B54EDDB@cisco.com> <1395998078.19721.60.camel@dhcp-2-127.brq.redhat.com> <CABcZeBPKAnp1Lna8hL9P67iuqdP_Lkcxjf20mNw-WtW67dqbrQ@mail.gmail.com> <CACsn0cnSJ6i5m3eNonXE++fouuryOHzEMAf0xTP8SEruUhu87A@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 28 Mar 2014 07:23:24 -0700
Message-ID: <CABcZeBMczbY8Zaw-TKL=KXK2JBiTPX52gDXtsj_1u8bM3Muoeg@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043c811a3a900f04f5ab7483
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/W16uw__r83LeePcpbb9fpM8KKX8
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 28 Mar 2014 14:24:09 -0000

On Fri, Mar 28, 2014 at 7:16 AM, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Fri, Mar 28, 2014 at 9:57 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > The idea here is that TLS currently specifies *in TLS* how to compose
> > authentication and encryption which means that we have to specify
> > three interfaces for three different kinds of ciphers (stream, block,
> AEAD).
> > Since cryptographic practice seems to be moving towards AEAD as
> > a primitive, we have an opportunity to simplify matters by going to
> > an AEAD only interface which also has the virtue of having to specify
> > specific constructions in TLS.
>
> So let me get this straight: what we are planning to do is eliminate
> the current MAC-encryption layer, and instead have a layer that takes
> a plaintext TLS record and encapsulates as an encrypted one. The TLS
> spec specifies the inputs, and the cipher has to specify how to go
> from inputs to ciphertext and be IND-CCA2+INT_PTXT secure.


Assuming I understand you correctly, then yes, this sounds right,
with the small caveat that we would probably not leave the question
of how to format the cleartext part of the (otherwise encrypted)
record header up to the cipher, since that's a TLS issue, though
we would expect it to be covered as part of the "additional data".


This has a major advantage in that we lose a lot of length and
> complexity from the spec.


This was my thinking as well.

-Ekr