Re: [TLS] Consensus Call on MTI Algorithms

Nico Williams <> Thu, 02 April 2015 19:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B698F1A019B for <>; Thu, 2 Apr 2015 12:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BnPs2XRsJkq6 for <>; Thu, 2 Apr 2015 12:44:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CA80E1A0193 for <>; Thu, 2 Apr 2015 12:44:19 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 83090554062; Thu, 2 Apr 2015 12:44:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s=; bh=c1NkEJbx34fnfRkoDmkQpwM3ZxM=; b=qBf2Jx7Z7jZ rOXi61LcPGEh4mn/Rzu1mS3sTk62EptFQtGgXiGO3SLAaYpKJ14B2DLBiR42aedj IQ9uxxEe7LdiSM+EV7t7iI5LgA/i+B8z4ZjkVZ3UeUJjSOzzeTk832DrAytPYEjo 2si4IJu1w3XyoKMg8kKvTjnq3t8lhp+c=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id E8706554060; Thu, 2 Apr 2015 12:44:18 -0700 (PDT)
Date: Thu, 02 Apr 2015 14:44:18 -0500
From: Nico Williams <>
To: Yoav Nir <>
Message-ID: <20150402194417.GJ10960@localhost>
References: <> <> <> <> <> <> <> <20150402183622.GE10960@localhost> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Consensus Call on MTI Algorithms
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, 02 Apr 2015 19:44:20 -0000

On Thu, Apr 02, 2015 at 10:19:17PM +0300, Yoav Nir wrote:
> > On Apr 2, 2015, at 9:36 PM, Nico Williams <> wrote:
> > 
> > On Thu, Apr 02, 2015 at 05:52:36AM -0700, Yaron Sheffer wrote:
> >> On 04/02/2015 05:48 AM, Stephen Farrell wrote:
> >>> But isn't it likely we revise the TLS BCP once TLS1.3 is done and
> >>> implementations start to become common? We can make sure things
> >>> all add up at that point in time, and are in-whack with what people
> >>> are deploying, but we don't necessarily need to do so now I think.
> >> 
> >> It entirely likely. But even then, I am not sure we'll be able to
> >> convince people who went to AES-256 (presumably, for "compliance"
> >> reasons) to move to ChaCha. And certainly not to AES-128...
> > 
> > Must-implement != must-deploy.
> Hi, Nico.
> That’s a nice catch-phrase, but what does it mean? Suppose I am

I should have completed the thought :/  And I probably misunderstood
your point about compliance.

What I'd meant to say is that if external-to-the-IETF "compliance" rules
have anything to say on the matter, no problem:

 - external rules can demand additional algorithms
 - external rules can demand that some algorithms be disabled that we
   require to implement

External rules could refer to: IoT realities, protocol-specific profiles
of TLS, laws and regulations of various countries, corporate policies,

My catch-phrase was about the latter.

> implementing a TLS library specifically for the IoT space. Being a
> standards-compliant implementation, my library and all its users will
> of course conform to the profile in draft-ietf-dice-profile. That
> means TLS_PSK_WITH_AES_128_CCM_8. Given this, why must I implement
> AES-GCM? Why should I implement ChaCha? I and any other IoT
> implementer will argue that the devices don’t have the memory for code
> that will never run. 

This is a bit of a semantics game.  Is an implementation of TLS that
doesn't implement any of the required algorithms still TLS?  Can we have
profiles that specify different sets of required/recommended algorithms?

The answers don't really matter.  Suppose that you are implementing such
a library, you don't implement the required algorithms, and that you
call the result something like YoavTLS, or FooLangTLS ("TLS for the Foo
programming language").  Will the IETF police drag you to the IETF jail
for doing that?  No.

These requirements are really for general purpose TLS implementations.
IoT is a bit of a special case for many reasons, not just their limited
hardware capabilities.