Due to the existence of GREASE ECH, for requests made by clients that have
implemented ECH but do not have a suitable ECH Config, the server always fails
to decrypt and can choose to send retry config.
Why not treat this an opportunity to upgrade Plaintext Hello to ECH(if
certificate verificatio
Okay PRs are ready to merge:
https://github.com/tlswg/rfc8447bis/pull/61
https://github.com/tlswg/rfc8447bis/pull/62
And I found some typos:
https://github.com/tlswg/rfc8447bis/pull/63
Will merge Sunday (when submission window re-opens) and spin a new version,
unless you say otherwise.
spt
> O
> On Mar 7, 2025, at 12:51 PM, Sean Turner wrote:
>
>> Section 5 TLS Cipher Suites Registry
>>
>> This section contains some reasoning why it is Discouraging things. The
>> current
>> IANA registry also contains such reasoning on the form of notes, but this
>> section
>> does not add to the
Hey David,
Thanks for the draft! I had some thoughts about how Relying Parties build their
list of Trust Anchor IDs to send to the Authenticating Parties. In the draft
currently there is different behaviour by the Relying Party depending on
whether it is a retry connection or not.
When a relyi
Peter C writes:
> In ML-KEM, Bob derives b deterministically from m and H(ek).
> If Bob tried to reuse b with a different public key, then the
> re-encryption check would fail during decapsulation.
That check doesn't affect processing of valid ciphertexts, so it often
won't be tested, so some impl
Hi Usama,
The title of this email is quite alarming to me ("identity crisis") and
yet I'm not able to understand what the actual issue is other than
someone wishing to replace public-key authentication with "attestation".
Personally, I wouldn't do that.
Although TLS PKI authentication involv
Viktor Dukhovni writes:
> I'd expect such designs to be quite unlikely
That's different from "not possible". :-)
I agree with your API comments: one can't build this by simply calling
the FIPS 203 standard keygen-enc-dec functions for ML-KEM. However, if
that were the end of the story then we wou
Just a quick reminder that this adoption call is still ongoing.
spt
> On Feb 28, 2025, at 1:56 PM, Sean Turner wrote:
>
> In response to the WG adoption call, Dan Bernstein pointed out some potential
> IPR (see [0]), but no IPR disclosure has been made in accordance with BCP 79.
> Additional
On Fri, Mar 7, 2025 at 7:01 PM Kris Kwiatkowski wrote:
> May I know if you have a plan for FIPS certificaton for PQC after release?
>
Absolutely - OpenSSL-3.5 will be heading into a fresh FIPS140-3 validation
in April once the release is final - and that will include the PQC
algorithms that have
Adopt
On Mon, Mar 10, 2025 at 7:59 AM Sean Turner wrote:
>
> Just a quick reminder that this adoption call is still ongoing.
>
> spt
>
> > On Feb 28, 2025, at 1:56 PM, Sean Turner wrote:
> >
> > In response to the WG adoption call, Dan Bernstein pointed out some
> > potential IPR (see [0]), but
Internet-Draft draft-ietf-tls-rfc8447bis-11.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.
Title: IANA Registry Updates for TLS and DTLS
Authors: Joe Salowey
Sean Turner
Name:draft-ietf-tls-rfc8447bis-11.txt
Pages: 17
11 matches
Mail list logo
