Re: [TLS] Pull Request: Removing the AEAD explicit IV

Brian Smith <brian@briansmith.org> Thu, 19 March 2015 11:34 UTC

Return-Path: <brian@briansmith.org>
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 0667B1A89AD for <tls@ietfa.amsl.com>; Thu, 19 Mar 2015 04:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 70ZUBFIW7-mZ for <tls@ietfa.amsl.com>; Thu, 19 Mar 2015 04:34:26 -0700 (PDT)
Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE36D1A89A1 for <tls@ietf.org>; Thu, 19 Mar 2015 04:33:57 -0700 (PDT)
Received: by obcxo2 with SMTP id xo2so52081745obc.0 for <tls@ietf.org>; Thu, 19 Mar 2015 04:33:57 -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:date :message-id:subject:from:to:cc:content-type; bh=gVKNJEia/NAwg7fOsefTxoizlbfjgfEUxIudkDV8D5I=; b=fA7WGQ4lElsLD8IvfEdoljuvixRSGO2lBMDhb0zqdOL0uCvm345VhdUtPkGMISaD8g G8YqI3x7KGMrEKXGbNmVc+EgB5N5+r+47cXDfDHn4twaHBRgPxO/VULV0nCkEqM/KSAs bzVOE/rtbpBc4gpLUg58wxZgfK4TYVTd+6iLnfmSqs+1+HsKWs5nJ7++h+3tjVl/z4Dk HoQCOpw4+QPHDivDSuraGBT8nQYxDO422QMCFUuEOWb/IeJMvvHNChlM4Ykmffl22/qH Uzc8lvWvz+CpwzoN4WdwxciOfaVmyZqHKu84OxFDGT6Hr9/5woOyu2R3wCb+f6L+5PmL a4ug==
X-Gm-Message-State: ALoCoQn38k2jHHZQcXyH8NMpal/Y/iyEYFQRIj8xQA0WmL3KVLgF+j7ehCTyPSTgDfcayJPDVvBu
MIME-Version: 1.0
X-Received: by 10.60.82.10 with SMTP id e10mr2822358oey.85.1426764837329; Thu, 19 Mar 2015 04:33:57 -0700 (PDT)
Received: by 10.76.144.105 with HTTP; Thu, 19 Mar 2015 04:33:57 -0700 (PDT)
In-Reply-To: <CACsn0ckU==QcJhTvyov2DeJCKq_kxvfqK=AkFKsyFcRbQBfC-Q@mail.gmail.com>
References: <CABcZeBPfasM5HmJaATLUHQKRgiSGCreJt1T=UoDBGCbcuzyW8Q@mail.gmail.com> <CAAF6GDdbr57hVa4OD-wCfQtx46bo_D858V_25w8gTtd+M8OhzQ@mail.gmail.com> <CACsn0ckU==QcJhTvyov2DeJCKq_kxvfqK=AkFKsyFcRbQBfC-Q@mail.gmail.com>
Date: Thu, 19 Mar 2015 01:33:57 -1000
Message-ID: <CAFewVt6ay5ti9EJRsAm0fLSFjyBHCg_BM0P2DbKHwDxcEWxOmQ@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/x_MZiaDDrQuZFKyI_6a-9y_aaWA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV
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: Thu, 19 Mar 2015 11:34:28 -0000

Watson Ladd <watsonbladd@gmail.com>; wrote:
> If we're going to make a change this
> radical, why not make equally radical changes to simplify the protocol
> further if that's possible?

That's already happening.

> I'm also not sure what we're supposed to
> be gaining from this change: while it's true that we don't need to
> send the explicit nonce, I don't know that we are losing anything from
> having it.

1. The explicit nonce is a place to potentially leak secret data.
2. The explicit nonce is a place where a PRNG could be used poorly,
and/or a poor PRNG could be used.
3. Security properties of an explicit nonce cannot practically be
verified by the receiver, whereas the receiver could (and in fact
would have to) verify that an implicit nonce based on the record
sequence number is safe.
4. The implicit IV reduces per-record overhead on the wire by 16 or 32
bytes. For some applications that's substantial.

There are other advantages that aren't so simple to describe.

> Yes, I know the ChaCha draft does it a seemingly more
> sensible way, but the last thing we need is to further increase the
> codesize of TLS implementations.

This change would not contribute substantial complexity to most TLS
libraries that would implement it. Most TLS libraries already have
similar logic to deal with implicit vs. explicit IVs in CBC mode for
SSL3/TLS1 vs. TLS 1.1+.

Also, the proposed changes to the handshake state machine for TLS 1.3
are much larger. It seems we can't substantially simplify the protocol
proportionately increasing the complexity of implementations that need
to also implement earlier versions.

Cheers,
Brian