Re: [TLS] Comments on

Nikos Mavrogiannopoulos <nmav@redhat.com> Mon, 17 February 2014 08:10 UTC

Return-Path: <nmav@redhat.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 18DEB1A0041 for <tls@ietfa.amsl.com>; Mon, 17 Feb 2014 00:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.45
X-Spam-Level:
X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 rlyDus6zpTWF for <tls@ietfa.amsl.com>; Mon, 17 Feb 2014 00:10:09 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 19E5A1A008D for <tls@ietf.org>; Mon, 17 Feb 2014 00:10:08 -0800 (PST)
Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1H89q2r029590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Feb 2014 03:09:52 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1H89mPn009990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 17 Feb 2014 03:09:49 -0500
Message-ID: <1392624588.30995.10.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Adam Langley <agl@google.com>
Date: Mon, 17 Feb 2014 09:09:48 +0100
In-Reply-To: <CAL9PXLzgHqguYfKwhiVyjDeSCUkqwbsoujAcz8UPN0FQyfaodg@mail.gmail.com>
References: <nnha83nwy9.fsf@bacon.lysator.liu.se> <CAL9PXLyWhqSdG5YRyrOprW5wgCYCwHn7_a=R2sb+mN-irkMYbA@mail.gmail.com> <nna9dum6fk.fsf@bacon.lysator.liu.se> <CAL9PXLyC98rc73x7o4gDeu-UBz1k0VP_qTdbCqgSSObuKf9+LA@mail.gmail.com> <nnsirlldyf.fsf@bacon.lysator.liu.se> <CAL9PXLzgHqguYfKwhiVyjDeSCUkqwbsoujAcz8UPN0FQyfaodg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4dVnEva2oyUKfF7dnJQU2-6xFzs
Cc: Niels Möller <nisse@lysator.liu.se>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Comments on
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: Mon, 17 Feb 2014 08:10:11 -0000

On Fri, 2014-02-14 at 14:49 -0500, Adam Langley wrote:

> > By streaming, I don't advocate you do the decryption in a pipe line;
> > that's clearly a dangerous habit. Usecase is more like on one machine
> > running
> >   src-machine$ tar -cf - foo-dir | aead-encrypt | send
> This use of streaming is fine by my criteria, assuming that
> "aead-encrypt" is chunking the input into different blocks and
> applying the AEAD to each block. This is perfectly fine with a
> one-shot(*), AEAD API at the core.

I'd pretty much agree with the chunked approach, but I now realize that
it is more hard to get it right than the streaming one. In the chunked
approach one would need to implement sequence numbers (could be implicit
as additional data) and a termination block. So both approaches have
quite some disadvantages. The streaming approach allows for misuse of
the API which may cancel the benefits of AEAD, and the chunked approach
requires the developer to create a safe protocol over AEAD.

If the idea is for AEAD to be used by an average developer, it seems we
need even a higher abstraction than that; even for such a simple
use-cases.

regards,
Nikos