On Sat, Jan 6, 2024 at 9:16 AM Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote:
> Hi Orie, > > > I am not sure whether the comparison between JOSE/COSE and TLS is > appropriate when the latter uses a handshake and the former is a one-shot > message (or a payload). > > In a TLS handshake there are so many things that get negotiated, such as > the algorithms and parameters for protecting the record layer (e.g. > TLS_AES_128_GCM_SHA256), the curve and parameters of the key share (e.g. > secp256r1), the digital signature algorithms (like ecdsa_secp256r1_sha256) > used in the handshake and the signature algorithm used for cerificates, > version, extensions and other features. > > On top of the above, the design has a long history and didn't radically > change from version to version (except for the cipershite that was changed > to separate the authentication and key exchange mechanism from the > symmetric key algorithm and hash function used at the record layer). > > > Hence, I am not sure what the benefit of aligning the registries are. To > me, this entire ciphersuite vs. à la carte discussion is largely a matter > of taste. > That's fine, except that when the registry is filled with mixed tastes, security considerations for each spec that depend on the registry will have to keep addressing this. It's trivial to get the best of both worlds... HPKE is à la carte: https://www.iana.org/assignments/hpke/hpke.xhtml MLS is ciphersuite: https://www.iana.org/assignments/mls/mls.xhtml#mls-ciphersuites If a protocol requires "à la carte" it requires a registry that supports that. If a protocol can support ciphersuites, it's my understanding it should prefer them to an à la carte registry... MLS could have used the HPKE registry directly. If a registry is consumed by multiple protocols, and contains a mixture of suites and à la carte, there will be considerations addressing this in every protocol that depends on the registry. > Ciao > Hannes > > PS: Regarding your question below about "I see that "ed25519(0x0807)," > could have been "eddsa_ed25519", and I assume "0x0807" actually means > "eddsa with ed25519", and "0x0808" actually means "eddsa with ed448". Since > these values are in the signature algorithm registry, those are could have > been prefixed with "eddsa". > Sounds like TLS 1.3 aligns with JOSE, and not with COSE.... Your signature algorithms are "fully specified". Sounds like the "EdDSA'' algorithm as used in JOSE and COSE does not align with TLS 1.3. > > Am 06.01.2024 um 15:49 schrieb Orie Steele: > > Hello, > > Apologies in advance for starting a thread about the proper way to name > things. > > We've been discussing the TLS naming conventions in relation to JOSE and > COSE naming conventions for suites. > > Here is the start of the full thread: > https://mailarchive.ietf.org/arch/msg/jose/66xvb1EgD-bf7V-XyAgDgRuUTJk/ > > We've been comparing "trends in suite names", between TLS, JOSE and COSE. > > For example, we see the following: > > /* ECDSA algorithms */ > ecdsa_secp256r1_sha256(0x0403), > ecdsa_secp384r1_sha384(0x0503), > ecdsa_secp521r1_sha512(0x0603), > > /* EdDSA algorithms */ > ed25519(0x0807), > ed448(0x0808), > > > In JOSE, ES256 means ~ " ecdsa_secp256r1_sha256(0x0403)," > In COSE, ES256 means ~ "ecdsa with some curve + sha256" > > In JOSE, EdDSA means ~ "EdDSA with some curve" > in COSE, EdDSA means ~ "EdDSA with some curve" > > This draft is in call for adoption, and argues for a convention: > https://datatracker.ietf.org/doc/draft-jones-jose-fully-specified-algorithms/ > > The convention is essentially, when we "name a suite", it should fully > specify all the parameters. > > "ecdsa_secp256r1_sha256" is fully specified... "eddsa" or "ecdsa with > sha256" is not (curve parameter is not specified). > > In the thread, Neil said that it is better to negotiate for > key (representations), instead of algorithms, and that TLS has been moving > away from fully specifying things. > > I see that "ed25519(0x0807)," could have been "eddsa_ed25519", and I > assume "0x0807" actually means "eddsa with ed25519", and "0x0808" actually > means "eddsa with ed448". > > I don't expect a hash function here, because I know SHA-512 is used > internally. > > Key representations in JOSE and COSE have parameters, and one parameter is > the "alg" field, which restricts the use of the key. > > In the case of a fully specified algorithm, this "alg" parameter contains > redundant information to the other key parameters. > In the case of a partially specified algorithm, this "alg" parameter > contains non redundant information (such as dsa and hash, there are curves > that support multiple dsas, and of course everyone has a favorite hash > function). > > Neil also made several compelling arguments not to adopt the draft because > fully specified identifiers for partially specified things are already > partially understood. > > Assuming we dropped new registrations, and just made recommendations for > how to specify algorithms, how might JOSE and COSE align our registry > guidance with the current thinking in TLS? > > Should we recommend against fully specifying things, and argue that > negotiation should be for keys, not algorithms, and keys can choose to > restrict to achieve full specification? > > Should we recommend fully specifying things, and then decide if redundant > code points should also be assigned, or if the guidance should just be > forward facing? > > Regards, > > OS > > -- > > > ORIE STEELE Chief Technology Officer www.transmute.industries > > <https://transmute.industries> > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
