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

Benjamin Kaduk <> Thu, 07 June 2018 13:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 232FE1310CC for <>; Thu, 7 Jun 2018 06:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1pPi3x0Z6s0v for <>; Thu, 7 Jun 2018 06:49:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA673130E06 for <>; Thu, 7 Jun 2018 06:49:13 -0700 (PDT)
X-AuditID: 1209190d-571ff70000007a29-c4-5b1937d86502
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 60.BC.31273.8D7391B5; Thu, 7 Jun 2018 09:49:12 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w57DnBoU023967; Thu, 7 Jun 2018 09:49:11 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w57Dn72G018881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jun 2018 09:49:10 -0400
Date: Thu, 07 Jun 2018 08:49:07 -0500
From: Benjamin Kaduk <>
To: Michael Richardson <>
Message-ID: <>
References: <13635.1528327933@localhost>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="HKEL+t8MFpg/ASTE"
Content-Disposition: inline
In-Reply-To: <13635.1528327933@localhost>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA2VSbUgTYRznuTv1tnbj2ant2cwPTj+UsZkhZlERRbGkoIIgXGCnO91wO8fd HE4CF64EFbWPjqBcS0VtqKFGGsaIoiQoFSeFDCrETdD1ZiSk3Tl8gb79/r+3Pw/Pn8TpQJKW tHJOlucYmy5ZTtCy9Gz93BGN6dDMYl7R79UWvKgl1JZyCjMGAn8wo/feOH4JK5EfN7M2q4vl 807ekFs2NkaSHAvqWn98gvCANboJyEgEC9DQ917QBOQkDR9iKDg6mpIYBgBq7BomEsMMhj7O twApQsAcdKfhQ7KEk0XsaZ7GJZwGDaj75YLoIUkcQhQPl0l0KixEcyuRzSglbuuYbMckCw33 I9/f/AStQm86vhISxqELhfvbiURLBupeJyVaBg+g6an7mITTYTZ63hpKaQfQtyvt25X27aQT dC6aW49i/9EHUVfnEp7AJ1AwuEI8ACm9INNsr9PbGatNYMv1QjnDcSyvP2ywW50G1lwzBDY/ QEM9BevzxSEASaBTUJ6I2kQnMS7BbQ8BDYnp0il/NjLRyrJqs9vCCJZSvsbGCiGQI+76PND3 HmgJrppjdWkUM7XXRFNmxl3H8tVbtgyS0KmpKj8w0bCScbJVLOtg+S11H0nqEDVZqDHRKp6t ZGsrrDbnjoyRshBApEIsj0keSnAwdsFamdDfgiytmqqXBCgJlhpuOysdF6qauBkDavFZqVRY cinE09tOx8RiTCw24pvFTmZH0nqA98Xp2dffmKtBVbF9ZWj53erlzNyiY/5lZVv98E9Hz93w 4pdPj/1Zt7znf/RHFOOpz7rj/OCY8ehaM3a2tMQ1eKaJXuavRS8s1TemqTo7PRXeaPnYnnOB ivj18Z7Bi1eKDSOR1RGDxd01+6gvHOVuZ8aU3o1fsd4nBQblq4ZWHSFYmPxcnBeYf8Yiodc3 AwAA
Archived-At: <>
Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jun 2018 13:49:18 -0000

On Wed, Jun 06, 2018 at 07:32:13PM -0400, Michael Richardson 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:
> 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.

Unfortunately, I'm not a big fan of the "+/-" variants of RFC 2119
keywords.  It seems more clear to me to actually write out in prose
the current situation and future expectations.  So, if you do end up
going this route, please ensure that the shepherd writeup includes a
justification of why it was chosen.