Re: [TLS] ML-KEM key agreement for TLS 1.3

[Orie Steele]

Does the argument about hybrid code points first generalize to all PQ Code
points?

Is it equally true of hybrid signatures?

I don't understand why registering composite components first wouldn't be
assumed.

Isn't support for the component mandatory to support the hybrid anyway?

Let's assume CRQC drops tomorrow, why did we not register ML-KEM first?

Assume it never drops, you still needed to implement ML-KEM to use the
hybrid.

If the goal is to prohibit ML-KEM without a traditional component, just
register it as prohibited.

OS

On Wed, Mar 6, 2024, 10:10 PM Bas Westerbaan  wrote:

> Back to the topic at hand. I think it'd very bad if we'd have a codepoint
> for pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process
> wise, I think that's up to the designated experts of the IANA registry.
>
> Best,
>
>  Bas
>
>
> On Wed, Mar 6, 2024 at 3:16 AM Deirdre Connolly 
> wrote:
>
>> I have uploaded a preliminary version of ML-KEM for TLS 1.3
>> 
>> and have a more fleshed out
>>  version to
>> be uploaded when datatracker opens. It is a straightforward new
>> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
>> very similar style to -hybrid-design
>> .
>>
>> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
>> compatible) ready to go when users are ready to use them.
>>
>> Cheers,
>> Deirdre
>> ___
>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Trust Expressions Follow-up

[Orie Steele]

Thanks for your thoughtful reply.

Inline:

On Sat, Mar 2, 2024 at 9:21 PM David Benjamin  wrote:

> Hi Orie,
>
> Thanks for the note! I'm not very familiar with the SCITT work, so I can't
> speak to it directly. But perhaps I can try to describe what we're trying
> to achieve for TLS, and that might help you determine whether it applies to
> SCITT?
>
> We're looking here to address problems caused by single-certificate
> deployment models in TLS. In an ecosystem where one server may serve many
> diverse clients (ranging from evergreen browsers, to decade-old TV set-top
> boxes) with different requirements, that deployment model results in a ton
> of conflicts as the PKI evolves to meet user security needs. The first
> message in this thread, and this document
> <https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md> try
> to describe the problem and goals a bit.
>
> TLS, being an online protocol, lends itself well to negotiation-based
> solutions (we do it for cipher suites, etc.), where the server has multiple
> certificates available and then somehow the client and server are able to
> determine which to use. Trust expressions aim to provide that "somehow".
> The manifests business is purely a supporting structure to get there, since
> we need to be able to succinctly describe what are fairly large lists of
> trusted CAs in many PKIs. If there isn't an analogous deployment problem or
> online protocol in SCITT, the work probably isn't directly applicable.
>

I think the SCITT analog here is managing code signing certs when trying to
verify a software bill of materials that covers both public and private CAs.


> I didn't quite follow the transparency service comments (this may be my
> unfamiliarity with SCITT again), but this draft isn't trying to change PKI
> structure. Or rather, it isn't trying to do so directly. Having a robust
> negotiation mechanism *enables* us to explore structural changes. I do
> think that will be valuable, as post-quantum dramatically changes some
> trade-offs here. (Signatures and keys are now *huge*.*)* E.g. there's the
> intermediate elision use case you noted. But that one isn't related to
> transparency and is simply observing that intermediate elision and
> short-lived trust anchors are the same thing.
>

This sorta lines up with the current solutions for short lived certs seen
in the wild today, such as Sigstore.

Is proving possession of an email address good enough to sign software?

What about scenarios with MFA, CI systems with certificates for each build
server, with HSM keys... etc.

It seems that there might be some conceptual alignment on "these certs for
this name, on these timescales", even if the certs are used for different
things.

SCITTs focus is to provide an access controlled audit log for details
related to the software supply chain.

I'm still trying to wrap my head around how
draft-davidben-tls-trust-expr maps to the CT use case (
https://datatracker.ietf.org/doc/rfc9162/), or how they might be related in
an ideal setting.

It seems like SCITT Receipts for a trust expression manifest might be a
thing, assuming you are trying to reason about which trust store manifests
that are used by a 3rd party, without the ability to talk to them
directly... Perhaps that's a "SCITT can help you audit how a trust store
was used" use case... or... maybe trust expressions help SCITT auditors
make quick sense of SCITT Receipts from PKIs that have aging identities
co-mingled with new ones, which seems to be common in software supply
chains.


> We do have another draft, draft-davidben-tls-merkle-tree-certs, which
> explores a much more differently structured PKI, aiming to fit with how the
> Web PKI currently does transparency. Though we wrote that draft first and
> have not yet had time to rebase it atop trust expressions. There are
> probably other data points in this design space too, and I hope certificate
> negotiation will help us find the right ones for various use cases.
>

 Skimming the draft you mentioned, perhaps this is also a point of overlap
between your 2 drafts and the SCITT architecture:

https://datatracker.ietf.org/doc/html/draft-davidben-tls-merkle-tree-certs-01#section-10.3

You might build a "Merkle Tree certificate", using a SCITT transparency
service, since a SCITT receipt is logically an inclusion proof for a single
certificate,

A "signed feed of receipts" can be thought of as an intermediate data
structure for Merkle tree certs... possibly... I need more time to digest
the draft.

Thanks for your comments.


> David
>
> On Fri, Mar 1, 2024 at 6:39 PM Orie Steele 
> wrote:
>
>> I found the CDDL in the appendix intriguing:
>>
>>
>> https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-e

Re: [TLS] Trust Expressions Follow-up

[Orie Steele]

or to all
>>> clients. This wastes bandwidth, particularly with post-quantum
>>> cryptography, where every signature costs kilobytes. Additionally, an
>>> individual server operator cannot unilaterally configure this. Cross-signs
>>> apply to entire intermediate CAs, not just the individual server’s
>>> certificate.
>>>
>>> There’s more to say on this topic, as relieving this conflict solves
>>> many other PKI problems and enables new solutions for relying parties, CAs,
>>> and subscribers. We discuss some of these in the use cases
>>> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-use-cases>
>>> section. But hopefully this helps clarify our goals and is a starting point
>>> for discussion.
>>>
>>> We’d be interested to hear thoughts on these issues or others. Our hope
>>> is to reach enough consensus on the list to determine whether it would make
>>> sense to have a call for adoption around Brisbane.
>>>
>>> Thanks,
>>>
>>> David
>>>
>> ___
> TLS mailing list
> TLS@ietf.org
> https://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

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Orie Steele]

Hybrids by their very nature are the explosion.

If there will only ever be X-Wing, I think it's fine to not make it generic
(since we admit that it is a special case, not an instance of a generic).

However, if B-Wing (brainpool + kyber) and P-Wing (p curve + kyber) also
end up getting made, we never stopped the explosion, and we made it harder
to evaluate the security properties, and we delayed the rollout against
harvest and decrypt... for the cases where X-Wing could not fit.

Yes, we will need proofs for all those other hybrids, sounds like that will
keep people busy for a while... It feels like promising false hope to say
that making X-Wing not generic will stop all that other work from
happening... If anything, making X-Wing generic will reduce the cost of
doing the work, that seems inevitable at this point.

I do think it's important for this to not end up as "crabs in a bucket",
where each candidate holds the others back, and then they all get cooked
together.

If arguing over generic's causes that, I suggest we not make generics a
requirement.

OS




On Thu, Jan 11, 2024 at 1:35 PM Sophie Schmieg  wrote:

> I very much appreciate having a concrete hybrid scheme that is
> intentionally not generic. This avoids the explosion of ciphertext suites
> that would otherwise occur, and allows for better compatibility of
> libraries. Fixing the key sizes to ML-KEM 768 and X25519 is aligned with
> our preferred choices as well, and further increases interoperability.
>
> On Thu, Jan 11, 2024 at 9:31 AM Salz, Rich  40akamai@dmarc.ietf.org> wrote:
>
>> I'm going to echo Bas to highlight that X-Wing is not generic to any
>> IND-CCA KEM, it is a particular primitive construction based on the
>> internal construction of ML-KEM in particular:
>>
>>
>>
>> I don’t think it’s our place to try to shoe-horn everything into one
>> construct.  Particularly when we are in the experimentation phase of things.
>>
>>
>>
>> If people want to have ML-KEM as a material in their composites, it
>> sounds like they might want to learn from X-Wing, but not try to chop them
>> to fit into that one keyhole, as it were.
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> --
>
> Sophie Schmieg | Information Security Engineer | ISE Crypto |
> sschm...@google.com
>
> ___
> CFRG mailing list
> c...@irtf.org
> https://mailman.irtf.org/mailman/listinfo/cfrg
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Suite Naming Conventions

[Orie Steele]

cheme, 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 
>> 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
>>>
>>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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, t

[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

<https://transmute.industries>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls