[TLS] -tls13-11: "directional keys" ?

2016-02-17 Thread =JeffH

In -tls13-11 section 7.2 [1] there is this..

  7.2.  Updating Traffic Keys and IVs

 Once the handshake is complete, ...

[...]

 Once traffic_secret_N+1 and its associated traffic keys have been
 computed, implementations SHOULD delete traffic_secret_N.  Once the
 directional keys are no longer needed, they SHOULD be deleted as
 well.


..and it isn't clear to me what is meant by "directional keys" in the
paragraph above (that is the only occurance of the term I find)?

is the term meant as a forward reference to this table in S 7.3 and thus
to the notion of "client write key" and "server write key" ?

 +--++
 | Key Type | Purpose|
 +--++
 | Client Write Key | "client write key" |
 |  ||
 | Server Write Key | "server write key" |
  [...]
 +--++


thx,

=JeffH

[1] https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-7.2

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


[TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ?

2016-02-17 Thread =JeffH

Hi,

RFC5705 section 4 "Exporter Definition" [1] states..

   The exporter takes three input values:

   o a disambiguating label string,

   o a per-association context value provided by the application using
 the exporter, and

   o a length value.

   If no context is provided, it then computes:

   PRF(...
  )[length]

   If context is provided, it computes:

   PRF(...
  )[length]


..i.e., RFC5705 directly utilizes the TLS PRF (pseudo-random function)
from TLS {1.0, 1.1, 1.3}.  Since the PRF() is no longer defined in TLS
1.3, RFC5705 is incompatible with TLS 1.3, yes?

Also, draft-ietf-tls-tls13-11 seems to contain a built-in keying material
exporter (KME) in S 7.1 step 8 [2]..

   7.1.  Key Schedule

  [...]

  8. exporter_secret = HKDF-Expand-Label(master_secret,
  "exporter master secret",
  handshake_hash, L)
  [...]


..i.e., does the above step "8." effectively define the TLS 1.3 keying
material exporter?


thanks,

=JeffH


[1] https://tools.ietf.org/html/rfc5705#section-4

[2] https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-7.1

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] -tls13-11: "directional keys" ?

2016-02-17 Thread Benjamin Kaduk
On 02/17/2016 01:03 PM, =JeffH wrote:
> In -tls13-11 section 7.2 [1] there is this..
>
>   7.2.  Updating Traffic Keys and IVs
>
>  Once the handshake is complete, ...
>
> [...]
>
>  Once traffic_secret_N+1 and its associated traffic keys have been
>  computed, implementations SHOULD delete traffic_secret_N.  Once the
>  directional keys are no longer needed, they SHOULD be deleted as
>  well.
>
>
> ..and it isn't clear to me what is meant by "directional keys" in the
> paragraph above (that is the only occurance of the term I find)?
>
> is the term meant as a forward reference to this table in S 7.3 and thus
> to the notion of "client write key" and "server write key" ?
>

Yes.

-Ben

>  +--++
>  | Key Type | Purpose|
>  +--++
>  | Client Write Key | "client write key" |
>  |  ||
>  | Server Write Key | "server write key" |
>   [...]
>  +--++
>
>
> thx,
>
> =JeffH
>
> [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-7.2
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ?

2016-02-17 Thread Ilari Liusvaara
On Wed, Feb 17, 2016 at 11:25:12AM -0800, =JeffH wrote:
> Hi,
> 
> RFC5705 section 4 "Exporter Definition" [1] states..
> 
>The exporter takes three input values:
> 
>o a disambiguating label string,
> 
>o a per-association context value provided by the application using
>  the exporter, and
> 
>o a length value.
> 
>If no context is provided, it then computes:
> 
>PRF(...
>   )[length]
> 
>If context is provided, it computes:
> 
>PRF(...
>   )[length]
> 
> 
> ..i.e., RFC5705 directly utilizes the TLS PRF (pseudo-random function)
> from TLS {1.0, 1.1, 1.3}.  Since the PRF() is no longer defined in TLS
> 1.3, RFC5705 is incompatible with TLS 1.3, yes?
> 
> Also, draft-ietf-tls-tls13-11 seems to contain a built-in keying material
> exporter (KME) in S 7.1 step 8 [2]..
> 
>7.1.  Key Schedule
> 
>   [...]
> 
>   8. exporter_secret = HKDF-Expand-Label(master_secret,
>   "exporter master secret",
>   handshake_hash, L)
>   [...]
> 
> 
> ..i.e., does the above step "8." effectively define the TLS 1.3 keying
> material exporter?
> 

Well, it isn't clear to me what TLS 1.3 exporters should do. Presumably
the "master secret" used for calculations is exporter_secret. However,
just replacing the PRF in definition with the standard TLS 1.3 PRF
(HKDF) would leave those exporters using randoms, which aren't
explicitly used anywhere in TLS 1.3.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] JPAKE

2016-02-17 Thread Robert Cragie
A few points to some of the comments:

1) Thread devices are not typically smartphones and PCs. They are class 1
constrained devices according to RFC7228, i.e. thermostats and light
switches etc.
2) Device certs. and short fingerprints are indeed used in similar systems
to Thread (e.g. ZigBee IP)
3) There is an experimental version of TLS using EC-JPAKE. This will be
written up in an informational RFC as stated
4) Typically the device requiring network access has a burned in passphrase
which is entered into a local commissioning device, establishing a secured
session and high entropy shared secret, which is subsequently used for
delivering network parameters authorising network admission. Any PAKE would
have done really however the decision was made to use EC-JPAKE. This method
may not be appropriate in all scenarios but provides a common, simple
interoperable mechanism for consumer devices.

Robert



On 17 February 2016 at 06:52, Tony Arcieri  wrote:

> On Tue, Feb 16, 2016 at 10:45 PM, Dan Harkins  wrote:
>
>> What?!? How is that "better"? Having a "keychain" that loops in some
>> vague "secure enclave" that makes authorization decisions based on some
>> app deriving a "strong master secret from a weak password/pin" sounds
>> complicated
>
>
> Microsoft:
> https://technet.microsoft.com/en-us/library/mt621546(v=vs.85).aspx
> Matt Green: https://twitter.com/matthew_d_green/status/699777680728842240
> Apple: https://www.apple.com/business/docs/iOS_Security_Guide.pdf (see
> also: Matt Green)
>
> Hardware interlocks around authentication allow various anti-brute force,
> exponential backoff, and device wiping security measures. They also allow
> you to unlock a "full entropy" cryptographic key with some low entropy
> mechanism like a PIN without the former being deterministically derived
> from the latter.
>
> I personally believe the future of authentication is having a weak
> credential which unlocks a strong credential on something you have. This
> approach to authentication is generally described as "something you have
> and something you know"
>
> --
> Tony Arcieri
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


[TLS] -tls13-11: client ephemeral, server ephemeral, static secret, ephemeral secret ?

2016-02-17 Thread =JeffH
Hi, perhaps I'm missing various somethings, but I'm having trouble figuring 
out _how_ the Static Secret (SS) and Ephemeral Secret (ES) are actually 
derived...



Given this chunk of -tls13-11..

###
7.1.  Key Schedule

   The TLS handshake establishes secret keying material which is then
   used to protect traffic.  This keying material is derived from the
   two input secret values: Static Secret (SS) and Ephemeral Secret
   (ES).

   The exact source of each of these secrets depends on the operational
   mode (DHE, ECDHE, PSK, etc.) and is summarized in the table below:

   +-+++
   | Key Exchange| Static Secret (SS) |  Ephemeral Secret (ES) |
   +-+++
   | (EC)DHE (full   |Client ephemeral w/ |Client ephemeral w/ |
   | handshake)  |   server ephemeral |   server ephemeral |
   | |||
   | (EC)DHE (w/ |Client ephemeral w/ |Client ephemeral w/ |
   | 0-RTT)  |  server static |   server ephemeral |
   | |||
   | PSK | Pre-Shared Key | Pre-shared key |
   | |||
   | PSK + (EC)DHE   | Pre-Shared Key |Client ephemeral w/ |
   | ||   server ephemeral |
   +-+++
###

..where do "client ephemeral" & "server ephemeral" come from -- i.e., which 
section(s) of the spec define their provenance?  searching -tls13-11's text 
for those phrases yields hits in only that thar above table :(


however, I note the following in the preceding section 6.2..

###
6.2.  Handshake Protocol Overview

   [...]

   Ephemeral Secret (ES): A secret which is derived from fresh (EC)DHE
   shares for this connection.  Keying material derived from ES is
   intended to be forward secret (with the exception of pre-shared key
   only modes).

   Static Secret (SS): A secret which may be derived from static or
   semi-static keying material, such as a pre-shared key or the server's
   semi-static (EC)DH share.

   [...]

  ... If DH is in use, this will contain a
   "key_share" extension with the server's ephemeral Diffie-Hellman
   share which MUST be in the same group as one of the shares offered by
   the client.  The server's KeyShare and the client's KeyShare
   corresponding to the negotiated key exchange are used together to
   derive the Static Secret and Ephemeral Secret (in this mode they are
   the same).  [Section 6.3.2.3]
###


So, is "server ephemeral" in S 7.1 actually referring to "the server's 
ephemeral Diffie-Hellman share" in S 6.2 ?


Is "client ephemeral" in S 7.1 referring to "the client's KeyShare" in S 6.2 ?

The above S 6.2 text seems to indicate that Section 6.3.2.3 defines how the 
server's KeyShare and the client's KeyShare are used to derive the Static 
Secret and Ephemeral Secret, but I am not able discern such a definition 
(unlike the clear definitions for xSS, xES, etc in S 7.1).



thanks,

=JeffH







___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


[TLS] Proposal: don't change keys between handshake and application layer

2016-02-17 Thread Eric Rescorla
Hi folks,

TL;DR.
I propose that we should not change keys between the handshake
and application traffic keys.

DETAILS
As we try to finalize the drafts and implementations are starting to
emerge, it's worth looking for opportunities to simplify. This is the
first of several messages suggesting areas where we may have made
things too general/complicated and now that we can look at
simplifying. The following suggestion comes out of conversations with
Karthik Bhargavan, Antoine Delignat-Lavaud, Cedric Fournet, Christian
Huitema, Markus Kohlweiss, Martin Thomson, Santiago Zanella and
others.

The general idea is that there is no strong security reason to change
change keys between handshake and traffic in the same phase (e.g.,
between the 1-RTT handshake and traffic keys, so we should simplify by
not doing so.)  This is something that implementers have asked for,
especially for DTLS (so you don't need to have three contexts in one
flight) and we have resisted, nominally for security reasons but
really over concerns about analysis.

There are three basic security reasons why one might want to change
keys:

- To add additional secret information.
- To bind in additional context.
- For PFS.

None of these apply at the handshake/traffic transition: We don’t have
any more secret material at this point in TLS 1.3 (SS and ES are both
known at the time that the handshake keys must be generated.) It is
not necessary to bind in the additional context to the traffic keys
(though see below about resumption) because it is tied to the keys
via the Finished messages. We know how to do security proofs
for this (those exist for 1.2).  There’s no reason to have different
PFS for the handshake versus the application traffic.

We can simplify matters by adopting a schedule more like the following:


Key Class Input   Handshake Context Specific
  Secrets /Transcript   Keys
-
0-RTT KeysSS  ClientHello + client write keys
   ServerConfiguration +client finished keys
   ServerCertificate +
   CertificateRequest

1-RTT KeysSS, ES  ClientHello,  client/server write
keys
  ServerHello   client/server
finished keys


Final KeysSS, ES  Complete transcript
  through client finished   exporter master
secret
resumption master
secret
[Maybe
traffic_secret_1]


Note that it is very important that the Resumption Master Secret
include the server certificate (otherwise you get Triple Handshake)
but you shouldn'tt need that for the initial handshake traffic keys.

This is clearly simpler and also has the advantage that you do fewer
expansions with different combinations of transcript messages. It's
a very simple change to the specification and to implementations.
It also allows a somewhat simpler key schedule (see the next message
in this series).

There are two potential objections here:
- It’s a change, how do we know it’s OK?
- Doesn’t this make analysis harder?

There are intuitive reasons to believe that it is OK (this is very
similar to what TLS 1.2 does with the resumption secret being derived
as with Extended Master Secret), and there are teams actively adapting
their analysis to verify that they are OK. Obviously, it might not be
OK and we should not finalize this change until we have some analysis.
I'll let Karthik, Cedric, etc. speak to the progress on that and
perhaps we can discuss more at TRON.

There is a sense in which it makes analysis harder in that the
cryptographic (as opposed to symbolic) proofs are better adapted to
assuming that the keys being output by the handshake are never used
for any handshake purpose. However, there are techniques for making
this work with plausible assumptions about how TLS will use the keys
(mainly that only TLS will be allowed to send traffic with the TLS
internal keys and that everything else will only get access to
Exported keys) [1].

One more important note: for DHE-PSK mode, it is important to have the
traffic encrypted under both SS and ES (I.e., both PSK and DHE) but
that’s not presently true for the handshake data (which is only
encrypted under ES). So, this will also require at least some change
to the key schedule to accommodate that. However, those changes are
relatively straightforward.

Comments, please.
-Ekr


[1] Another alternative here would be to generate separate keys for
handshake and application traffic but do so at the same time, so that
there is only one derivation stage. This simplifies the specification
and implementation somewhat, but not as much as having handshake
and application traffic.
__