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

Watson Ladd <> Thu, 19 March 2015 16:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ECC7A1ACE2F for <>; Thu, 19 Mar 2015 09:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kn_UWim5xZfN for <>; Thu, 19 Mar 2015 09:20:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF2AC1ACE30 for <>; Thu, 19 Mar 2015 09:20:55 -0700 (PDT)
Received: by yhpt93 with SMTP id t93so28262652yhp.0 for <>; Thu, 19 Mar 2015 09:20:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4WryrL+FeNPw5imVn7y0n5P2cd1DRNsAj9LUoGJLEE8=; b=a1ngmu8IEvvxH00x6rse3N7wEVjE/uUX7Jgdyi7d3MS8IynsvBe00WUMT8rnp1Ydjq +QvnGOU6ZsOHIQmhVZ2S2Hepy9OkZdnp5jCEBdEpUPe0FPugUpE13jJrPwT3QqNbQCSA +0DjoPqbFEnj/Ya2ugbMTT+jD9R6hwvRvo0i97lCFxa+tDNL49r58+nx/5LXlKhHRa2F 5ViO7hwgN+VWxnMZd84Yop2HB93q+oCp+tXVg8Mh5TX1INrEA2I1hKVRNveGviwAiqwh 1kiG6+7zXgbuBbh7yonChuVCCc/xWq+/9LsdGGQnJiPnM5d0iWGwmA/PtrRy+aFZ4aPa UtLA==
MIME-Version: 1.0
X-Received: by with SMTP id n61mr77884738yhp.44.1426782055016; Thu, 19 Mar 2015 09:20:55 -0700 (PDT)
Received: by with HTTP; Thu, 19 Mar 2015 09:20:54 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 19 Mar 2015 09:20:54 -0700
Message-ID: <>
From: Watson Ladd <>
To: Brian Smith <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Mar 2015 16:20:59 -0000

On Thu, Mar 19, 2015 at 4:33 AM, Brian Smith <> wrote:
> Watson Ladd <> 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.

No it's not: the draft is still longer than the TLS 1.2 RFC, and seems
to demand support for every single usecase. This seems at odds with
absolute simplification, where we would throw out less important
features, and radically reduce the complexity.

>> 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.

You are not supposed to use random nonces with GCM.

> 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.

The receiver cannot determine that the sender isn't sending an extra
copy to the secret police anyway. Of course, this implicit nonce
strategy will prevent certain bugs involving being unable to count,
and may be worth it.

> 4. The implicit IV reduces per-record overhead on the wire by 16 or 32
> bytes. For some applications that's substantial.

This is an actual advantage.
> 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+.

A million here, a million there: pretty soon you start spending real money.

> 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.

Adding new states and transitions to a state machine doesn't increase
complexity that much: if the transition doesn't apply, you don't take
it. But adding additional special casing all over the place to deal
with TLS 1.3 does increase complexity much more.

Watson Ladd

> Cheers,
> Brian

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin