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

Hi Russ, Hi Michael,

why don't you just reference https://tools.ietf.org/html/rfc7925?

I am not a big fan of making all sorts of different crypto recommendations in our specs that differ slightly.

Ciao
Hannes

PS: Next time someone suggests the use of a new crypto algorithm I will demand that they also implement one themselves.

-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Russ Housley
Sent: 07 June 2018 15:55
To: Michael Richardson
Cc: ace@ietf.org
Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST

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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.