+1 to shipping it.
On 11/03/2024 22:00, Joseph Salowey wrote:
This is the working group last call for TLS Encrypted Client Hello
[1]. Please indicate if you think the draft is ready to progress to
the IESG and send any comments to the list by 31 March 2024. The
comments sent by Watson Ladd t
On 14/03/2024 01:41, Deirdre Connolly wrote:
Oh and one more consideration: hybrid brings complexity, and
presenting the pure-PQ solutions and their strictly lesser complexity
(at the tradeoff of maybe taking more risk against newer schemes no
matter how good we feel about their fundamental cr
I have a suggestion which keeps things technical but hopefully addresses
Stephen's concern:
In Security Considerations:
"TLS1.3 requires the use of forward secret key exchanges (RFC 8446, 1.2,
E.1). Using SSLKEYLOGFILE breaks this security property as it records
the used session key and so in
I would argue adding `ML-KEM` as a standalone NamedGroup is not more
complex than adding ECDH groups, the hybrid part is the already complex
part. To minimize complexity even more, one can 'just' do the X-Wing style
of having a hybrid NamedGroup that doesn't know anything about the other
available
(not speaking as a chair of anything here)
The IETF, together with the IRTF, needs to make an independent judgement
on whether using PQ-only algorithms is advisable, and if we do not think
so, then we should not standardize them, regardless of what CNSA 2.0
requires. The supported groups regist
On Wed, Mar 13, 2024 at 8:40 PM Raghu Saxena wrote:
>
> On 3/14/24 00:45, Eric Rescorla wrote:
> > There are two questions here:
> >
> > 1. What the specification says
> > 2. What implementations choose to do within the envelope of that
> > specification.
> >
> > The specification needs to prescr
I do not believe that "decode_error" would be the correct alert. As the
text currently says:
*Failures* Some post-quantum key exchange algorithms, including
ML-KEM, have non-zero probability of failure, meaning two honest
parties may derive different shared secrets. This would cause a
There was a push to change the parsing logic for ML-KEM public keys to
never fail, by silently reducing, without changing the hash of the public
key. I am not sure if NIST ended up adopting that change for their final
standard (I hope they did, I think it's the best way to handle this
problem), whi
Whoops, I copy-pasted the wrong section, this is the definition for
'decrypt_error':
> decrypt_error: A handshake (not record layer) cryptographic
operation failed, including being unable to correctly verify a
signature or validate a Finished message or a PSK binder.
On Wed, Mar 13, 2024, 10:
Good points. I've included these notes in the GitHub tracking issue, and
will leave the document as-is for now.
On Thu, Mar 14, 2024, 3:41 PM Sophie Schmieg wrote:
> There was a push to change the parsing logic for ML-KEM public keys to
> never fail, by silently reducing, without changing the ha
On Thu, Mar 14, 2024 at 5:53 AM Deirdre Connolly
wrote:
> I would argue adding `ML-KEM` as a standalone NamedGroup is not more
> complex than adding ECDH groups, the hybrid part is the already complex
> part. To minimize complexity even more, one can 'just' do the X-Wing style
> of having a hybri
Reasonable statement. It's a variation on what we already have, but the focus
on forward secrecy is worth a small paragraph:
How about this: https://github.com/tlswg/sslkeylogfile/pull/7/files
On Thu, Mar 14, 2024, at 22:51, Dennis Jackson wrote:
> I have a suggestion which keeps things technic
12 matches
Mail list logo
