Re: [TLS] TLS Suite Naming Conventions

[Orie Steele <[e-mail]>]

Thanks for your detailed response!

I agree with everything you wrote, but especially these parts:

> A key is a thing you get out of a signature scheme, not the other way
around.

And this part:

> 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)).

I struggled with these concepts until I found this directionality most
consistent with safe use:

key-gen (signature type) --> private-key --> public-key --> signature
(signature type)

Serializations of keys and signatures can contain hints about these types,
but it is the named interface that ensures the security properties, not the
hints we see in serializations.

This applies to both "alg" and "kid" hints in the context of JOSE and COSE.

The draft in question is essentially trying to give guidance on how to name
future signature scheme interfaces, summarizing what we have learned from
years of naming and encapsulating (with varying degrees of success)
signature scheme interfaces.

OS


On Sat, Jan 6, 2024 at 11:54 AM David Benjamin <[e-mail]>
wrote:

> On Sat, Jan 6, 2024 at 12:23 PM David Benjamin <[e-mail]>
> wrote:
>
>> 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
>>
>
> Since I suspect this is where some of the confusion comes from, let me
> point something out from RFC 8032: Ed25519 is *not* an elliptic curve in
> the way that P-256 is. RFC 8032 uses edwards25519 to refer to the elliptic
> curve in Ed25519. This is a name you've probably never seen used because it
> is an implementation detail of Ed25519. When using the primitive, you don't
> actually care how it is defined, just the name (Ed25519) and interface.
>
> Now, sometimes people are a bit sloppy and say "Ed25519" to mean the
> curve. The original Ed25519 paper didn't formally give a name to the curve
> itself, and if you know you're talking about an elliptic curve instead of a
> signature scheme, this is unambiguous. There's only one curve in Ed25519,
> realistically, we'll probably never instantiate another signature scheme
> with that curve. SHA-512 is fine. But due to the history of people trying
> to separate key and use (always a mistake), it's helpful to have precise
> names for individual components when this confusion comes up.
>
> The fact that P-256-based primitives leak their parameterization is a flaw
> in how we defined those primitives, not an analogy to apply to other
> schemes. We should move away from that as much as possible. This is
> analogous to how the X.509 work shifted from a heavily parameterized in
> draft-ietf-curdle-pkix-00 to distinct top-level OIDs in RFC 8410..
>
>
>> 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 <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>