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

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 <mcr+ietf@sandelman.ca> wrote:
> 
> 
> 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 =-
> 
> 
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace