Subject: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD

From: Michael StJohns <[email-masked]>
Date: Mon, 26 May 2014 21:53:51 -0400

I went back and read the minutes of the London meeting about removing 
static RSA and wanted to clarify what that really meant. The minutes had 
EKR mentioning this in conjunction with DH which seems different that 
what I kept hearing at the interim meeting. Could someone confirm 
"removing static RSA" results in removing the use of  RSA as a key 
transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of 
TLS1.2 - basically removing this section and prohibiting "rsa" and 
"rsa_psk"  as key exchange algorithms)?

To go further and take this up from specific cryptography - will/should 
TLS 1.3 prohibit *any* Key Transport mechanism and retain only Key 
Agreement mechanisms for key exchange?

Also in the London meeting it was agreed limit ciphertext to AEAD style 
processing - e.g. in the TLSCipherText record to remove "stream" and 
"block" as valid choices.  Does that result in the removal of sections 
6.2.3.1 and 6.2.3.2 or rather their equivalent in TLS1.3?  Does it also 
result in changing the output of the "key expansion" phase as only 
"client_write_key" and "server_write_key"s will be needed for AEAD?

Is there any desire to specify a AEAD general block cipher mode/mac 
construct with an integral key expansion function?  E.g. could something 
like http://www.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-04.txt 
be adapted to be a general model for TLS or is this out of scope for the 
TLS1.3 main document?

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 May 2014 19:32:20 -0700

On Mon, May 26, 2014 at 6:53 PM, Michael StJohns <[email-masked]>wrote:

> EKR mentioning this in conjunction with DH which seems different that what
> I kept hearing at the interim meeting. Could someone confirm "removing
> static RSA" results in removing the use of  RSA as a key transport
> mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of TLS1.2 -
> basically removing this section and prohibiting "rsa" and "rsa_psk"  as key
> exchange algorithms)?
>

Yes. This has already been merged into github:
https://github.com/tlswg/tls13-spec/commit/45aed081b1e3790507d91e3e6cc48451ed9beb94

To go further and take this up from specific cryptography - will/should TLS
> 1.3 prohibit *any* Key Transport mechanism and retain only Key Agreement
> mechanisms for key exchange?
>

I don't believe there has been any consensus on this topic. It certainly
would
be easy to do if that's what the WG wants.

> 6.2.3.1 and 6.2.3.2 or rather their equivalent in TLS1.3?

Yes. I'm working on a pull request for this now.

> Does it also result in changing the output of the "key expansion" phase as
> only "client_write_key" and "server_write_key"s will be needed for AEAD?
>

I don't believe so, since AEAD still at least potentially requires an IV.

> like http://www.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-04.txt be
> adapted to be a general model for TLS or is this out of scope for the
> TLS1.3 main document?

Certainly this is something one could in principle do. However I know that
there are some who would prefer to not specify any CBC cipher suite so
I expect they may want to weigh in now. Another alternative would be to
specific an AES-CTR/HMAC combined mode.

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Mon, 26 May 2014 23:14:32 -0400

On 5/26/2014 10:32 PM, Eric Rescorla wrote:
>
>     Does it also result in changing the output of the "key expansion"
>     phase as only "client_write_key" and "server_write_key"s will be
>     needed for AEAD?
>
>

Right - but we really need to get IV material in a way where it isn't 
derived from the master secret.    What I meant was that 
"client_write_mac_key" and "server_write_mac_key" are no longer 
generated since they aren't necessary for AEAD - correct?

>
>
>     Is there any desire to specify a AEAD general block cipher
>     mode/mac construct with an integral key expansion function?  E.g.
>     could something like
>     http://www.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-04.txt
>     be adapted to be a general model for TLS or is this out of scope
>     for the TLS1.3 main document?
>
>

There's things that the TLS base document should be specifying (e.g. 
we'll only do AEAD style modes and here's the interface), and then 
there's getting into the nitty-gritty of specific cipher suites.

  I'm wondering if it would make sense to completely remove all of the 
cryptography (e.g. RSA, DH, AES, DSA, ECDSA, ECDH) specific language to 
a separate document and have the base document only talk about the 
cryptographic constructs, message formats, negotiation schemes etc?  
That makes support of the base specification a bit more independent from 
the crypto suite specifications.

With respect to the use of compound AEAD functions - I think you have to 
allow for things like McGrew's draft, as well as the equivalent on 
non-AES, non-NIST regional mechanisms to be specified as a compound 
AEAD.  CBC has gotten bad press, but it's out there, it's built in to a 
lot of hardware and, used with a good integrity mechanism (in 
encrypt-then-mac order), seems to be "secure enough" for the given uses.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 May 2014 20:25:38 -0700

On Mon, May 26, 2014 at 8:14 PM, Michael StJohns <[email-masked]>wrote:

>  Does it also result in changing the output of the "key expansion" phase
>> as only "client_write_key" and "server_write_key"s will be needed for AEAD?
>>
>
> derived from the master secret.
>

I don't agree with this claim. As I understand the constraints, they merely
need to be derived in a way that is isolated from the keying material.
Is there a reason that it's unsafe to generate the IVs from the MS provided
that this condition is met?

>   What I meant was that "client_write_mac_key" and "server_write_mac_key"
> are no longer generated since they aren't necessary for AEAD - correct?
>

Yes, I agree with this.

>> like http://www.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-04.txtbe adapted to be a general model for TLS or is this out of scope for the
>> TLS1.3 main document?
>
>
> There's things that the TLS base document should be specifying (e.g. we'll
> only do AEAD style modes and here's the interface), and then there's
> getting into the nitty-gritty of specific cipher suites.
>

Well, ultimately whether it's in the base document or not, the TLS WG will
need
to decide whether to specify a cipher suite that uses any particular set of
algorithms.

> cryptography (e.g. RSA, DH, AES, DSA, ECDSA, ECDH) specific language to a
> separate document and have the base document only talk about the

IMO this would not promote understanding.

> allow for things like McGrew's draft, as well as the equivalent on non-AES,
> non-NIST regional mechanisms to be specified as a compound AEAD. CBC has
> gotten bad press, but it's out there, it's built in to a lot of hardware
> and, used with a good integrity mechanism (in encrypt-then-mac order),
> seems to be "secure enough" for the given uses.
>

I'm not sure what "allow for" means.

There's no technical reason that such a cipher suite cannot be specified
for TLS,
within the existing AEAD framework, but that does not mean that the WG will
be
in favor of specifying such a suite. As I said, there are people who would
prefer
not to have CBC at all.

-Ekr

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 27 May 2014 13:39:20 +0000

>> Right - but we really need to get IV material in a way where it isn't derived
>> from the master secret.

s/isn't derived/is cryptographically separated/

And everything will be fine. ;)

> need to be derived in a way that is isolated from the keying material.

Yes.

> that this condition is met?

IMHO, no. :-)

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 27 May 2014 13:43:31 +0000

>...... Could someone confirm

What would be the consequences of this decision for embedded servers that
may not have a good source of randomness to meaningfully engage in
[EC]DH[E]?

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 27 May 2014 14:53:29 +0100

On 27 May 2014 14:43:31 BST, "Blumenthal, Uri - 0558 - MITLL" <[email-masked]> wrote:

>What would be the consequences of this decision [removing static RSA] for embedded servers
>that

If they don't have any source of randomness, they are going to have problems generating any keys, random nonces or IVs, period!

I don't think we can usefully do anything secure in that scenario.

And I don't think that's a blocker outweighing the very real benefits of mandatory forward security.

- --
/akr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 May 2014 06:56:50 -0700

> may not have a good source of randomness to meaningfully engage in

They will be in trouble. However, presumably if they have a place to store
their private key, they can somehow store other random data there that
they use to generate random values, no?

-Ekr

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

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 27 May 2014 13:59:47 +0000

>>That may not have a good source of randomness to meaningfully engage in
>>[EC]DH[E]?
>
>If they don't have any source of randomness, they are going to have
>problems generating any keys, random nonces or IVs, period!

Respectfully disagree.

Keys: manufacturer can generate random key pairs for such devices and burn
them in.

IVs:  contrary to what some people tend to believe, IV does not have to be
random (or even unpredictable). Being unique is sufficient in many cases,
including AEAD.

>I don't think we can usefully do anything secure in that scenario.

Again, respectfully disagree.

>mandatory forward security.

I do. I prefer an option with explicit lack of PFS rather than "PFS on
paper only".

---

From: Watson Ladd <[email-masked]>
Date: Tue, 27 May 2014 07:00:49 -0700

On Tue, May 27, 2014 at 6:56 AM, Eric Rescorla <[email-masked]> wrote:
>
>
>
> On Tue, May 27, 2014 at 6:43 AM, Blumenthal, Uri - 0558 - MITLL
> <[email-masked]> wrote:
>>

But then they can store an incrementing counter for use with AES with
a fixed key as a RNG. I don't see the problem here.

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

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 27 May 2014 14:09:55 +0000

>>>What would be the consequences of [removing key transport] for embedded
>>>servers that

Yes, that is definitely an option (why didn't I think of it myself?) - a
reasonably good PRNG for a source of randomness.

However I still am uneasy about the client being unable to tell the server
"This is *my* transaction, and I want you to use this key with this cipher
suite to protect it".

[I understand the value of PFS. :-]

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 May 2014 07:10:40 -0700

> a fixed key as a RNG. I don't see the problem here.

Yes, that is one way of doing what i was suggesting.

-Ekr

---

From: Jakob Breier <[email-masked]>
Date: Tue, 27 May 2014 16:18:22 +0200

> a fixed key as a RNG. I don't see the problem here.

Even better, if there is some memory that can be securely erased, you 
could retain PFS via something like
r_(j+1) = HMAC(longTermKey, r_j || counter )
where the cache of the current random output r_j will be overwritten 
with r_(j+1).

Regards,
Jakob Breier

---

From: Dan Brown <[email-masked]>
Date: Tue, 27 May 2014 14:29:00 +0000

Looks like PRNGs, e.g. HMAC_DRBG, being re-invented, by the way.

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Jakob Breier
> Sent: Tuesday, May 27, 2014 10:18 AM
> To: [email-masked]
> Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and
AEAD
> >> >They will be in trouble. However, presumably if they have a place to
> >> >store their private key, they can somehow store other random data
> >> >there that they use to generate random values, no?
could
> retain PFS via something like
> r_(j+1) = HMAC(longTermKey, r_j || counter ) where the cache of the
current
> random output r_j will be overwritten with r_(j+1).
> 
> Regards,
> Jakob Breier
>

---

From: Jakob Breier <[email-masked]>
Date: Tue, 27 May 2014 16:51:47 +0200

True :)
To just show the principle a simple example is more concise than the 
full blown HMAC_DRBG, though.

Regards,
Jakob Breier

---

From: Dan Brown <[email-masked]>
Date: Tue, 27 May 2014 15:18:19 +0000

> From: TLS [mailto:[email-masked]] On Behalf Of Blumenthal, Uri - 
> 0558 -
> MITLL
> Sent: Tuesday, May 27, 2014 9:44 AM
>

As noted elsewhere, if the server is authenticated (or at least has a 
long-term private key) and has a persistent state then it should be able to 
implement a good PRNG.  Then it can do pretty good DHE, with forward secrecy, 
which is better than key transport.

Otherwise, static [ECH]DH seems quite similar in security properties to key 
transport, from the server's side, for the following 2 reasons.

If the server is completely stateless and lacks an entropy source, it will 
fail to achieve FS in its attempts at DH[E], but this is still as good as key 
transport.

If the server is anonymous, (or at least lacks a long-term private key) and 
lacks a source of entropy, a persistent state does not seem to help, whether 
for DH or RSA key exchanged.

---

A different question:  what about very constrained clients?  Is this even a 
fair question?

For example, what if the client can be seeded with entropy but lacks a live 
entropy source and a persistent state (to implement a good PRNG)?

Currently key transport require the client to generate a random 
pre_master_secret.  A weak client could naively always generate the same PMS, 
which would be bad.  It could derive the PMS from the server key public key, 
and perhaps the server random value, so that PMS is not common to two 
different servers, or sessions.  This would make it similar to static DH.

An even weaker client is one that is unseeded and entropy-lacking (and 
completely stateless, not that statefulness would help here).   Such a client 
could apply deterministic encryption of messages using RSA.  Note that this 
would no longer be key transport, but rather content encryption, so would 
require a major change to TLS. Also, this type of deterministic encryption 
lacks many of the important security benefits of probabilistic encryption. 
There have been research papers about deterministic encryption: the security 
is limited by the amount of entropy in the message being encrypted.  Anyway, 
maybe this is the one situation in which RSA has an advantage over DH.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 27 May 2014 08:20:41 -0700

> for DH or RSA key exchanged.

Replay attacks: servers need state or randomness to prevent.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 27 May 2014 11:53:24 -0400

On 5/26/2014 11:25 PM, Eric Rescorla wrote:
> On Mon, May 26, 2014 at 8:14 PM, Michael StJohns 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>         Does it also result in changing the output of the "key
>>         expansion" phase as only "client_write_key" and
>>         "server_write_key"s will be needed for AEAD?
>>
>>
>     Right - but we really need to get IV material in a way where it
>     isn't derived from the master secret.
>
>

I'm going to answer this twice because EKR's comment appears to include 
an slight internal inconsistency or I'm mis-understanding what he meant:

1) ----------------------------------

"isolated from the keying material" can be accomplished one of two ways 
- by deriving a sub-secret from the master secret and then using that 
for generating the IV in a keyed PRNG, or by deriving a second secret 
from the pre-master secret at the same time you generate the master 
secret and generating the IV from that second secret.  I would claim 
that neither of those is equivalent to "generate the IV's from the MS...."

There's a third way that basically injects per-key and iv length 
information into the KDF expansion - I looked at this and rejected it as 
it made the KDF security analysis complex and it violated the general 
principle that cryptographic functions output either public (cipher 
text, signatures) or private data (key material) and not both.

Is there a fourth way you were thinking of? and "isolated" needs to mean 
"cryptographically isolated".

2) ----------------------------------

As a specific comment on how the master secret is used:

The general rule is that the same key shouldn't be used for multiple 
things.  In this case the master secret is used (ignoring for a moment 
that the functions are all iterations of the PRF):

  * with a Key Derivation Function to derive key material
  * with a MAC function to sign the finished messages
  * with a keyed pseudo random number generator to derive the IV's.

By my count that's two too many.  The fact that the KDF and PRNG steps 
are part of the same process is even more problematic.

There's literature on this - but an easy reference is section 5.2 of 
NIST's SP800-57 part 1 rev 3 - 
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-57-Part%203-Rev.1:

> 5.2 Key Usage
> In general, a single key should be used for only one purpose (e.g., 
> encryption, authentication,
> key wrapping, random number generation, or digital signatures). There 
> are several reasons for
> this:

> 1. The use of the same key for two different cryptographic processes 
> may weaken the
> security provided by one or both of the processes.

> 2. Limiting the use of a key limits the damage that could be done if 
> the key is compromised.

> 3. Some uses of keys interfere with each other. For example, consider 
> a key pair used for
> both key transport and digital signatures. In this case, the private 
> key is used as both a
> private key-transport key to decrypt data-encryption keys and a 
> private signature key to
> apply digital signatures. It may be necessary to retain the private 
> key-transport key
> beyond the cryptoperiod of the corresponding public key-transport key 
> in order to decrypt
> the data-encryption keys needed to access encrypted data. On the other 
> hand, the private
> signature key shall be destroyed at the expiration of its cryptoperiod 
> to prevent its
> compromise (see Section 5.3.6). In this example, the longevity 
> requirements for the
> private key-transport key and the private digital-signature key 
> contradict each other.

> This principle does not preclude using a single key in cases where the 
> same process can provide
> multiple services. This is the case, for example, when a digital 
> signature provides assurance of
> the identity of the originating entity, non-repudiation, source 
> authentication and integrity
> protection using a single digital signature, or when a single 
> symmetric data-encryption key can
> be used to encrypt and authenticate data in a single cryptographic 
> operation (e.g., using an
> authenticated-encryption operation, as opposed to separate encryption 
> and authentication
> operations). Also refer to Section 3.7.

> This Recommendation also permits the use of a private key-transport or 
> key-agreement key to
> generate a digital signature for the following special case:
> When requesting the (initial) certificate for a static 
> key-establishment key, the associated
> private key may be used to sign the certificate request. Also refer to 
> Section 8.1.5.1.1.2.

Because the IV may be used for things like nonces, the IV generator 
needs to be unpredictable, but able to be generated synchronously from 
data available to the sender and receiver.  It's unclear that it needs 
any more entropy (e.g. a key)  than that available in the client_random 
and server_random.  If the per-message IV is carried in its entirety in 
the message, then the IV generator need not be coordinated between 
sender and receiver.

 From a general cryptographic point of view, an IV is NOT a confidential 
data element.  A cipher mode is required to be secure even if the IV is 
available to an attacker, so again, it's unclear the IV generator needs 
to be a keyed PRNG.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 27 May 2014 12:03:01 -0400

On 5/27/2014 9:39 AM, Blumenthal, Uri - 0558 - MITLL wrote:
>         Right - but we really need to get IV material in a way where
>         it isn't derived from the master secret.
>
>

No.  The key material and IVs produced by the current TLS1.2 KDF are 
"cryptographically separated" from the master secret - that's sort of 
the definition of what a KDF is.

You want cryptographic isolation between the key material produced from 
the master secret and the iv material produced from the IV, and the 
current spec doesn't do that.  See my last message to EKR.  One way to 
create this isolation is to derive the random IV data from a key that is 
different from the master secret - either a subkey derived from the 
master secret, or from a second key derived from the premaster.    A 
second way to create the isolation is to not generate the IV data from a 
key value and instead simply use an entropy expansion function on the 
client_random and server_random to generate the IVs.

There are other approaches, but most end up with a single function 
producing both public and private data and that makes securing the 
process difficult.

Mike

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 27 May 2014 16:58:54 +0000

> You want cryptographic isolation between the key material produced from the
> master secret and the iv material produced from the IV, and the current spec
> doesn't do that.  See my last message to EKR.  One way to create this
> isolation is to derive the random IV data from a key that is different from
> the master secret - either a subkey derived from the master secret, or from a
> second key derived from the premaster.

You want the separation to be on a higher level.

I'd be happy with either one of the above.

>   A second way to create the isolation is to not generate the IV data from a

Should be fine too, assuming at least one *_random is good enough.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 27 May 2014 13:39:33 -0400

On 5/27/2014 12:58 PM, Blumenthal, Uri - 0558 - MITLL wrote:
>
>     You want cryptographic isolation between the key material produced
>     from the master secret and the iv material produced from the IV,
>     and the current spec doesn't do that.  See my last message to
>     EKR.  One way to create this isolation is to derive the random IV
>     data from a key that is different from the master secret - either
>     a subkey derived from the master secret, or from a second key
>     derived from the premaster.
>
>
>       A second way to create the isolation is to not generate the IV
>     data from a key value and instead simply use an entropy expansion
>     function on the client_random and server_random to generate the IVs.
>
>

That latter is my preference.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 27 May 2014 13:43:52 -0400

> different servers, or sessions.  This would make it similar to static DH.

One of the London decisions (which EKR clarified earlier in the thread) 
is the removal of key transport (e.g. RSA static encryption) as a key 
exchange mechanism for TLS1.3.  That removes the need to generate a 
pre_master_secret as the product of only one side.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 27 May 2014 13:49:29 -0400

> random (or even unpredictable). Being unique is sufficient in many cases,

Hi Uri -

I seem to remember for some modes that the IV has to unpredictable - I 
believe that CBC was one. (But may be mitigated by integrity checks to 
defeat chosen plain text attacks?  I don't have time to search for a 
cite).  You are correct that uniqueness is the only requirement for 
AEAD, but mostly AEAD IVs are constructed from a [random nonce][per 
message value][block counter 0] concatenation - the random nonce 
enforces the uniquity.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 27 May 2014 13:58:04 -0400

> may not have a good source of randomness to meaningfully engage in

You could still do 1/2 ephemeral ECDH.  The embedded server would have 
to have a key pair created for it and installed, and would have to only 
support ECDHE ciphers.  The client would generate a new ECDH pair per 
connection, resulting in different derived shared secrets. It's not 
ideal, but has the benefit of not requiring much in the way of randomness.

You still need a source of some randomness for server_random though.  
The comments elsewhere on using a seeded AES PRNG are interesting - but 
it would be useful to still mix in as much entropy as you can find 
internally.  (Or even externally).

Mike

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 27 May 2014 18:01:31 +0000

On 5/27/14 13:49 , "Michael StJohns" <[email-masked]> wrote:

>defeat chosen plain text attacks?

Yes and yes. AFAIR. Which is why I'm not a fan of CBC (in addition to
having to worry about padding :).

>I don't have time to search for a
>enforces the uniqueness.

Random nonce = per-key-change. Per-message value could be also a counter.

;)

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 27 May 2014 20:01:02 +0100

On 27/05/2014 14:59, Blumenthal, Uri - 0558 - MITLL wrote:

>> If they don't have any source of randomness, they are going to
>> have problems generating any keys, random nonces or IVs, period!
> Keys: manufacturer can generate random key pairs for such devices
> and burn them in.

I caution against such a practice. Pre-baked keys are a half-baked idea!

Pre-baked keys make the manufacturer responsible for not just the
implementation, but the actual keys.

• If the manufacturer keeps the keys:
  - The manufacturer will become a remarkably attractive target.
  - The manufacturer will be attacked - legally, technically, and
    otherwise, by various actors - for the keys.
  - Manufacturers are unlikely to be able to resist every attack.

• If the manufacturer "doesn't keep the keys":
  - The manufacturer may not generate the keys securely.
  - The manufacturer is likely to be coerced into secretly keeping
    the keys, or may already be doing so.
  - The manufacturer may be, or may be coerced into, lying about it.
  - The manufacturer cannot prove they didn't keep the keys.

This has represented - and still represents - the most significant
practical point of attack in numerous real-world implementations (to
give one notable high-profile example: the seed compromise in RSA
SecurID®).

I would strongly recommend device manufacturers not to generate keys.

> IVs:  contrary to what some people tend to believe, IV does not
> have to be random (or even unpredictable). Being unique is
> sufficient in many cases, including AEAD.

A note of caution here: as I recall, CBC mode's one of the famous
problem cases where non-random IVs enable a chosen-ciphertext attack?

[Of course, no AEAD I'm aware of uses CBC mode, so I believe we're
switching away from that in TLS 1.3 - but still, the point bears
mention in case of later misunderstanding.]

- -- 
/akr

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 27 May 2014 12:17:38 -0700

> Keys: manufacturer can generate random key pairs for such devices and burn

Which means that, if the device is ever a TLS client using an TLS
1.1-style RSA key transport, then the device is completely insecure: the
supposedly secret part of the pre-master secret will always be the same!

If the device really has no source of randomness, I think it's still
much better off using a static DHE secret.

--Andy

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 27 May 2014 19:32:01 +0000

>I caution against such a practice.......
>..............

Conceptually, is it different from manufacturer seeding the PRNG on such
devices?

>I would strongly recommend device manufacturers not to generate keys.

It may be the only reasonable alternative for small-factor embedded
devices, the other alternative being very bad keys generated on such
devices locally. 

I think most of the bad SSH and TLS keys reported on the Internet are the
result of such approach being implemented.

"A good man knows his limitations" - this should apply to good devices
too. :)

See 
@InProceedings{weakkeys12,
  author = {Nadia Heninger and Zakir Durumeric and Eric Wustrow and J.
Alex Halderman},
  title = {Mining Your {P}s and {Q}s: {D}etection of Widespread Weak Keys
in Network Devices},
  booktitle = {Proceedings of the 21st {USENIX} Security Symposium},
  month = aug,
  year = 2012
}

>problem cases where non-random IVs enable a chosen-ciphertext attack?

Essentially yes. But it is not just CBC mode, it's a combination of the
usage, cipher suite, etc. I.e., if the MAC was in a better place wrt.
Pad+Encrypt and all this, y'know...

I personally would rather drop CBC than RSA. :-)

>mention in case of later misunderstanding.]

Of course. :-0

---

From: [email-masked] (Martin Rex)
Date: Tue, 27 May 2014 22:46:32 +0200 (CEST)

Michael StJohns wrote:
>> encryption, authentication, key wrapping, random number generation,
>> or digital signatures). There are several reasons for this:

I believe you're misinterpreting the concept of the TLS master secret.

The TLS master secret is *NOT* a key.  It is more like the entropy pool
(internal state) of a DBRG (Deterministic Random Bit Generators).

-Martin

---

From: Michael StJohns <[email-masked]>
Date: Tue, 27 May 2014 17:15:24 -0400

> (internal state) of a DBRG (Deterministic Random Bit Generators).

Um.... taken one way you could call any key an entropy pool.  I think 
you're misinterpreting the characteristics of a key.

So, no.

Stealing from the definition of "Cryptographic Key" in SP800-57 part 1 
rev 3:

> A parameter used in conjunction with a cryptographic algorithm that
> determines its operation in such a way that an entity with knowledge of
> the key can reproduce or reverse the operation, while an entity without
> knowledge of the key cannot.

Continuing, the master secret *is* used explicitly as a MAC key 
(finished message) and as a master key for a KDF (key expansion).

Seriously though - no.   Basically if you share it, it's no longer an 
entropy pool, but a key.  And as I've suggested several times before, 
its unclear that the function that generates the IVs needs to to be 
keyed, or do anything except expand the entropy available from 
client_random and server_random to an appropriate length and with a 
particular set of mix-in's.

Mike

---

From: [email-masked] (Martin Rex)
Date: Tue, 27 May 2014 23:21:25 +0200 (CEST)

Michael StJohns wrote:
> Martin Rex wrote:

Unless you're using a NULL encryption ciphersuite, the Finished
messages _are_ encrypted, rather than exchanged in the clear,
and there is a reason why the Finished message is truncated.

For the two communication peers that are involved (TLS client and
TLS server), the master secret is a shared secret.  For any attacker,
the finished messages are not visible (encrypted).

> entropy pool, but a key.

There is a necessity to share the master secret with your communication
peer so that both can derive the same new secrets from it.

-Martin

---

From: Michael StJohns <[email-masked]>
Date: Thu, 29 May 2014 15:34:22 -0400

> the finished messages are not visible (encrypted).

Not really sure why this is relevant.  Are you arguing that the finished 
MAC isn't actually a MAC or the finished MAC isn't necessary if the 
handshake is encrypted, or isn't necessary if these messages are 
encrypted? Or that the key for the MAC isn't actually a key?

As a general comment, the security of the TLS handshake protocol 
shouldn't a) depend on the encryption of the handshake messages, or b) 
depend on the security of any part of the negotiated cryptographic suite 
except that specifically required for the handshake (and right now, 
that's only the PRF).  (e.g. I can't assume that the cipher suite isn't 
NULL for encryption when designing the security).

Encryption of the handshake is "nice to have" and "provides privacy for 
some elements of the handshake (e.g. certificates)", but isn't actually 
critical for the security (integrity/source authentication/key 
agreement/correctness/prevention of MITM attacks) of the protocol.

> peer so that both can derive the same new secrets from it.

Hence my point that the master secret is a key, and not an entropy pool.

You've made a claim about the master secret (and the PRF) being more 
like an entropy pool.  Is there any literature to support your view?

Later, Mike

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 29 May 2014 20:18:49 +0000

>Hence my point that the master secret is a key, and not an entropy pool.

*Shared* entropy *is* a key.  :-)

---

From: Michael StJohns <[email-masked]>
Date: Thu, 29 May 2014 18:19:07 -0400

> *Shared* entropy *is* a key.  :-)

Shared *data* may be a key.  A key may have no entropy at all. (e.g. 
passwords for PBE, public keys for identity based public key systems, 
most PINs etc, your safe combination - really, your marriage date?).

Neither of the following statements is true:

    A key is always shared entropy.
    Shared entropy is always a key.

Then there's the fact that "shared entropy" is probably an oxymoron.  
Entropy is "lack of order or predictability", or in thermo "a measure of 
disorganization of a system" and "shared entropy" is there so that 
multiple entities can predictably come up with the same "unpredictable" 
values.

Going back to the origin of this discussion, the premaster and master 
secrets are "keys" - they may be other things, but they are always 
"keys" because without knowledge of those pieces of information you may 
not repeat the functions keyed by them and get the same answers.  (Look 
up many definitions of "key" and you'll find this general concept).  
Martin's assertion that the TLS master secret is not a key is ... 
unsupported by the facts.  Thinking about it as an entropy pool is 
misleading.

Later, Mike

http://niccs.us-cert.gov/glossary#letter_k
> key:
>
> Definition: The numerical value used to control cryptographic 
> operations, such as decryption 
> <http://niccs.us-cert.gov/glossary#decryption>, encryption 
> <http://niccs.us-cert.gov/glossary#encryption>, signature 
> <http://niccs.us-cert.gov/glossary#signature> generation, or signature 
> verification.
>

http://jproc.ca/crypto/terms.html
> *Key* - Information (usually a sequence of random or pseudo-random 
> binary digits) used initially to set up and periodically change the 
> operations performed in crypto equipment for the purpose of encrypting 
> or decrypting electronic signals, for determining electronic 
> counter-countermeasures patterns (e.g., frequency hopping or spread 
> spectrum), or for producing other key. "Key" has replaced the terms 
> "variable," "key(ing) variable," and "cryptovariable." 

http://en.wikipedia.org/wiki/Key_%28cryptography%29
> In cryptography <http://en.wikipedia.org/wiki/Cryptography>, a *key* 
> is a piece of information (a parameter 
> <http://en.wikipedia.org/wiki/Parameter>) that determines the 
> functional output of a cryptographic algorithm 
> <http://en.wikipedia.org/wiki/Algorithm> or cipher 
> <http://en.wikipedia.org/wiki/Cipher>. Without a key, the algorithm 
> would produce no useful result. In encryption 
> <http://en.wikipedia.org/wiki/Encryption>, a key specifies the 
> particular transformation of plaintext 
> <http://en.wikipedia.org/wiki/Plaintext> into ciphertext 
> <http://en.wikipedia.org/wiki/Ciphertext>, or vice versa during 
> decryption <http://en.wikipedia.org/wiki/Decryption>. Keys are also 
> used in other cryptographic algorithms, such as digital signature 
> <http://en.wikipedia.org/wiki/Digital_signature> schemes and message 
> authentication codes 
> <http://en.wikipedia.org/wiki/Message_authentication_code>.

http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/appendix-b-glossary.htm
>
> *key*
>     A string of bits used widely in cryptography, allowing people to
>     encrypt and decrypt data; a key can be used to perform other
>     mathematical operations as well. Given a cipher, a key determines
>     the mapping of the plaintext to the ciphertext. See also
>     distributed key, private key, public key, secret key, session key,
>     shared key, sub key, symmetric key, weak key. 
>

http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
> Cryptographic key
> (key)
> knowledge of the key cannot. Examples include:
> 1. The transformation of plaintext data into ciphertext data,
> 2. The transformation of ciphertext data into plaintext data,
> 3. The computation of a digital signature from data,
> 4. The verification of a digital signature,
> _*5. The computation of an authentication code from data*_,
> 6. The verification of an authentication code from data and a
> received authentication code,
> _*7. The computation of a shared secret that is used to derive keying*__*
> *__*material.*_