Hi Bas,
On 4/26/26 11:07, Bas Westerbaan wrote:
Hi Jake,
Adding reference to composites in this PR: https://github.com/tlswg/
tls-mldsa/pull/32
Will you also expand the draft to encompass the larger discussion around
hybrids in the language of the PQ/T composites draft?
There is no value in deploying
PQ if both ends don't support the same thing, and installing 20
certificates is not practical.
Practicality seems rather subjective or at least highly
contextual. Most of the HTTPS infrastructure would be impractical
without the automation that is already in place. It is natural to
extend that automation to cover this kind of problem as well,
isn't it?
There are many other server operators on this list with an
enthusiasm for automation and not breaking their target audience.
Let's hear from them.
Agreed.
If browser vendors want to work everywhere, they'll likely need to
support a set of cryptography that is global.
If everyone would accept all composites, then we can just pick one
at random. We can't because some are not acceptable to everyone.
I would not pick one at random. If everyone had implementations for all
possible options, wouldn't we still want to rank choices by some kind of
preference?
Isn't it better to rank them by a security metric? For example in the
language choice of the composite draft: A (null cipher or a) null
signature should probably rank at the absolute bottom, a Trad or Rad
option above the bottom, and a hybrid, that is a PQ/T construction,
would be above the PQ or Trad used in isolation.
The security value of the ranking would depend a great deal on the
threats as a Trad option such as ECC alone isn't going to rank too far
above the null signature when the adversary has a quantum computer if
breaking ECC keys has a low (economic, energy, etc) cost.
If that's because of security then it's important to note that the
verifier sets the policy: it's what the browser accepts that
determines security, not what the server installs. Hence, if there
is fragemtation because of security concerns, then we must have
browsers that accept some composites and not others.
I don't agree that it is the verifier that sets the policy. At least not
alone, and it certainly isn't in a vacuum. The specifications require a
baseline that must be implemented to be compliant. That baseline removes
discretion for developers building software such as servers or clients
if they want to be compliant verifiers. The protocol specifications that
define the client and server possibilities are setting the stage. That
means that the policy possibilities are set by the available set of
choices in the standard(s).
After the standard, server implementations and server configuration
defines the space of available options that are acceptable to the
server. The client is constrained by the developer effort and then the
server's set. A specific connection's security is then constrained as
you say by the verifier's preference for using one element in the
overlapping set. Jumping to the end there is a disservice to users who
eventually suffer the consequences of switching to a radically new thing
without taking a cautious approach, a similarly cautious approach that
hybrids provide for encryption.
Not all implementations will implement everything. Not all servers will
offer what is implemented. Not all clients will implement everything. I
think that we agree generally about these things.
The draft in question from my perspective is an encouragement. It
promotes choices that are beneath a risk tolerance that has already been
set using hybrids for encryption. Signatures have their own set of risks
similar to but not entirely equal to the encryption discussion.
As with encryption, non-hybrid signatures are an unnecessary risk. PQ/T
is a reasonable baseline, PQ alone is not. If a verifier's policy is
risky, either the verifier is implementing a risky standard or it is
non-conformant. There are no protocol police, so someone who wants a
footgun is free to shoot themselves in the foot any time. Users who
don't know better should be protected by the standards, and ideally
conformant implementations should make that protection the practical
baseline.
My position is different. I do not mind a large number of
variants, I care about the diversity of the variants, and other
design factors. The primary and most important goal is to actually
achieve security.
Your browser is only as secure as the weakest variant you accept.
I note that one surprising difference in assumptions here is about
applications using TLS. The phrase "The Internet is more than the world
wide web" comes to mind. This draft isn't limited only to the web, right?
Thus adding diversity decreases security.
A corollary is that we're only as secure as the weakest variant that the
server advertises while maintaining standards compliance. Related is
that sometimes the set won't overlap and there will be a denial of
service due to a lack of agreement on what constitutes security; this
may or may not be considered a negative outcome.
Noteworthy is that since we are discussing a server having a weak
baseline, impersonation sure seems like it can do a lot of damage
to security. Lots of energy has been spent on redirecting the discussion
to the category of Harvest Now, Decrypt Later attacks, but little energy
has been spent on describing what happens when Impersonate Now,
Impersonate Later attacks are possible. This is why I said that the
security section of the document is lacking.
Readers worried about the threat of quantum computers need to better
understand the security tradeoffs that the draft currently omits.
Personally, I am a fan of diversity. I do not believe that it has been
shown in this discussion that diversity decreases security. A set of
diverse choices is perhaps as weak as the weakest variant that overlaps
between the client and server where a connection is established, and
this is also true when the set only has one element. The issue in either
case is having elements that are below an acceptable threshold.
Doesn't this indicate to you that the weakest element in that MUST be in
either set should be hybrid (e.g.: PQ/T) constructions and not a
non-hybrid PQ?
In draft-ietf-lamps-pq-composite-sigs the authors use the term
Trad for
Traditional which is amusing and it fits. It seems that it would be
nice
if they also used the term Rad for the new, hopefully post-
quantum, cryptographic primitives.
That's pretty funny :).
Naming things is hard, naming then meaningfully is harder, and making
the name meaningful and amusing is harder still...
One of the considerations is related to raw RNG outputs as I
mentioned in my NIST comments that I cited in my previous email. I
trust that you've read my comment to NIST[0] but if not, please
consider doing so.
I trust you've also seen my comment on the same forum on the same
matter on April 29, 2023, hence it puzzles me you bring it up.
If you mean the email where you wrote "We will not remove that hash, and
prefer it not to be removed from the standard." - yes, I have seen it.
I am unclear on how you (Cloudflare) will deal with the patent control
issues as raised by many to NIST. Will your company pay for a
license if the worldwide NIST license doesn't apply, I wonder? Or did
you disagree that it would even be needed? The latter would be
especially interesting.
The other issued raised in my comment still apply but are otherwise
unaddressed. I understand that we generally share a similar conclusion.
Thus it appears that we have a disconnect around some of the reasoning
steps that proceed general agreement about a course of action up to a point.
Another perhaps more interesting consideration is to have
geopolitical diversity.
I'd like to stay away from discussing malicious motivations as that
makes productive work difficult.
Recently while talking with a technical person from an organization in
Europe that is an analog to NIST, they expressed that they only look at
the issue with the tools in their toolbox. They know that their work is
ultimately related to protection of say, everyday citizen's privacy, but
that they don't really enjoy looking at the big picture. They expressed
some genuine self-reflection by remarking that they didn't like the
uncertainty of working with concepts or tools that are unfamiliar. That
is of course very understandable, but also, it may be unreasonable if it
impacts the security outcomes. If I were a user impacted downstream, I
would be unhappy with the process and the result.
I suppose that I am somehow able to empathize with and understand this
sentiment regarding interest in problems where one has the tools.
Unfortunately, I understand it as an unreasonable conclusion. It appears
as a rejection of the responsibility of security engineers for security
outcomes, and especially for how those security outcomes impact the
wider society.
From an engineering perspective, I find it lacking systematic rigour.
Do attackers care about what we like? Do they plan attacks around those
preferences and then exploit them? What would we do in their shoes with
their job requirements?
If I understand your preference, you wouldn't like to be asked or
required to answer something like "is it a malicious motivation that
NIST doesn't require hybrids while other organizations do recommend and/
or require hybrids?"
To accommodate your preference, lets change the framing because as it
just so happens, we don't need to understand motivations to discuss
qualitative conclusions and outcomes.
Consider that geopolitical diversity need not be speculative about
motivations. Here is one example: risk tolerance. Risk tolerance
decisions need not be malicious. There are obviously other factors at
play including but not limited to a lack of competence in the area of
basic risk management or even an agreement about what risks need to
be addressed as risks.
Instead we can ask: "Of the different geopolitical entities involved,
who recommends or requires a risk tolerance choice that meets the needs
of all other parties involved?"
Isn't the notion of geopolitical diversity as described directly tied to
productive work? Isn't avoidance of addressing these issues a part of
why we have failed to achieve consensus?
Argument by dismissal seems to be a core dynamic of many IETF
discussions, especially those which drag on. A lack of systematically
addressing concerns in a documented manner with transparency is how
other organizations at least attempt to settle these contentious
matters. The IETF could set a baseline of hybrids, and it would save us
all a lot of time.
I do hope you considered privately the question what an actor would
do that would have a keen interest in delaying the adoption of PQC.
Sure, I addressed that in my comment too:
"Delays: Other countries have already completed standardization of post-
quantum cryptography. A lack of absolutely clear security metrics for
security evaluation and a very slow standardization process are
problematic. The delay in standardization has slowed and even stalled
deployment of post-quantum cryptography. Mass surveillance adversaries
have access to many more ciphertexts that will forever remain
unprotected in the quantum adversary model. These delays are avoidable
by having clear guidelines for all metrics, including public
explanations or calculations of any NIST provided results, scheduling
fixed dates in advance for key events over shorter periods of time, and
publishing specific guidelines to assist with encouraging further
cryptanalysis"
At this point, one delay, perhaps the primary delay, is the repeated
introduction of non-hybrid proposals that require a tremendous amount of
energy to resist. But on that, I think we sadly disagree. How does the
joke go? "Be reasonable and see things my way!"
Kind regards,
Jacob Appelbaum
Best,
Bas
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
