Whilst I don’t know Peter, my intervention in San Francisco on this topic was
on the same line.
Am working with the CISO teams of organizations that have to keep their
infrastructure for 50 to 100 years long plans (nuclear power stations,
hydraulic infrastructures, etc.).
And among organizatio
Stephen:
>
>> I've been thinking about your point. Some people want to use RFC
>> 8773 to protect data that is transmitted today and recorded from the
>> future invention of a quantum computer. To do this, the handshake
>> includes the identifier for the external PSK, and an observer can get
>>
>
> I think there is a companion point to be made. I suggest:
>
>Implementations must use a ciphersuite that includes a symmetric
>encryption algorithm with sufficiently large keys. For protection
>against the future invention of a CRQC, the symmetric key needs to be
>at least 256
Hiya,
On 13/12/2023 13:18, Bas Westerbaan wrote:
Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's
deployable, and whether its performance is acceptable, is something we
should figure out.)
I guess we're just interpreting "as-is" differently. What I
meant by "as-is" was a
>
> PS: I do not want us to hold up producing the ECH RFC while
> we figure that out - we should get the current thing out the
> door first!
>
Completely agree.
Bas
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi Ilari, thanks for the clarification!
I attempted to correct the text.
Would you be willing to review the change? It's here:
https://github.com/richsalz/tls12-frozen/commit/a1ce7ede97897e291af44f0c2f4fc225a2ca4447
thanks,
Nimrod
On Tue, 12 Dec 2023 at 19:22, Ilari Liusvaara
wrote:
> On Fri,
Bas:
Thanks. I've adjusted the proposed text to address your comments:
Implementations must use a ciphersuite that includes a symmetric
encryption algorithm with sufficiently large keys. For protection
against the future invention of a CRQC, the symmetric key needs to be
at least 12
On 12/12/2023 2:50 PM, Stephen Farrell wrote:
Hiya,
On 12/12/2023 17:08, Russ Housley wrote:
Stephen:
I've been thinking about your point. Some people want to use RFC
8773 to protect data that is transmitted today and recorded from the
future invention of a quantum computer. To do this, t
On Wed, Dec 13, 2023 at 10:29 AM Christian Huitema wrote:
>
> Doing a PQ version of ECH would be hard. On the other hand, doing an
> 8773-like enhancement to ECH should not be all that hard. It would
> require that the outer CH contains a PSK shared between the client and
> the fronting server, a
> By contrast the PQ version "just" has key size issues to worry about
> with the DNS advertising bits and maybe some structures that get
> tight.
>
I have the same intuition. Instead of guessing, we should plop Kyber in ECH
and see if it works.
If not then there are still other paths besides PSK
sgtm
On Wed, Dec 13, 2023 at 4:36 PM Russ Housley wrote:
> Bas:
>
> Thanks. I've adjusted the proposed text to address your comments:
>
>Implementations must use a ciphersuite that includes a symmetric
>encryption algorithm with sufficiently large keys. For protection
>against the
Stephen Farrell wrote:
> That'd be a fairly giant outer client hello
Well, is there a latency histogram?
The reality I've seen ignored in these discussions is that these large
handshake messages are in fact very slow or broken on older
implementations, but that it might not matter.
The very slo
12 matches
Mail list logo
