[TLS] Weekly github digest (TLS Working Group Drafts)

[Repository Activity Summary Bot]

Pull requests
-
* tlswg/tls13-spec (+0/-0/5)
 2 pull requests received 5 new comments:
 - #1334 Tracking by replaying a flight of 0-RTT data (4 by ekr, emanjon, 
martinthomson)
   https://github.com/tlswg/tls13-spec/pull/1334 
 - #1333 Privacy and PSK identifiers (1 by martinthomson)
   https://github.com/tlswg/tls13-spec/pull/1333 



Repositories tracked by this digest:
---
* https://github.com/tlswg/draft-ietf-tls-semistatic-dh
* https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate
* https://github.com/tlswg/draft-ietf-tls-esni
* https://github.com/tlswg/certificate-compression
* https://github.com/tlswg/draft-ietf-tls-external-psk-importer
* https://github.com/tlswg/draft-ietf-tls-ticketrequest
* https://github.com/tlswg/tls13-spec
* https://github.com/tlswg/tls-flags
* https://github.com/tlswg/dtls13-spec
* https://github.com/tlswg/dtls-conn-id
* https://github.com/tlswg/tls-subcerts
* https://github.com/tlswg/oldversions-deprecate
* https://github.com/tlswg/sniencryption
* https://github.com/tlswg/tls-exported-authenticator
* https://github.com/tlswg/draft-ietf-tls-ctls
* https://github.com/tlswg/external-psk-design-team
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Suite Naming Conventions

[Orie Steele]

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 
wrote:

> On Sat, Jan 6, 2024 at 12:23 PM David Benjamin 
> 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 

Re: [TLS] TLS Suite Naming Conventions

[David Benjamin]

On Sat, Jan 6, 2024 at 12:23 PM David Benjamin 
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 

Re: [TLS] TLS Suite Naming Conventions

[David Benjamin]

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 

Re: [TLS] TLS Suite Naming Conventions

[Orie Steele]

On Sat, Jan 6, 2024 at 9:16 AM Hannes Tschofenig 
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, 

Re: [TLS] TLS Suite Naming Conventions

[Salz, Rich]

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

Strongly agree.  TLS is an online protocol; the others are not.

Perhaps the LAMPS (neé spasm) working has opinions, since JOSE at all are more 
like CMS than TLS.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Suite Naming Conventions

[Hannes Tschofenig]

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.


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


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 STEELEChief Technology Officerwww.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

[TLS] TLS Suite Naming Conventions

[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


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls