Hi folks,
I was just reading draft-ietf-tls-deprecate-obsolete-kex-01.txt
and the combination of Section 3 and Appendix C is confusing
to me.
Specifically, the text says:
Clients and servers MAY offer fully ephemeral FFDHE cipher suites in
TLS 1.2 connections under the following
> I don't have details, but the NVMe/TCP specification suggests that it can
> make use of multiple PSK identities during a TLS handshake.
>From my read of NVMe spec, it's one PSK/identity per TLS connection:
"8.13.5.9 Generated PSK for TLS
When used with a non-NULL DH exchange, the DH-HMAC-CHAP
Hi! We have tentatively been scheduled for Wednesday at 1300-1500 (Tokyo Time):
https://datatracker.ietf.org/meeting/116/agenda
The final agenda will be posted tomorrow.
I am forwarding this in case you missed the original call for agenda items for
the TLS WG’s session. Thanks to those who have
> On Mar 1, 2023, at 11:29 PM, Peter Gutmann wrote:
>
> Chuck Lever III writes:
>
>> We're implementing TLSv1.3 support for PSK and note there is a capability in
>> the PSK extension described in S 4.2.11 for sending a list of identities. We
>> don't find support for a list of alternate
On Tue, Feb 28, 2023 at 2:18 PM Lanlan Pan wrote:
> Personally I think, the negotiation may cause the downgrade security risk,
> making PNE not actually work for privacy protection.
> The hardware acceleration can support both PNE and plaintext packet number.
> Maybe we can consider assigning a
