Hi folks,I sincerely apologize to all, in particular Uri to whom I was replying. Respecting the call from a senior member to stop, I'll post this final email on this topic to address the misunderstandings and then stop. If someone is interested in constructively contributing to the formal modeling work, please reach out to me off-list.
On 10.04.26 23:32, Salz, Rich wrote:
*
So Physics is some rocket science which cannot be represented by
math, right? Is that the reasoning here?
No. Mixing “physics” and “physical” is a mistake; they are not the
same thing.
Whatever way we want to call "real-world mechanisms" as physics or physical, I don't think it matters in the point I was trying to make. I just meant the real world mechanisms (which includes quantum physics etc.) are /always/ more complex than the models. We make models to understand the complexity of the real world. I believe that's the whole purpose of models.
If we were to deal with and fully understand the reality of the real world, TLS WG will really be insufficient. We need quantum physics specialists to explain how all of ML-KEM works. We need hardware experts to tell us about how the hardware works on which TLS is going to run. Hardware itself already too complex. And not only a single hardware but all possible set of hardware that TLS will be used anywhere in the world. Now imagine the complexity.
PKI infrastructure and then provisioning and so on... how to even model that? Like, how trust is established between CA and requester? We always make abstractions in the formal models, like in this case that somehow keys are magically provisioned at the point in time where we start analysis.
Without abstractions and assumptions, these alone will bloat up all the things that we won't be able to do anything productive and useful.
Sorry that was my auto-corrector at work. I intended to write Physicists (as in experts in quantum physics).Physicians is yet a third thing that is not the same as either.
It’s clear where you stand. You have threatened to appeal if the WG does not share your view.
I would like to clarify that the "if" hypothesis above is not correct; it was [0]
if I feel that the final draft ignores critical security considerations or puts the community at significant riskwhich was because I believe not mentioning the risks is a disservice to the community. I have clarified that I am doing the formal analysis and I have shared some of my current working with properties in [1]. Ekr is right that I have some simplifying assumptions. Like, we make several abstractions and assumptions in the formal analysis for Appendix F.1 of TLS 1.3 too, but I will see how I can improve my model. I will appreciate any further feedback and l hope to have substantial analysis to be presented at IETF 126. I would like folks to provide constructive feedback like Ekr has provided to move things forward.
Nico has provided some useful hints in the thread. I don't think we need to know whether ECDHE is more secure or ML-KEM is more secure. I am trying to formulate a property on the lines of:
Hybrid is at least as strong as the stronger of ECDHE and pure ML-KEM.So we might not need to have circular discussions on which one is stronger. This will surely have some assumptions, but we have to start somewhere rather than those circular discussions.
Many of your recent messages have been about language issues, like trying to argue that NIST implies the IETF should use MUST NOT.
I would like to clarify that there appears to be a confusion of threads. I have no strong opinion on ML-DSA. My preliminary view opposed it but many of my concerns have been resolved, and I am pretty much close to what I can live with for publication.
On the other hand, I have a strong opinion on this ML-KEM which is the topic of this thread.
Please stop.
sorry, last one for sure.
Please stop asking for “authentic references.”
sorry. Regarding the request for reference, I thought an authentic reference would help to come to an agreement. I keep hearing costs, but no evidence is provided on costs. I don't know how else we can come to an agreement but I'll stop asking.
Best regards, -Usama [0] https://mailarchive.ietf.org/arch/msg/tls/q4nNjdrGrJv-4s1JYVHz41WJ2Go/ [1] https://mailarchive.ietf.org/arch/msg/tls/g4lCSltMQQY8xHdJdtjTvudTMes/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
