> -----Original Message-----
> From: ilariliusva...@welho.com <ilariliusva...@welho.com>
> Sent: Thursday, October 24, 2024 1:03 PM
> To: <tls@ietf.org> <tls@ietf.org>
> Subject: [TLS] Re: ML-DSA in TLS
>
> On Thu, Oct 24, 2024 at 03:51:50PM +0000, Tim Hollebeek wrote:
> > 3. Composite is slightly more complicated, though not as complicated as its
> > detractors claim. However, since composite signatures are not
> standardized
> > yet, I think they shouldn't be dragged into the 'pure' discussion. They
> > can
> have
> > their own draft and thread, like Diedre noted.
>
> I don't agree with composite signatures being slightly more complicated.
> I think that composite signatures are much more complicated, and that I am
> underestimating the complexity.
I'm sorry, but I have a really hard time buying this 'composite signatures are
hugely complex' argument. For hybrid, the validation check is essentially:
if conventional_signature_validates && pq_signature_validates
accept the signature
Now, at least in the transition time, we need both conventional and pq
signature routines, hence I can't see how those routines count as additional
complexity (because we need them anyways).
The only complexity I see added are:
- Something to initially hash the message (at least, in the current
LAMPS proposal)
- Something to parse the hybrid public key into its components
- Something to parse the hybrid signature into its components
- The AND operation
Is there some complexity there? Yes, a little. However, I cannot see how that
is an unprecedented amount; certainly, less than Deidre's idea of 'let's open
up the crypto and smash the two sides together'.
And, BTW: the AND operation is externally testable (by the simple expedient of
passing in a hybrid signature with one signature incorrect).
That said, if the working group thinks that it is better to modify the TLS
protocol to accept two certificates (and generate two signatures with the two
public keys), that is reasonable - it could facilitate easier transitions from
an operational standpoint (and then later a transition to a pure PQ solution
once a CRQC becomes a reality, and the classical half is no longer useful).
>
> For hybrid KEMs, I think slightly more complicated would be fair, as long as
> one keeps away from more complex stuff.
>
>
> > I strongly oppose the "we have some time" sentiment, though. There are
> > ecosystems that are slow to transition due to long approval timelines
> > and the desire to do rigorous analysis and discussion, and some of
> > them are starting to make transition plans now. The lack of IETF
> > guidance on some of these topics is starting to be a blocker now that NIST
> algorithm specifications are complete.
> >
> > In the absence of standards, they will just do their own thing, and
> > we'll end up with lots of unnecessary diversity and "interesting" design
> choices.
>
> I think that the only quantum-safe signatures that are currently ready-to-go
> are ML-DSA and SLH-DSA. These have already seen rigorous analysis.
>
> AFAIK, hybrid signatures have not seen rigorous analysis, and that should
> predate IETF guidance.
Possibly because the analysis would be too trivial to publish an academic paper
on? If you can generate a forgery of 'ECDSA signature || ML-KEM signature',
then you can obviously generate a forgery of 'ML-KEM signature'.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
