Re: [TLS] Comments on

Adam Langley <agl@google.com> Fri, 14 February 2014 22:05 UTC

Return-Path: <agl@google.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 1C73D1A015A for <tls@ietfa.amsl.com>; Fri, 14 Feb 2014 14:05:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.627
X-Spam-Level:
X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no
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 pKMj3X4N5Gpt for <tls@ietfa.amsl.com>; Fri, 14 Feb 2014 14:05:34 -0800 (PST)
Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 87B061A0039 for <tls@ietf.org>; Fri, 14 Feb 2014 14:05:32 -0800 (PST)
Received: by mail-vc0-f181.google.com with SMTP id ie18so9542132vcb.26 for <tls@ietf.org>; Fri, 14 Feb 2014 14:05:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=EVxQOGx7f8t/XWmy26qroOW6DlS6c5JAhY/uZEtUpWw=; b=UxkGBnrcYKXzdieW+PRIhTtKU1zL7w11gL4rr6/muHUNVSJy+MnCul0XxAT6NSdsd8 mTW5BtUtoIhvciPALAQeeq2XWSMKaSSnB1e8YDZ/IZF1pqdfYDfC7U/oL0pH8vo/ZKye zsXoSNkDNI/+eVnnGTM3nXA5TB97AFjXg6/dwZPH8LfMSlVtVBEhO9VERJQUdgKdC/AX oR/4Dv0R08bEAPJd2pRg8dFFsrD9A9GxH0eP3xIg0h5fOULR6yolix/E/8qQtYhvKERH AGnHtb9eat/SyHBrApfz2EFKzjxBd4+auA6/0heTm+ja+mGdJd9suWZK49ILBo3LXePc NLXA==
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:content-transfer-encoding; bh=EVxQOGx7f8t/XWmy26qroOW6DlS6c5JAhY/uZEtUpWw=; b=NAyUzB6R7MFtrQnsyJuAZVxmCGFWPqTx+frpWc+RW7iddjdahbJza5TN8qCQgFzHv2 DsI6gyQ6iYMa3Bez5pnEnbbm+ONxyi37pUaByzDhMAND9zunMh2zNmiT61PNCtVY3+Cy algdq/rkNt3uyh524WHuRuPD5jLuT6aCakQo0cDr0uJM1RzgqnRjD14s1SUah/USVwq8 Jc36fMCIqBwGb3tI38hF+9nUhMaxHFBESiZEUBYDOkd/UYpS2bNRUM6CbTeMRBgXXoT5 aP/XxMAS5tPLpVuXICQcGW8ybGIxwayaU+sNgIchd9u3aHFQ3A93fd8SwAkNVUM4R29O CD3w==
X-Gm-Message-State: ALoCoQm/jOhHBOkjFx/X5YP6L2YhMgzRkmFd+AbGg9YqMrtZ1BXiC85/mm7XID7OoxV+XvmwA4Yb6SS7h9JOhvBwV6KaSeZUMf/YfIuZ3gyEpPG1q88sdummiixDDOHeohPEuOVjFwkoOTy79OM/+g1a3sBmYAmg6LS5neXyHhBBVGX6lZJbqjOtwSMEpG6IU/J2sO4aA2fN
X-Received: by 10.52.171.39 with SMTP id ar7mr5828496vdc.5.1392415530775; Fri, 14 Feb 2014 14:05:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.104.37 with HTTP; Fri, 14 Feb 2014 14:05:10 -0800 (PST)
In-Reply-To: <nnob29l8ry.fsf@bacon.lysator.liu.se>
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> <nnob29l8ry.fsf@bacon.lysator.liu.se>
From: Adam Langley <agl@google.com>
Date: Fri, 14 Feb 2014 17:05:10 -0500
Message-ID: <CAL9PXLyFk-BkaLW3Cf=tDFg7CaTbn_NquRm=rY8Hh4Rt_4ie0Q@mail.gmail.com>
To: Niels Möller <nisse@lysator.liu.se>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UpH61JwS6dWS5dmhhPtzm-jSU9c
Cc: "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: Fri, 14 Feb 2014 22:05:36 -0000

On Fri, Feb 14, 2014 at 3:49 PM, Niels Möller <nisse@lysator.liu.se> wrote:
> The proper way is to process the file incrementally (with bounded RAM),
> write the result to a temporary file on disk (preferably hidden, if
> supported by the OS). At the end of data, check authentication, and
> either rename the file and advertise it, or delete it and return a
> failure exit code.

I think that's a fine API to expose if you can limit it to operations
like that. However, I fear requirements creep will will set in as data
needs to be further processed and one ends up evincing a "streaming"
API that has the unauthenticated plaintext problems that I worry
about.

For example, in my favourite, recreational language of the moment
(Go), the convention for layering transforms like decryption is to do
it in a streaming fashion via a minimal interface that provides a
read() like, virtual function. Using a temp file in a library would be
considered poor form, although it does solve the truncation problem.

I admit that I'm hypothesising with little evidence which implies that
the argument can be dismissed with little effort.

Although, if you were to implement just an API like that then you
could require that update be called exactly once, since it wouldn't be
public API anyway, and that would solve your AD length problems.

> But in the case that you really want proper authentication of the
> *complete* file before you start processing it, I think an AEAD chunking
> format is additional complexity with no benefit over plain AEAD, since
> plain AEAD provides exactly the type of autentication needed.

I think the benefit is that one doesn't have to worry about possibly
exposing an unsafe, streaming API. Everything can be composed from a
one-shot, AEAD function and we don't have to worry about littering
header files with more comments describing the superficially correct,
but unsafe, ways that the functions shouldn't be used.

But just because it's not my personal preferences doesn't mean that
it's unreasonable.


Cheers

AGL