Dear Deirdre,
Could say a little more why both 'key exchange' and 'key establishment' have
been excluded?
>The naming of the document excluded 'key exchange' and 'key establishment',
>and went with 'key agreement', but that is a weakly held name,
Thanks,
Guilin
__
Hi,
Isn't this issue already in "RFC 9325 - Recommendations for Secure Use of
Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS)"? (BCP 195)
https://www.rfc-editor.org/rfc/rfc9325.html#section-4.1
So, that's IETF consensus. It's easy to find things that still do this, bu
I see two possibilities:
1. Nobody in the real world employs static DH anymore – in which case this
draft is useless/pointless; or
2. On private networks people employ static DH to implicitly authenticate
their peers (a-lá MQV) – in which case this draft is harmful.
Overall, I’m amazed b
On Sat, Apr 20, 2024 at 04:12:48AM +, Peter Gutmann wrote:
> I realise that absence of evidence != evidence of absence, but in response to
> my previous request for anyone who has such a thing to comment on it, and even
> better to send me a sample so I can see one, no-one has mentioned, or
>
Pull requests
-
* tlswg/draft-ietf-tls-esni (+0/-0/💬2)
1 pull requests received 2 new comments:
- #614 Correct `ECHConfigList` length bounds (2 by ctz, davidben)
https://github.com/tlswg/draft-ietf-tls-esni/pull/614
Repositories tracked by this digest:
---
