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
Eric Rescorla 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
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
Hannes Tschofenig 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
Russ Housley 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
Olaf Bergmann wrote:
> Michael Richardson 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?)
AFAIK, Curve25519 is about the
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:c...@tzi.org]
Sent: 07 June 2018 18:40
To: Hannes Tschofenig
On Jun 7, 2018, at 18:30, Hannes Tschofenig wrote:
>
> 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
___
Ace mailing list
Ace@ietf.org
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
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 wrote:
>
>
> In draft-ietf-ace-coap-est, we would like to specify some mandatory to
> implement
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
Hello Michael,
Michael Richardson 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
___
12 matches
Mail list logo
