Subject: [TLS] PSK in 1.3?

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sun, 19 Oct 2014 11:30:47 +0200

Hi,

Sorry if this was discussed previously and I missed it, but I was wondering
about the fate of PSK in TLS 1.3. The RSA and (EC)DH key exchanges were removed
because they do not offer forward security. PSK does not offer FS either. OTOH,
it has very interesting performance properties, namely it's the only key
exchange that does not require asymmetric crypto.

It seems to me it makes a lot of sense to keep it, even if it doesn't give FS.

The reason I'm asking this now is the parallel discussion about new handshake
flows and possibly proving them secure. If we're keeping PSK, maybe it's good to
keep it in mind in this discussion, since it may have different properties than
(EC)DHE for the proofs/security discussion.

Manuel.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Oct 2014 12:44:16 +0100

Thanks for the reminder.

I've been assuming we would keep it and trying to bear it in mind as I think
about design, but it's good to see this stated explicitly.

-Ekr

On Sun, Oct 19, 2014 at 10:30 AM, Manuel Pégourié-Gonnard <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 19 Oct 2014 15:33:12 +0300

> about design, but it's good to see this stated explicitly.

Some notes about PSK in TLS 1.2:

- TLS 1.2 has PSK identity hints. These are fundamentially 2RTT if used.
- PSK without identity hints is still 2RTT in TLS 1.2, but is not fundamentally
  2RTT (send identity in ClientHello).
- TLS 1.2 PSK requires application protocol to specify use of identity
  hints for those to be usable. At least one RFC does so, and another
  punts it forward (there are too many references to that RFC to scan
  quickly).
- There is also DHE-PSK in TLS 1.2. There kex data is combination of PSK
  kex data and anonDH kex data. This one is PFS.
- Then there is RSA-PSK in TLS 1.2. Too difficult to support and
  pretty much useless.
- 1RTT PSK also has some interactions with formulation of THS fix.
  Basically, one wants to force ServerHello to be always hashed.

-Ilari

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sun, 19 Oct 2014 14:47:00 +0200

>   2RTT (send identity in ClientHello).

I was thinking that maybe this can use the same "optimistic with fallback"
mechanism as the other key exchanges: initially the client chooses an identity
and sends it in ClientKeyShare in the same flight as the initial ClientHello. If
the server is happy with this identity, the normal 1.3 1RTT flow is used,
otherwise the server sends back an identity hint and things start over at
ClientHello.

(Only a rough idea, I didn't think about it carefully yet.)

>   kex data and anonDH kex data. This one is PFS.

For the sake of completeness, there is also ECDHE-PSK (RFC 5489) with the same
properties.

> - Then there is RSA-PSK in TLS 1.2. Too difficult to support and

Apparently not widely implemented currently, btw:

https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Key_exchange_algorithms_.28alternative_key-exchanges.29

>   Basically, one wants to force ServerHello to be always hashed.
That's the kind of things I was hoping you (and others with the relevant
expertise) could mention!

Manuel.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 19 Oct 2014 16:03:40 +0300

As Ilari said, there are ciphersuites with PSK and FS. 

I don’t see what the rationale can be to allow non-PFS for PSK authentication, but prohibit it for certificate authentication.  That would imply that we can make a blanket statement that the data passed in PSK-authenticated sessions is inherently low-value or non-private.  I don’t think we can make that statement.

Yoav

---

From: Hauke Mehrtens <[email-masked]>
Date: Sun, 19 Oct 2014 15:20:29 +0200

> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Key_exchange_algorithms_.28alternative_key-exchanges.29

RSA-PSK is used in the protocol for doing online authentication with the
German identity card (neuer Personalausweis). This is used when a
citizen wants to authentication himself at some government website or
online shop. It is used in the communication between the eID-Client on
the consumer device and the eID-Server, the client gets a PSK to connect
to the server and the client should still be able to check the server
certificate against a trusted list. The usage is specified by the German
BSI (Federal Office for Information Security) in TR-03124 Part 1, and
other BSI TRs.

Hauke

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sun, 19 Oct 2014 15:39:29 +0200

On 19/10/2014 15:03, Yoav Nir wrote:
> I don’t see what the rationale can be to allow non-PFS for PSK
> authentication, but prohibit it for certificate authentication.  That would
> imply that we can make a blanket statement that the data passed in
> PSK-authenticated sessions is inherently low-value or non-private.  I don’t
> think we can make that statement.
> 
I think the point is that a non-FS PSK key exchange is orders of magnitude
cheaper in terms of computation time/power usage, RAM usage, and ROM footprint
which makes it a practical option in much more scenarios than the FS variants.

For non-PSK key exchanges however, there is some asymetric crypto going on
regardless of whether the exchange is FS or not. So while the non-FS version
might be cheaper, the cost difference is nowhere near as big as ECDHE-PSK vs PSK.

Also, while it would of course be simpler to be able to state that "TLS 1.3
offers FS" rather than "TLS 1.3 offers FS *except* for PSK", it should be noted
that there is almost no risk for PSK to be negotiated "by mistake" since the
keys need to be provisioned.

Manuel.

---

From: Hauke Mehrtens <[email-masked]>
Date: Sun, 19 Oct 2014 15:41:41 +0200

> I don’t see what the rationale can be to allow non-PFS for PSK authentication, but prohibit it for certificate authentication.  That would imply that we can make a blanket statement that the data p…

For using PFS some asymmetric cryptography is needed in addition to the
symmetric cryptography and without PFS only symmetric cryptography is
needed. For normal desktop usage this does not matter, but when you want
to use TLS and DTLS on some embedded devices like Class 1 node (see
rfc7228 section 3.) with ~ 10 KiB ram and ~ 100 KiB flash and a slow CPU
(~ 10MHz) without any hardware cryptography support a DTLS handshake
without PFS is possible in under two seconds while doing a handshake
with PFS with asymmetric cryptography like ECC would take more than 10
seconds or even minutes.
In addition adding ECC also adds some more code.

I tried a DTLS handshake between two simulated MSP430X and it took 3.3
seconds for the PSK handshake using TLS_PSK_WITH_AES_128_CCM_8 and it
took 336 seconds for a handshake using the
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite on the curve secp256r1
without client authentication and 499 seconds with client
authentication. The slow part was the elliptic curve multiplication
which took 47 seconds. (my code was not very optimized and this was a
very slow CPU)

Hauke

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 19 Oct 2014 17:23:17 +0300

> (Only a rough idea, I didn't think about it carefully yet.)

Something along those lines would work, except that AFAIK client either knows
the PSK identity immediately or needs a hint from server to select it.

So one would have to stick the hint into HelloRetryRequest.

Also, would work rather nicely for DHE-PSK: If you don't know identity to
use, don't send any shares on the first round (since you will get to know
the group too on the second round).

(Well, personally I don't think HelloRetryRequest is a good idea. And
I think resetting the hash would be a very bad idea).

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Sun, 19 Oct 2014 17:35:02 +0300

> On Oct 19, 2014, at 4:39 PM, Manuel Pégourié-Gonnard <[email-masked]> wrote:
> 

I understand. It’s just weird that we’re treating non-PFS like it was made from asbestos, laced with arsenic and painted with lead paint, while this is proposing to allow asbestos/arsenic/lead combo as long as it’s much cheaper.

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. 

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.

Yoav

---

From: Watson Ladd <[email-masked]>
Date: Sun, 19 Oct 2014 07:53:23 -0700

> which took 47 seconds. (my code was not very optimized and this was a

These costs are close to the costs presented in
http://discovery.csc.ncsu.edu/software/TinyECC/TR-2007-36.pdf, and so
are in the right ballpark. However, there are several reasons why
ECDHE_ECDSA is not optimal. The first is signing and validation takes
a long time, the second is that genus 2 is faster. I also think there
are some papers that get better multiplication times, but I don't
think dramatically so.

If we want, we can fix these reasons by moving to solutions like the
Triple-DH handshake. But this ends up forcing new certificates and
kinds of keys on everyone, and getting genus 2 through CFRG should be
easy, but won't be/compatibility concerns.

You seem to have a point though: embedded devices use TLS because it
can avoid public key cryptography. Removing that option has costs, and
makes TLS 1.3 less useful than otherwise. Now, would sticking with TLS
1.2 be an option?

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 19 Oct 2014 10:58:37 -0400

> ...
TLS-PSK provides mutual authentication and channel binding, which
addresses a major problem with RSA key transport: wrap a secret in
anybody's public key and send it (even if its the wrong server or
public key).

I'm not sure its wise to discard mutual authentication and channel
binding. They are improvements over key transport.

---

From: "Paul Bakker" <[email-masked]>
Date: Sun, 19 Oct 2014 17:00:29 +0200

> From: TLS [mailto:[email-masked]] On Behalf Of Yoav Nir
> Sent: zondag 19 oktober 2014 16:35
> I understand. It’s just weird that we’re treating non-PFS like it was made
> from asbestos, laced with arsenic and painted with lead paint, while this is
> proposing to allow asbestos/arsenic/lead combo as long as it’s much
> cheaper.

The usage scenario of PSK ciphersuites is also very different than from the other ciphersuites.

PSK ciphersuites are meant for closed user groups. Peers and servers are provisioned in advance with something they share. They often don't have a TTP they rely on, with certificates that can be 'demanded' by governments in dragnet-requests.

Regards,
Paul Bakker
PolarSSL lead maintainer

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Oct 2014 16:05:53 +0100

> BSI (Federal Office for Information Security) in TR-03124 Part 1, and

RSA-PSK would presumably be forbidden in TLS 1.3 or the same reason
that ordinary RSA is forbidden. This shouldn't apply to DHE-PSK.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Oct 2014 16:07:13 +0100

> (Only a rough idea, I didn't think about it carefully yet.)

This was my assumption as well, though I also have not worked through it.

Is there any actual use for identity hints? Under what realistic
circumstances
does a client have more then one PSK for a given server?

-Ekr

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 20 Oct 2014 05:13:09 -0700 (PDT)

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.

  regards,

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 20 Oct 2014 07:25:12 -0700

On Mon, Oct 20, 2014 at 5:13 AM, Dan Harkins <[email-masked]> wrote:
>> it. But the standards donâ€™t say that. They donâ€™t say that PSK
>> the same TLS 1.3 be used for both, and we donâ€™t want to say that PSK is
>> needed for PSK uses, whereas itâ€™s essential for all RSA uses.  If I

Good luck with that: it says preshared key, not preshared password.
Yes, section 7 of RFC 4279 probably should be fleshed out more to deal
with this. Yes, we should have modern PAKE suites. SPAKE2, not
Dragonfly.

>> If we donâ€™t, weâ€™re saying that weâ€™re just piling on security

What do you mean, lack of a security proof? RFC 4279 might not cite
one, but it's pretty obvious given the recent work on proving TLS
secure what it is you need to do to get one. I can get confidentiality
and authentication in the symbolic model immediately for RFC 4279, and
more realistic models aren't that much harder. Of course, if this
analysis wasn't done beforehand, it should have been.

To be clear, I have many, many complaints about the historic and
continuing performance of this WG. So long as non-cryptographers
attempt to do crypto, the results are just bad. Given that we can't
fix or bury our mistakes despite years of effort, we need to be
especially careful. However, so far it seems like TLS 1.3 will be in a
much better position than earlier attempts.

Sincerely,
Watson Ladd

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 20 Oct 2014 10:06:29 -0700 (PDT)

> with this. Yes, we should have modern PAKE suites. SPAKE2, not

  There is nothing to flesh out because you seem to not understand
what a dictionary attack is-- but you're in company because neither
did the editors of that RFC.

  Protocols that use a static, symmetric credential like a PSK (or a
password, the difference is semantic) are all flawed because the
adversary is always assumed to have access to a pool from which
the PSK (or password is drawn. Resistance against dictionary attack
is then a demonstration that the advantage gained by the adversary
is due to _interaction_ and not _computation_.

  Merely making the pool from which the PSK is drawn, for instance
by making it a bigger or including mixed case, etc, does not make
the protocol resistant to dictionary attack. With the TLS PSK
ciphersuites the adversarial advantage always grows with
computation no matter how big, or complex, you make the PSK.

  Therefore, all of the TLS PSK ciphersuites are susceptible to
dictionary attack, notwithstanding any addition section 7 flesh
you wish to add.

> analysis wasn't done beforehand, it should have been.

  If such a proof would be enough to satisfy you over the security
of the TLS PSK ciphersuites then it would be enough to satisfy you
over the TLS-pwd ciphersuites.

  Dan.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 20 Oct 2014 20:06:52 +0200

On 20/10/2014 19:06, Dan Harkins wrote:
> the protocol resistant to dictionary attack.

>From a theoretical standpoint, the PSK key exchange is indeed vulnerable to a
dictionary attack with this definition. In practice, if your keys are 128-bit
long and chosen uniformly at random using a good source of entropy, I doubt any
real-world adversary is able to gain a non-negligible advantage in the
foreseeable future.

Also, it should be noted that with this definition, the TLS session keys are
vulnerable to a dictionary attack too. In practice, it's not a problem either
for the same reason. Obviously the difference between the pre-shared key and the
TLS session keys is that the later is short-term while the former is long-term.
Which basically boils down to the point that PSK lacks FS.

Are you sure you have point besides:
- pre-shared key must be chosen with sufficient entropy and
- PSK does not offer FS?

Manuel.

PS: by the way, it seems to me RSA key exchange as it exists in TLS 1.2 is also
vulnerable to dictionary attack with the above definition. (Obviously there are
more efficient attacks here.)

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 20 Oct 2014 20:15:22 +0200

On 20/10/2014 19:06, Dan Harkins wrote:
> by making it a bigger or including mixed case

PS: the above reference to "mixed case" makes me think there is a serious
misunderstanding about how keys should be generated. They should be the output
of a properly seeded cryptographically secure DRBG. The very notion of "mixed
case" does not make any sense in this context.

If such misinterpretations can be made, then indeed the RFC should be revised to
be much more explicit about the meaning of pre-shared *key* (as opposed to
password).

Manuel.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 20 Oct 2014 12:20:23 -0700 (PDT)

> real-world adversary is able to gain a non-negligible advantage in the

  The justification for these ciphersuites is some constrained device that
has a small data and code size. But if you can not only generate 128-bit
long uniformly random keys from a good source of entropy and also
securely provision them on 2 (or more) devices then you don't need TLS.
Just do static keyed symmetric crypto and you save even more data
and code by eliminating TLS!

  In practice, these things are deployed by people who probably do not
read the RFC in question, are in a hurry, and don't understand the
security implications of their use of TLS. The PSKs that get provisioned
are the ones that are easy to enter with a low probability of error-- i.e.
something considerably less than uniformly random 128-bit key
generated from a good source of entropy.

  This is not (only) a theoretical issue. It's practical reality.

> - pre-shared key must be chosen with sufficient entropy and

  Yes, I'm absolutely sure. It's:

  - you can't ensure security with MUSTs and SHALLs; and,
  - the use case that you say compels PSK ciphersuites actually argues
     against you.

TLS should be as misuse resistant as possible. That is, it should be as
hard as possible to use improperly and that means no PSK ciphersuites.

  regards,

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 20 Oct 2014 12:31:45 -0700

>   This is not (only) a theoretical issue. It's practical reality.

I dissent here: interoperability and firewall traversal are good reasons
not to homebake something, and if this WG had done it's job, security would
likely be better then a home brewed protocol.
> hard as possible to use improperly and that means no PSK ciphersuites.

I concurr.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 20 Oct 2014 22:26:45 +0200

> and code by eliminating TLS!
In addition to what Watson said, it's generally a bad idea to roll one's own
crypto protocol, it's too easy to get things wrong. Even with PSK, TLS brings
you important things: a record protocol, a way to derive session keys from the
long-term secret key, etc.

> generated from a good source of entropy.
I agree that's a real problem. But I don't think it has anything to do with your
previous definition of dictionary attack. As you said earlier, the size of the
pool from which the key is drawn does not change the fact the a protocol is or
isn't resistant to dictionary attack. My impression is that the size of the pool
(or more precisely the entropy of the key generator) is exactly the problem (and
from my understanding of your previous paragraph, we at least agree that it's an
important question).

>   - you can't ensure security with MUSTs and SHALLs; and,

That's one point I certainly agree with.

> hard as possible to use improperly and that means no PSK ciphersuites.
I agree about misuse resistance, and I agree it's a serious problem with the PSK
ciphersuites. I'm just not sure if it's serious enough to get rid of them.

I'd like to point out again that, in contrast with the NULL ciphersuites for
example, the mere existence of the PSK suites is less of a threat for the rest
of TLS, since there is very little risk of them being silently selected by
mistake. The problem is people who choose to use PSK but do it badly, but it
does not affect people who don't choose to use PSK.

Anyway, it's good to be discussing this explicitly.

Manuel.

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 21 Oct 2014 00:44:05 +0400

>   This is not (only) a theoretical issue. It's practical reality.
Any link to sources that support this practical reality? Or it is a
theoretical statement?

Best regards
Badra