Re: [TLS] PSK in 1.3?

["Christian Kahlo" <[e-mail]>]

BTW: We're using TLS_ECDHE_RSA_PSK_WITH_AES_256_CBC_SHA384 on a

custom code point for a couple of years now. Works well - even in customer

infrastructure with SPI firewalls.

 

BSI TR-03116-4 requires TLS1.2, EtM (RFC7366) and PFS. For some cases PSK is

needed as a three-party cryptographic binding. When I saw how lazy RFC7366

standardization was in this WG I just skipped talking about and we decided to

fulfill the requirements out-of-IETF-standard. It's sufficient if we rely on the

basics such as versions, record format, supported minimum, interoperable

cipher suites for non-internal infrastructure communication.

 

But maybe this is a pointer how to support PSK-PFS in TLS1.3+. I could provide

pseudo code from the key exchanger part. We would really appreciate PSK-PFS

as a public standard.

(No, we don't reveal source code of those projects. But we could add it to

i.e. BouncyCastle.)

 

Best regards,

Christian

 

 

Von: TLS [mailto:[e-mail]] Im Auftrag von Sven Schäge
Gesendet: Donnerstag, 19. Februar 2015 16:41
An: Dan Harkins; [e-mail]
Betreff: Re: [TLS] PSK in 1.3?

 

I was just reading through the TLS-PSK related discussions so far and came across your post...

 

2014-10-20 14:13 GMT+02:00 Dan Harkins <[e-mail]>:


On Sun, October 19, 2014 7:35 am, Yoav Nir wrote:
>
> I also understand that in practice, PSK ciphersuites are used only by
> small devices, whereas the web and SMTP and other things never went for
> it. But the standards don’t say that. They don’t say that PSK
> ciphersuites are especially for constrained devices. So if we insist that
> the same TLS 1.3 be used for both, and we don’t want to say that PSK is
> for weak security, then we should have a good story of why PFS is not
> needed for PSK uses, whereas it’s essential for all RSA uses.  If I
> understand the mechanism correctly, PSKs tend to be long-lived, and a
> subsequent compromise of a PSK (even if it is expired at the time of
> compromise) allows an attacker to decrypt the content of a TLS session.

  The non-PFS PSK ciphersuites are no different than the widely
discredited, and easily cracked, WPA-PSK mode of WiFi security. It would
be a really bad idea to continue with these ciphersuites in TLS 1.3. But the
issue is not just PFS (or the lack of it), it's that PSK ciphersuites are
susceptible to dictionary attack.

> So either we believe that PSK compromise is unlikely, or we believe that
> the data in a connection with a PSK ciphersuite is not future-sensitive.
> If we don’t, we’re saying that we’re just piling on security
> nice-to-haves because we think the users can handle them.

  There's no way that the protocol can be defined to justify that belief.
What you're talking about is how people end up using the protocol and
that is entirely out of the power of this WG. What we can do is to make
TLS be as _misuse resistant_ as possible. And to do that we should not
allow PSKs in TLS 1.3 unless they are used in a PAKE.

  By the way, I'm surprised that no one is expressing outrageous outrage
at the lack of a security proof for PSK ciphersuites.

 

 

Perhaps you might find 

 

http://eprint.iacr.org/2014/037

 

useful.

 


  regards,

  Dan.



_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls

 

Many greetings,
Sven