[TLS] The future of external PSK in TLS 1.3
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 is needed for legacy systems. Due to the major privacy, security, and deployment limitations with PSK, I see little need to use PSK (besides resumption) in new systems, except for the use case in RFC 8773. LAKE recently removed PSK authentication completely as it does not produce smaller messages and comes with severe privacy and deployments problems. Increasing code size (a few kB) and slightly increased computation/latency was not seen as a big problems. 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, and psk_ke does not give PFS, thus making pervasive monitoring much easier. If groups keys are used, additional security problems arise. All TLS 1.2 cipher suites without (EC)DHE has for good reasons been marked as NOT RECOMMENDED. I have recently seen several people arguing that the inclusion of PSK in TLS 1.3 means that the use external PSKs are now recommended. I don't think that was the intension of the TLS WG. I strongly think psk_ke should be NOT RECOMMENDED, except for resumption. Irrespectively of what ‘Y’ in the recommended column actually means, people are and will read it as recommended to use. Cheers, John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] The future of external PSK in TLS 1.3
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. So just because there's a concern for one specific environment doesn't mean it should be banned for any use. In particular, I think if a specific industry has a particular concern, they should profile it for use in that industry but not require that everyone else change their behaviour. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] The future of external PSK in TLS 1.3
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 fair bit in SCADA. There are no privacy problems there. So > just because there's a concern for one specific environment doesn't mean it > should be banned for any use. In particular, I think if a specific industry > has a particular concern, they should profile it for use in that industry but > not require that everyone else change their behaviour. Indeed, if the SCADA industry has a particular need, they should profile TLS for use in that industry, and not require we change the recommendation for the open Internet. 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 use case. I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke wouldn't be marked N like all suites lacking PFS.___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] The future of external PSK in TLS 1.3
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 use case. > > I don't have a strong opinion on psk_dhe_ke, but I see no reason > psk_ke wouldn't be marked N like all suites lacking PFS. Is there actually a problem here? "Nobody" is using external PSK "on the open Internet", because, perhaps not surprisingly, you need to have a pre-shared key for that. Thus, browsers and the like just don't have pre-shared keys with each and every web-server the user might direct them at. By the time external PSK (i.e. not resumption session tickets) is actually in use, we're already well outside the use cases where we're protecting the privacy of Joe-consumer using commodity software. Perhaps in the IoT space one can envision some device "calling home" to the manufacturer or supplier in a manner that identifies the device slightly more than just the source and destination IP addresses, ... but I don't see this as motivating a compelling need to change the registry. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
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 anything useful with that, which creates ekr> pressure to block TLS 1.4 entirely, which obviously is not awesome. >> >> I believe that without a mechanism described in this document, many >> enterprises may conclude that they need to block TLS 1.3. >> > Perhaps you mean some hypothetical TLS 1.4? No, I do mean 1.3. Many enterprises still think that they can stop it. Are they winning? probably not. >> We don't have to have the client provide it, it can be encoded by the >> manufacturer in the MUD file, assuming that it depends upon the model, not >> some local decision in the client. > Sorry, yes. I meant "client" in the sense that the client tells the > middlebox what rules to use. Whether it does so directly or by reference to > the manufacturer doesn't seem to matter too much for these purposes. okay. >> The idea of having a WASM file is an >> interesting one, but being an executable of a sort, it has other security >> problems. > Well, one always has to worry about the security of processing data one > receives from the network, but I'm not sure that the distinction between > the kind of DSL we're talking about here and an executable is really that > sharp. The argument for WASM or something like it is that there has Such as DSL would have to limit the number of cycles it is allowed to consume, otherwise the middle box might have to solve the halting problem :-) BPF could be another model. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
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 stereotyped outer CH/SH. The system > described > ekr> here would be unable to do anything useful with that, which > creates > ekr> pressure to block TLS 1.4 entirely, which obviously is not > awesome. > >> > >> I believe that without a mechanism described in this document, many > >> enterprises may conclude that they need to block TLS 1.3. > >> > > > Perhaps you mean some hypothetical TLS 1.4? > > No, I do mean 1.3. Many enterprises still think that they can stop it. > Are they winning? probably not. > Can you say more about this? While during previous transitions clients would "fall back" to lower versions of TLS, both Chrome and Firefox (and I imagine Edge and Safari but I have less information) do not do so. As a result any middlebox which blocks 1.3 will effectively cause failures on any site which offers 1.3, which seems like it would cause a lot of problems. > >> The idea of having a WASM file is an > >> interesting one, but being an executable of a sort, it has other > security > >> problems. > > > Well, one always has to worry about the security of processing data > one > > receives from the network, but I'm not sure that the distinction > between > > the kind of DSL we're talking about here and an executable is really > that > > sharp. The argument for WASM or something like it is that there has > > Such as DSL would have to limit the number of cycles it is allowed to > consume, otherwise the middle box might have to solve the halting problem > :-) > BPF could be another model. > Agreed. I know BPF less well but my understanding is that it has gotten quite powerful. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
