I think this thread stems from a misunderstanding of what TLS is doing, and what "Ed25519" means.
> 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. This is the exact opposite of what TLS 1.3 has done. I see the JOSE email claims we've moved away from fully specifying things by citing the cipher suite change, but that is misunderstanding what changed. The SignatureScheme enum negotiates a signature algorithm, which then implies a key type. It used to be that this information was scattered. To see if a ECDSA key was viable in TLS 1.2, you had to look in... - Cipher suites, to see if there was a TLS_ECDHE_ECDSA_* - Supported curves, to see if P-256 was in there - EC point formats, to see if your point format was in there - Signature algorithms, to see if (ECDSA, SHA-256) (or some other hash your key supported) was in there. This was a huge mess. Especially when you consider that this key is a long-lived credential, and thus at the boundary between the TLS implementation and deployment-specific requirements (sticking keys in some hardware thing), this selection information often needs to be exported out of the library. TLS 1.3 does away with all this and collapses all the information into a *single* enum, ecdsa_secp256r1_sha256. Now, the email mentions cipher suites. We did indeed take the "ECDHE_ECDSA" half out of the cipher suite and left only the AEAD and the PRF hash. That was *not* about fully specifying things. Rather, it was about keeping atomic things atomic. "ECDHE_ECDSA" was not useful. "ECDSA" could not be evaluated without checking the above extensions. Likewise, "ECDHE" would not be evaluated without checking many of those same extensions. Once we shifted to SignatureScheme being the long-lived credential and NamedGroup (formerly supported curves) being the ephemeral key exchange, that partial information is redundant. In TLS 1.2, "ECDHE_ECDSA" served a second purpose, which was to say we were doing a Diffie-Hellman + signature handshake, not an RSA-key-exchange style handshake. However, it did so in a very awkward way. However, we removed the latter in TLS 1.3. Once that was gone, this information was completely redundant and only made negotiation more complicated. Thus, we removed it. Now, we could have decided that we actually like having a single enum, rather than a few orthogonal enums, and replaced SignatureScheme + NamedGroup with, a single "cipher suite" that specified (ECDSA-P256-SHA256, ECDH-P256, AES-128-GCM, HKDF-SHA256). That would have been more in keeping with the original (SSL3-era) naming of "cipher suite", and still satisfied the "keep atomic things atomic" goal. And perhaps having a single enum to specify the TLS settings would have been nice. (No one remembers there have been multiple configuration points in TLS.) However, for better or worse, TLS *already* eroded the "cipher suite" as a fully specified enum. I think it started with RFC 4492, which opted for a couple side extensions rather than putting the ECDSA and ECDH variant into the cipher suite. It would have been a *bigger* departure from TLS 1.2 to do that, than what we actually did. Thus, we stuck with the orthogonal enums model and finished the evolution started by TLS 1.2. > 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". When you say "Ed25519", it *already* implies EdDSA. EdDSA is a family of signature schemes. That is, it is a way to construct a signature scheme given some parameters. Ed25519 is a particular instantiation of that. Saying "eddsa_ed25519" would have been redundant, and would not match existing naming conventions. https://datatracker.ietf.org/doc/html/rfc8032#section-5.1 This separation between signature scheme and key type is mostly a historical quirk of older cryptographic algorithms being mis-specified. A key is a thing you get out of a signature scheme, not the other way around. Had we defined RSA and X9.62-style EC in a way that better matched formal expectations, there would have been no such thing as an "RSA" key. Rather, RSASSA-PKCS1-v1_5 would have been a family of signature schemes, and RSASSA-PKCS1-v1_5-SHA256 would have been a particular signature scheme. >From there, you could have had a RSASSA-PKCS1-v1_5-SHA256 key, which would have been a distinct animal from a RSASSA-PKCS1-v1_5-SHA384 key, or an RSAES-OAEP-SHA256 key. Likewise, ECDSA-P256-SHA256 would have been a completely disjoint algorithm from ECDSA-P384-SHA256 or ECDSA-P256-SHA384 or ECDH-P256. (And we probably wouldn't have wasted our time defining all hash/curve pairs.) However, RSA and X9.62-style EC weren't defined that way. Instead we have an "RSA" key and an "EC" key that can be used with all manner of algorithms, nevermind that not all pairs of algorithms have been analyzed to work well together. (Although, realistically, it is usually fine, sometimes it's not, and gaps between formal analysis and practice are one of the places we get security bugs.) And as a result of that, systems put too little effort into key management and misdirected that effort into picking different algorithms within a key, despite that being much less theoretically sound. For the RSA and EC world, we're kinda stuck with that. And so although TLS negotiates a SignatureScheme, the most specific thing, we handwaive a bit because sometimes one key may be used with multiple SignatureSchemes. However, we still do not have a "key type" enum, and it would be harmful to introduce one in TLS. It's important to collapse all the information needed for key selection into a single enum. In TLS 1.2, the information was scattered (see above). For anything defined after RSA and EC,like Ed25519, there is no reason to keep this handwaiving. If, say, it turns out we need to replace the hash function in Ed25519, or change EdDSA, we would not use the same keys. We would simply define a new signature scheme, with a different name, and say that this is a completely disjoint key type. So, to your original question, specifying EdDSA is incoherent because EdDSA is not a signature scheme, or a key type. It is a family of signature schemes, which may be instantiated by specifying a pile of parameters <https://datatracker.ietf.org/doc/html/rfc8032#section-3>. Once instantiated, it is given a name like "Ed25519", and that is the thing that systems like TLS or JOSE or COSE should work in. The fact that Ed25519 and Ed448 are both EdDSA instantiations, or that the X25519 algorithm and the Ed25519 algorithm have a similar structure are just useful properties when analyzing, specifying, or implementing a primitive. It is not relevant to protocols that *use* a primitive. As far as we're concerned, these are just names that conform to the signature scheme interface (KeyGen() -> (pk, sk), Sign(sk, msg) -> sig, and Verify(pk, msg, sig)). David On Sat, Jan 6, 2024 at 9:49 AM Orie Steele <orie@transmute.industries> wrote: > 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 list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
