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 [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
