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

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Jun 2018 19:32:13 -0400

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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Jun 2018 07:18:04 +0200

Hi Michael,

On Jun 7, 2018, at 01:32, Michael Richardson <[email-masked]> wrote:
> secp256r1,

Sounds good to me.

> but we aren't sure that the WG will like us to use so many

Can we just reference those words?

Grüße, Carsten

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 07 Jun 2018 11:06:41 +0200

Hello Michael,

Michael Richardson <[email-masked]> writes:

> Curve25519 should be considered as an alternative

As we had this discussion at IETF-101 regarding the profile coap_dtls:
What where your reasoning for Curve25519? (Especially vs. Ed25519?)

Grüße
Olaf

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 7 Jun 2018 08:49:07 -0500

>              MUST- algorithm, it will remain at least a SHOULD or a

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.

-Ben

---

From: Russ Housley <[email-masked]>
Date: Thu, 7 Jun 2018 09:55:19 -0400

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 <[email-masked]> wrote:
> 
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Jun 2018 16:30:08 +0000

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:[email-masked]] On Behalf Of Russ Housley
Sent: 07 June 2018 15:55
To: Michael Richardson
Cc: [email-masked]
Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST

Michael:

Russ

> 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/

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.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Jun 2018 18:40:07 +0200

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

That describes the status of mid-2016.

Can we do something forward-looking?

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Jun 2018 16:50:40 +0000

In products crypto does not change that fast given the lifetime of IoT devices and the hardware support for it. Our customers are asking for NIST certified crypto.

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: 07 June 2018 18:40
To: Hannes Tschofenig
Cc: Russ Housley; Michael Richardson; [email-masked]
Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Jun 2018 13:11:33 -0400

> What where your reasoning for Curve25519? (Especially vs. Ed25519?)

AFAIK, Curve25519 is about the PFS/key-agreement.
Ed25519 is about authentication of the end-points, and depends upon what's
in the certificates (if any are used) to validate the end points.
CoAP-EST does not say anything actually about authentication; i.e. how we
get the Secure Transport.  It's out of scope for this document.
(But, in scope for draft-ietf-6tisch-dtsecure-zerotouch-join )

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Jun 2018 13:14:40 -0400

Russ Housley <[email-masked]> wrote:
    > These words were first used by IPsec; see RFC 4307.  They have gained
    > broader acceptance.  I see no problem just using them here.

Yes, but they aren't in an RFC2119-like document that we can simply cite, and I'm
not sure if the TLS reviewers will like them.  Ben doesn't like them for instance.

I would probably just write:
  SHOULD+/SHOULD-/MUST- are used in the same way as in RFC8247

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Jun 2018 13:41:17 -0400

> 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.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Jun 2018 13:20:35 -0700

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.

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Jun 2018 17:26:59 -0400

> 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.

    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 8 Jun 2018 07:10:21 +0200

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 <[email-masked]> wrote:
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Jun 2018 06:56:30 +0000

Here are my thoughts:

·       This group or any other IoT group should not come up with their own algorithm recommendations. Reason: we already have a group working on these recommendations - CFRG

·       There is no need to talk about new algorithms recommendations. Reason: the recommendations have already been made by the CFRG and the TLS 1.3 spec lists them.

·       The pace of switching to new crypto algorithm seems to be much slower in the IoT world (for the discussed reasons). I feel there is very little most of us can do to influence the pace. Reason: very few folks work on implementations of crypto algorithms for IoT devices.

Ciao
Hannes

From: Eric Rescorla [mailto:[email-masked]]
Sent: 07 June 2018 22:21
To: Michael Richardson
Cc: Hannes Tschofenig; [email-masked]
Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST

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.

-Ekr

On Thu, Jun 7, 2018 at 10:41 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Ignorance :-)

Section 4.4 includes:

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/        |   ruby on rails    [

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Jun 2018 11:07:45 -0400

We have written:

+    <t>
+      As per <xref target="RFC7925" /> section 3.3 and section 4.4, the
+      mandatory cipher suite for DTLS in EST-coaps is
+      TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in <xref target="RFC7251"/>,
+      and the the curve secp256r1 MUST
+      be supported <xref target="RFC4492"/>; this curve is equivalent to the
+      NIST P-256 curve.   Crypto agility is important, and the
+      recommendations in <xref target="RFC7925" /> section 4.4 and any
+      updates to RFC7925 concerning Curve25519 and other CFRG curves also applies.

https://github.com/SanKumar2015/EST-coaps/commit/94812c98492b6a6b0440155025357fa0b58ca017?diff=split

We had a discussion about whether section 4.2 (PSK) and 4.3 (RPK) also
applies, and in general they do, but we don't understand the
use cases that would result in that usage.
(Is it PSK, or EAP-SIM for for instance?)