Uri Blumenthal writes:
> D. J. Bernstein writes:
> > Filippo Valsorda writes:
> > > Because "a nominal group and a ciphertext collision resistant KEM" is
> > > not "any two KEMs"
> > How is the above dividing line supposed to interact with the stated
> > harm scenario? Why won't implementors in both cases want to be
> > "flexible" and "agile" and so on, leading to "more and more poorly
> > understood and tested combinations"?
> Because of the simple fact that in the stated scenario "KEM" choice is
> constrained by possession of certain listed properties?
I agree that asking for a KEM to be "ciphertext collision resistant"
(plus of course IND-CCA2) is a constraint on the choice of KEM. But how
is the stated scenario of
(1) some implementations exposing the combiner, and
(2) applications using "a different combination", leading to
(3) "more and more poorly understood and tested combinations"
supposed to be prevented by the fact that there's a constraint on the
choice of KEM? And why is asking just for the standard IND-CCA2 goal
(which is also a constraint) _not_ supposed to prevent this scenario?
To be clear, I find #1+#2+#3 plausible for other reasons---and am forced
to conclude that the current X-Wing design is unnecessarily dangerous:
* The modules in typical cryptographic libraries come from common
software-layering practices that have nothing to do with security
and that I'd expect to produce some instances of #1.
* The elephant in the room---the fact that NIST picked a KEM in the
middle of a patent minefield---provides a clear incentive for #2,
whether #2 is supported by #1 or handled by itself.
* #3 will be a default consequence of #2. Maybe #3 can be stopped,
but I'm skeptical.
* Once we're in situation #3, the "ciphertext collision resistant"
constraint is a security risk. Maybe all KEMs in use fortuitously
meet the constraint, but we have no reason to assume they will, so
we're in uncharted waters.
Even without that risk, this constraint is asking security reviewers to
investigate something they wouldn't otherwise have to investigate.
We can, at negligible cost, make the combined KEM safer and easier to
review by having the combiner hash the full transcript (the same way
that TLS moved to hashing the full transcript, but of course the goal
here is to have something that's safe far beyond TLS). What's the
contrary argument supposed to be?
There continue to be unquantified suggestions that the hashing is a cost
issue (e.g., "significant"). I've given numbers showing that the hash
cost is around 1% of the communication cost.
There were various complaints about exposing parameters to applications
(e.g., "leaking heavily parameterized algorithms up into the
cryptography interface"). None of the proposals at hand (X-Wing; my
recommended modifications to X-Wing; Chempat-X) are doing that.
I'm still hoping for clarification of the latest messages. I think the
messages are trying to argue that the parameters will (or "more likely"
will?) _indirectly_ be exposed because the difference between
(A) a combiner that reaches its security goals given any IND-CCA2 KEM
and
(B) a combiner that reaches its security goals given any "ciphertext
collision resistant" IND-CCA2 KEM
will somehow make the difference between #1+#2+#3 happening and not
happening. But, again, I don't see the mechanism that's supposed to
make the A-B distinction trigger #1+#2+#3. Meanwhile there's much more
clear damage done if we pick unnecessarily fragile mechanism B and then
#3 occurs for other reasons, such as the reasons predicted above.
https://www.imperialviolet.org/2018/12/12/cecpq2.html commented that
CCA-vs.-CPA was a "subtle and dangerous" distinction. How should we
imagine that implementors are going to notice the even more subtle
distinction between A and B, let alone taking action on that basis? If
the answer is supposed to be that implementors will see and heed
warnings in a spec using B: Why shouldn't such warnings be just as
effective in a spec using A, which has the giant advantage of protecting
the implementors who _aren't_ paying attention to the warnings?
Filippo Valsorda writes:
> it was argued that modularity should be the dispositive reason to
> choose universal combiners, even despite modest performance
> disadvantages.
No. I stated various reasons for modifications to X-Wing, and then my
email dated 16 Jan 2024 15:24:57 -0000 gave a numbered list of four
reasons "for assigning responsibility to the combiner rather than to the
underlying KEM". I stand by all of those reasons; I did not say that one
of those was "the dispositive reason". Narrowing the list to just one
entry understates the weight of the full list. This weight could affect
decision-making if there's ever a substantiated counterargument.
Also, regarding the change in cost, I don't believe the word "modest"
captures the strength of the original wording ("negligible"; "tiny") or
of the quantification backing up that wording.
In general, to reduce the risk of error and to help readers track the
discussions, please use quotes.
---D. J. Bernstein
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
