I agree with Stephen on this one and would not support adoption of non-hybrids.
There is no reason to not work on things like preventing key reuse at the ISE.
A question to the authors:
The draft talks about "users that need to be fully post-quantum".
Can you please give a specific example of suc
> That’s easy to answer: “many of our members have very hardware-constrained
> PoS devices.” Is that okay?
Some context:
Kyber requires several KB of RAM space according to [1], figure 1:
KG = KeyGen, E=Encaps, D=Decaps, H=Heap, S=Stack
Alg | KG(H) | KG(S) | E(H) | E(S) | D(H) | D(S)
> For comparison, [2] is an implementation of Curve25519 using no heap space.
> On an ATmega128, it uses 462 bytes of stack space for a curve multiplication.
Small correction: Almost no heap space :)
It uses three 32-byte constants which could be reconstructed dynamically.
Those being: The numbe
> This sounds like you are not objecting to adoption, but objecting only
> to publication as is? No consensus call for moving this document forward
> as is (eg WGLC) has been requested for this document yet. It is expected
> to be discussed in the WG, and I encourage everyone to propose text
> This is misleading. There are many implementations of Kyber that require
> much less memory. See eg [1] from 2019 where Kyber-512 only requires 2736
> bytes.
Thank you. Somehow I missed this, although the use of a reference
implementation seemed suspicious.
> By the way, for key agreement,
> It might be fine to adopt this only for publication as Experimental.
There is actually another option for those that just want a stable reference.
Quoting from draft-ietf-tls-rfc8447bis:
> D: Indicates that the item is discouraged. This marking could be
> used to identify mechanisms that
I am sorry for interrupting your argument, but as you are discussing this
on-list:
> My previous email explained the obvious way the consensus was validly called.
> This
> can be independently verified by anyone reading the email thread. The
> fact that you are the only one questioning the c
> Hi! At IETF 122, the chairs took a sense of the room about whether to
> progress draft-ietf-tls-keylogfile. There was consensus to do so [0]. We need
> to confirm that on-list. If you disagree with the consensus please let us
> know, and why. We close this call at 1159 UTC on 29 April 2025.
I
> Step0: we have this existing deployed thing we want to document.
As I wrote in [1], republishing without adding considerations and guard rails
is already bad.
> I think it is an interesting idea to use the KEYLOG format to help
> debugging of other security protocols. I think easy debugging he
> I disagree with this because if an attacker could write to the environment
> variable used by the program or is able to side-load a library and capture
> outbound packets, it is very likely that they already have privileged
> access to the machine.
I am questioning the threat model. Just like Pe
Hello,
I have just become aware of this draft and I believe there might be a good
cautionary addition I would like to propose:
Specifically, I am worried that with further encouragement to standardize this
format, it will become a convenient way to surveil unsuspecting end users. All
this requ
> Some things should not be standardized.
The problem is that there is a longing for such standardization.
And not just at the IETF. The idea of the draft is, after all, to republish a
"de facto standard" already implemented by many applications and debugging
helpers alike. Someone had the need
> I think we should abandon this effort and not publish.
>
> When initially proposed this was supposed to be documenting a
> deployed reality. I could just about hold my nose with that,
> but adding in ECH (for which key exfiltration is not currently
> deployed, nor seemingly needed) and the IANA
> The connection is secure. TLS doesn't defend against compromised devices.
I disagree. While the *network* connection itself may inhibit the rather
technical notions of confidentiality and integrity, this is not what the
average user would consider a "secure connection". Staying with a browser
> I believe that adopting the draft will allow those who
> wish to use pure PQC (for whatever reasons they may
> have) to do so while at the same time not in any way
> impacting anybody else who doesn't want to do that.
Those who wish to use pure PQC do not need permission. This is about IET
> I think this discussion should be moved to a separate mailing list. The
> current discussion is not technical and has very little to do with the TLS WG.
I agree that the discussion is not technical. However, the underlying issue is,
so once the AD(s) and the complainant get to the contents of
Hello together,
I have just opened a pull request related to the hybrid vs. non-hybrid
discussion, to highlight a possible compromise. For those who prefer mail, I
have included the PR description below.
Best,
-- TBB
- BEGIN PR -
This PR is an attempt to strike a balance between
- t
Hi everyone,
I have a question about draft-ietf-tls-ecdhe-mlkem. Some context:
ECDHE can be performed over any suitable elliptic curve, and different curves
have different tradeoffs.
Focusing on KEX mentioned in RFC8446, Section 9, the (MUST support) P-256
provides benefits in terms of complian
> I think this PR should mention risks introduced by hybrid solutions as well
> – which (obviously) differ from those introduced by non-hybrid.
Mentioning them is certainly a good idea. Perhaps it makes sense to be specific
as to what is compared:
- I would consider hybrid methods beyond ietf-
Jan Schaumann was kind enough to remind me that I forgot to include a link to
the PR.
Thanks, and Apologies :-)
Here it is: https://github.com/tlswg/draft-ietf-tls-mlkem/pull/6
-- TBB
smime.p7s
Description: S/MIME cryptographic signature
___
TLS mail
20 matches
Mail list logo
