[TLS] Re: [EXTERNAL] Attestation and request for expediting the call for adoption of draft-reddy-tls-composite-mldsa

[Wang Guilin <[e-mail]>]

+1: Support to this request as well.

One comment: First of all, hybrid/composite offers conservative security in contrast to pure PQ solution, in the aspect of security of algorithm itself.

Guilin

发件人：Muhammad Usama Sardar <[e-mail]<mailto:[e-mail]>>
收件人：[e-mail] <[e-mail]<mailto:[e-mail]>>
时 间：2026-04-20 06:04:33
主 题：[TLS] Re: [EXTERNAL] Attestation and request for expediting the call for adoption of draft-reddy-tls-composite-mldsa


Hi all,

Despite a couple of my requests to move this discussion here, the discussion has unfortunately continued in the WGLC thread for ML-DSA. Anyway, I did some study, so I have a few cents to share:

I think the composition property we should try to achieve here should be:

  *   Endpoint Authentication holds as long as at least one of the two underlying keys is secret.
  *   (stated differently) Endpoint Authentication holds unless both underlying keys are lost.

This is a nice property because keys may leak independently. Now achieving this property may not be as easy (or difficult) as some of us think but the point is to get started.

---

Following up on a few comments (let me know if I am misunderstanding something):

I wonder what happens if some keys are in software and some in hardware; I guess we’ll find out.

I would expect that the two keys will be separately protected, e.g., one in TEE and the other in TPM/HSM. This way one of those may break independently without breaking the property. So the above property may be useful in such cases when you are dealing with highly regulated data (such as genomics and health data).

- When exporting the private key, exports from each device and concatenate the keys (and inverse for import)

I would expect that exporting private keys will have serious security concerns, e.g., exporting private keys out of TEE breaks all guarantees for confidential computing. I would like the design to not export the private keys -- at least not both.

However, draft-ietf-lamps-pq-composite-sigs says that a component key MUST NOT[1] be reused as a standalone key.  Implicitly this means that splitting the component keys across two devices is a Bad Idea, as one could trivially use a component key individually. Hence, Viktor's requirement of a single device is the right way to implement it.

That "implicitly" part was not my interpretation of draft-ietf-lamps-pq-composite-sigs. So I am very lost now. If both keys are in the same device, then what makes a single key leak and not the other one? Without this, I don't find the above property providing much value (and folks talking about tradeoffs might be thinking this way, or?).

I really hope I am misunderstanding "device." Is a TEE considered a single "device" here? Is TPM/HSM also a single "device" here? or is the system which contains a combination of TEE and TPM/HSM considered as a "device"?

So 1.3
deprecated TLS without certificates but not necessarily unauthenticated TLS,
depending on how philosophical you want to get about the definition of
"authenticated".

I have difficulty following this argument. To me, both are indistinguishable and there is no philosophy involved here because the (formal) threat model of TLS 1.3 assumes secure PKI, no? As I pointed out in another thread [0], if this threat model is not suitable for someone's use case, one may consider using attested TLS [1].

Best regards,

-Usama


[0] https://mailarchive.ietf.org/arch/msg/tls/Q6dXt6jMqpBuPJBhMb1CJsuM53U/

[1] https://datatracker.ietf.org/doc/draft-fossati-seat-expat/