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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 07 June 2018 21:27 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 234D7130FA2 for <ace@ietfa.amsl.com>; Thu, 7 Jun 2018 14:27:44 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 I8tdUkRjq152 for <ace@ietfa.amsl.com>; Thu, 7 Jun 2018 14:27:38 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F4032130DD6 for <ace@ietf.org>; Thu, 7 Jun 2018 14:27:37 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CE2C320090; Thu, 7 Jun 2018 17:41:06 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 736843033; Thu, 7 Jun 2018 17:26:59 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 70EB03032; Thu, 7 Jun 2018 17:26:59 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Eric Rescorla <ekr@rtfm.com>
cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "ace@ietf.org" <ace@ietf.org>
In-Reply-To: <CABcZeBPoVaKhyMEtvbF=PtKE1brb0jvEYHvZV23N40XEV=Tnzg@mail.gmail.com>
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>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 07 Jun 2018 17:26:59 -0400
Message-ID: <31776.1528406819@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/DCciuFSYrXxX5RgBm38bCX82TRw>
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: Thu, 07 Jun 2018 21:27:45 -0000

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>, Sandelman Software Works
 -= IPv6 IoT consulting =-