Hi,
Recent discussions in 3GPP, ACE, and LAKE about the use of symmetric keys for
authentication and key exchange made me think about the future role of external
PSK in TLS.
https://mailarchive.ietf.org/arch/msg/ace/A60CFIvUohBwAXi_JuMKkQanZak/
I authored RFC 8442 because I believe PSK+ECDHE i
John Mattsson writes:
>Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
>especially psk_ke are both marked as RECOMMENDED. If used in the initial
>handshake, both modes have severe privacy problems,
PSK is used a fair bit in SCADA. There are no privacy problems there.
2020-09-19 13:48 GMT+02:00 Peter Gutmann :
> John Mattsson writes:
>
> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
> >handshake, both modes have severe privacy problems,
>
> PSK is used a
On Sat, Sep 19, 2020 at 06:00:00PM +0200, Filippo Valsorda wrote:
> Setting Recommended to N is not "banning" anything, it's saying it
> "has not been through the IETF consensus process, has limited
> applicability, or is intended only for specific use cases". SCADA
> sounds like a pretty specific
Eric Rescorla wrote:
ekr> As a thought example, consider a hypothetical TLS 1.4 which decided to
ekr> adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated
ekr> CH/SH in extensions in a stereotyped outer CH/SH. The system described
ekr> here would be unable to do a
On Sat, Sep 19, 2020 at 3:07 PM Michael Richardson
wrote:
>
> Eric Rescorla wrote:
> ekr> As a thought example, consider a hypothetical TLS 1.4 which
> decided to
> ekr> adopt QUIC-style obfuscation of the CH and SH, putting the
> obfuscated
> ekr> CH/SH in extensions in a stereotype
