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

Russ Housley <housley@vigilsec.com> Thu, 07 June 2018 13:55 UTC

Return-Path: <housley@vigilsec.com>
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 14F43131123 for <ace@ietfa.amsl.com>; Thu, 7 Jun 2018 06:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 bN9iUPodbyMM for <ace@ietfa.amsl.com>; Thu, 7 Jun 2018 06:55:17 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0E91310EC for <ace@ietf.org>; Thu, 7 Jun 2018 06:55:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C5D9B300A0C for <ace@ietf.org>; Thu, 7 Jun 2018 09:55:14 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oepTRFSVnNPK for <ace@ietf.org>; Thu, 7 Jun 2018 09:55:13 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 77214300A11; Thu, 7 Jun 2018 09:55:13 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <CE664422-ED4B-43FE-A531-4EAA090CA036@vigilsec.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F5530C32-9BA2-4AA2-9670-DEA62DCC1233"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 7 Jun 2018 09:55:19 -0400
In-Reply-To: <13635.1528327933@localhost>
Cc: ace@ietf.org
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <13635.1528327933@localhost>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/FEUvrCpA80a4iEDcO4es7uddHoI>
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 13:55:22 -0000

Michael:

These words were first used by IPsec; see RFC 4307.  They have gained broader acceptance.  I see no problem just using them here.

Russ


> On Jun 6, 2018, at 7:32 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> In draft-ietf-ace-coap-est, we would like to specify some mandatory to
> implement algorithms for DTLS.
> 
> We write:
>   The mandatory cipher suite for DTLS in EST-coaps is
>   TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the
>   mandatory-to-implement cipher suite in CoAP.
> 
>   Additionally, the curve secp256r1 MUST be supported [RFC4492]; this curve
>   is equivalent to the NIST P-256 curve.
> 
> And this is fine for now, but we'd like to signal that Curve25519 should be
> considered as an alternative, but we don't want to make it a MUST *today*,
> and we don't want to force implementations 15 years down the road that have
> it to include secp256r1.
> 
> IPsec(ME) has published things like: https://datatracker.ietf.org/doc/rfc8247/
> which include language like:
> 
>   SHOULD+   This term means the same as SHOULD.  However, it is likely
>             that an algorithm marked as SHOULD+ will be promoted at
>             some future time to be a MUST.
> 
>   SHOULD-   This term means the same as SHOULD.  However, an algorithm
>             marked as SHOULD- may be deprecated to a MAY in a future
>             version of this document.
> 
>   MUST-     This term means the same as MUST.  However, it is expected
>             at some point that this algorithm will no longer be a MUST
>             in a future document.  Although its status will be
>             determined at a later time, it is reasonable to expect that
>             if a future revision of a document alters the status of a
>             MUST- algorithm, it will remain at least a SHOULD or a
>             SHOULD- level.
> 
> I don't think TLS has done this... maybe TLS plans to.
> We think that we'd like to use SHOULD+ for Curve25519 and MUST- for
> secp256r1, but we aren't sure that the WG will like us to use so many
> words as IPsec to say so.
> 
> --
> ]               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