Re: [Ace] How to specify DTLS MTI in COAP-EST

Carsten Bormann <cabo@tzi.org> Fri, 08 June 2018 05:10 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F04130E14 for <ace@ietfa.amsl.com>; Thu, 7 Jun 2018 22:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 yvTQOhscg8Ky for <ace@ietfa.amsl.com>; Thu, 7 Jun 2018 22:10:29 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19CCF130E1F for <ace@ietf.org>; Thu, 7 Jun 2018 22:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w585ANZV011036; Fri, 8 Jun 2018 07:10:23 +0200 (CEST)
Received: from sev.fritz.box (p5B3D0187.dip0.t-ipconnect.de [91.61.1.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4129TV5mStzDXgZ; Fri, 8 Jun 2018 07:10:22 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <31776.1528406819@localhost>
Date: Fri, 8 Jun 2018 07:10:21 +0200
Cc: Eric Rescorla <ekr@rtfm.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "ace@ietf.org" <ace@ietf.org>
X-Mao-Original-Outgoing-Id: 550127418.731071-cf3746d990adc9e31ebdf7641e4eff91
Content-Transfer-Encoding: quoted-printable
Message-Id: <88E57C96-48FC-4D2B-A666-3363D67A1372@tzi.org>
References: <13635.1528327933@localhost> <CE664422-ED4B-43FE-A531-4EAA090CA036@vigilsec.com> <VI1PR0801MB2112950E1677D701165C74E2FA640@VI1PR0801MB2112.eurprd08.prod.outlook.com> <12464.1528393277@localhost> <CABcZeBPoVaKhyMEtvbF=PtKE1brb0jvEYHvZV23N40XEV=Tnzg@mail.gmail.com> <31776.1528406819@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/JE_08yLBfoUSMa_eFjjGBkNldXo>
Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2018 05:10:33 -0000

We had that discussion at the SUIT hackathon earlier this week, as well.
To get actual interoperability there, of course, every test pair needs to decide between P-256 and 25519 (and, maybe, use hash-based instead; but that is more appropriate for firmware update than for other uses).

The general observation was that we are seeing a much slower displacement of P-256 by 25519 than we would have expected, say, a year ago.
So, indeed, RFC 7925 is continuing to describe the current situation.

We can simply acknowledge that status quo.
We can also express some normative intent to accelerate the transition.
Or we can express an expectation that it will accelerate, without actually expressing normative intent.
Either one could be anchored at a specific date (say, 25519 becomes MTI from 2020).
As I said at the IoT-dir meeting in London, this is really the discussion I would like to see now across all IoT groups.

What do we want?

Grüße, Carsten



> On Jun 7, 2018, at 23:26, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Eric Rescorla <ekr@rtfm.com> wrote:
>> TBH, I'm not a fan of SHOULD+, etc., and they're pretty alien to TLS, so
>> you should just use words if you want to convey these points.
> 
>> With that said, I don't really understand the objective here: we're
>> generally moving towards the CFRG curves, so what's the reasoning for the
>> P256 MUST and why do you think that will change.
> 
> Because current generation of hardware and TPM modules has definite support
> for P256, and while some of the hardware assist out there can accelerate CFRG
> curves as well or better:
>  a) it's not universally true.
>  b) it takes time to get the new code through a FIPS process.
> 
> So, we want to say, P256 is if you must, and CFRG if you can on the
> constrained device.
> 
> On a non-constrained CA side, P256 becomes a MUST because one needs to
> support the old devices, and CFRG becomes a MUST just as soon as one
> can get the code through the right processes.
> 
> In any case, 7925 says EXACTLY this, so we are happy, and do not want to
> repeat things.
> 
>> wrote:
> 
>>> 
>>> Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
>>>> why don't you just reference https://tools.ietf.org/html/rfc7925?
>>> 
>>> Ignorance :-)
>>> Thank you, I think that we will reference it then;
>>> 
>>> Section 4.4 includes:
>>> 
>>> At the time of writing, the
>>> recommended curve is secp256r1, and the use of uncompressed points
>>> follows the recommendation in CoAP.  Note that standardization for
>>> Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for
>>> this curve will likely be required in the future.
>>> 
>>> which is what we want to say anyway.
>>> 
>>>> I am not a big fan of making all sorts of different crypto
>>>> recommendations in our specs that differ slightly.
>>> 
>>> --
>>> ]               Never tell me the odds!                 | ipv6 mesh
>>> networks [
>>> ]   Michael Richardson, Sandelman Software Works        | network
>>> architect  [
>>> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
>>> rails    [
>>> 
>>> 
>>> _______________________________________________
>>> Ace mailing list
>>> Ace@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ace
>>> 
>>> 
> 
>> ----------------------------------------------------
>> Alternatives:
> 
>> ----------------------------------------------------
> 
> -- 
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace