Re: [TLS] Key Schedule (PRs #453, #454).

[Eric Rescorla]

Sorry, I think you lost me there. Can you rephrase?

-Ekr


On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara 
wrote:

> On Thu, May 19, 2016 at 12:13:45PM -0700, Eric Rescorla wrote:
> > On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote:
> > >
> > > Just one thing to be careful of: If one has off-handshake counter-
> > > keys[1] (like the now-removed GDH 0-RTT mode had), one needs to hash
> > > those in, or one gets all kinds of crypto screw (which may or may not
> > > be actually exploitable...)
> > >
> > > The "context identifier" looks real handy for that purpose..
> >
> >
> > Yep. We were thinking that too!
> >
> >
> > Thanks for the quick look.
>
> In very quick'n'dirty security analysis the other thing I noticed was
> that if server handshake needs something to be nonce w.r.t. "SS", (e.g.
> happens in GDHE-PSK-CERT modes MT posted I-D about), you need contexts
> anyway, even with just "SS" being PSK.
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Resumption ticket/PSK

[Kyle Rose]

I've modified the branch to use your wording. As Viktor said, it
doesn't address his objection, but it's still a more precise starting
point for further discussion.

Kyle

On Thu, May 19, 2016 at 4:37 PM, Martin Thomson
 wrote:
> On 19 May 2016 at 16:01, Viktor Dukhovni  wrote:
>> Nevertheless, some clients may want to attempt to gain fine-grained
>> protection against correlating back to back or parallel resumption
>> requests.  For this they'd have to ensure that all session tickets
>> are single use, and either perform new handshakes when increasing
>> the number of parallel connections to the server, or somehow obtain
>> more than one ticket within a single session.
>
> I believe that this is the intent of the PR.  I've suggested an
> alternative wording that cleaves closer to your text above.
>
> ___
> 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] Resumption ticket/PSK

[Kyle Rose]

On Thu, May 19, 2016 at 3:19 PM, Viktor Dukhovni  wrote:

> It is good enough.  Clients that want strong protection against
> tracking by session ids can disable session caching entirely, or
> set an idle timeout of ~5 seconds, Ensuring that session re-use
> happens only for a quick burst of connections to the same server.
>
> This is only relevant to a particular type of client, and should
> not be default protocol behaviour.

I suspect the root of arguments for/against this proposal are
philosophical more than technical. I disagree with your contention
above that client-behavior-only is sufficient, because my definition
of "sufficient" includes something about resource usage on the server
in pursuit of the privacy desires of the client, which you implicitly
admit to below:

> If some clients desperately want a fresh ticket with every resumption,
> I think they should explicitly signal that via an optional new
> extension.  I'd have no objection to a zero-length payload extension
> that indicates that a fresh ticket is desired even if the session
> is resumed.

This IMO *would* be good enough from a technical standpoint.

I can't give you a technical argument for my proposal, because the
question fundamentally isn't a technical one: it's a philosophical one
regarding which properties we want this protocol to have by default. I
can only suggest a requirement that TLS, as a privacy protocol, must
at the very least not add to the ability to track clients. Reuse of
session tickets violates this requirement by adding an identifier
transmitted in the clear that allows a passive observer to track a
client much more easily than it would otherwise be able to do.

> I don't see how constantly generating and transmitting new tickets
> helps the server, or helps clients (at fixed network addresses)
> that don't need this protection.  Just a waste of bandwidth and
> needless churn in the client's session cache.

I'm not sympathetic to the bandwidth argument, given how typically
small these things are. I'm also not sympathetic to concerns about
generation, as session ticket generation is logically limited to
low-cost crypto operations (i.e., not public key crypto) that are
probably not significant in comparison to the rest of the key
derivation schedule: certainly, in the typical case thousands or tens
of thousands can be generated for the cost of a single extra PKC
operation. And nothing about this proposal suggests that a client MUST
not use a session ticket more than once, only that the server offer it
the opportunity to resume a session without doing so.

> There are clients where limiting ticket re-use makes sense, these
> clients can take appropriate measures.

My goal is to make it easy for the client to do this in a way that is
efficient for the server. A client can already simply turn off session
caching to gain added privacy, but there are ways to tweak
implementations to help resource-constrained servers, as well.

Kyle

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

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

[Russ Housley]

Thanks for doing the text.

Russ


On May 19, 2016, at 3:22 PM, David Benjamin  wrote:

> If the WG agrees with this change, I've put together a PR here:
> https://github.com/tlswg/tls13-spec/pull/462
> 
> On Tue, May 17, 2016 at 4:14 PM David Benjamin  wrote:
> Reviving this thread, I also think it would also be a good idea if 1.3 did 
> not stripping zeros from Z. Having this logic is rather dubious w.r.t. 
> treating secret data in constant-time. And as Bill Cox mentioned elsewhere in 
> this thread, this odd behavior has caused interoperability issues in the past.
> 
> I don't think we have to be worried about inconsistency with 1.2 as, by the 
> time this happens, we will already know we're speaking 1.3. TLS 1.3 DHE is 
> already a very different beast from TLS 1.2 DHE. At this point, the only 
> thing they meaningfully share is they happen to use the same code points.
> 
> David
> 
> On Thu, Apr 7, 2016 at 10:37 AM Russ Housley  wrote:
> I would prefer to always use the full, known-length byte string for Z.  In my 
> experience, it is better to know the lengths of byte strings instead of 
> stripping leading zeroes.  The difference in the speed of the HKDF 
> computation by omitting the leading zeros is not significant.  Alignment with 
> NIST SP 800-56A is nice, but it is not the reason for my preference.
> 
> Russ
> 
> 
> On Mar 28, 2016, at 11:56 AM, Maarten Bodewes  
> wrote:
> 
> > Hi all,
> >
> > I see that the leading zero is stripped off of the value of Z (the shared 
> > secret) before it is used as input to HKDF. This seems to be compatible 
> > with TLS 1.2. Then again, it is not compatible with e.g. NISP800-56A which 
> > uses the value of Z with the same size of the prime in octets. Furthermore, 
> > it is also different with regards to handling the coordinate X as used in 
> > ECDH.
> >
> > Was this a conscious decision to keep compatibility with TLS? Has the use 
> > of the value of Z including zero octets been considered?
> >
> > Regards,
> > Maarten
> 
> ___
> 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] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

[David Benjamin]

If the WG agrees with this change, I've put together a PR here:
https://github.com/tlswg/tls13-spec/pull/462

On Tue, May 17, 2016 at 4:14 PM David Benjamin 
wrote:

> Reviving this thread, I also think it would also be a good idea if 1.3 did
> not stripping zeros from Z. Having this logic is rather dubious w.r.t.
> treating secret data in constant-time. And as Bill Cox mentioned
> elsewhere in this thread, this odd behavior has caused interoperability
> issues in the past.
>
> I don't think we have to be worried about inconsistency with 1.2 as, by
> the time this happens, we will already know we're speaking 1.3. TLS 1.3 DHE
> is already a very different beast from TLS 1.2 DHE. At this point, the only
> thing they meaningfully share is they happen to use the same code points.
>
> David
>
> On Thu, Apr 7, 2016 at 10:37 AM Russ Housley  wrote:
>
>> I would prefer to always use the full, known-length byte string for Z.
>> In my experience, it is better to know the lengths of byte strings instead
>> of stripping leading zeroes.  The difference in the speed of the HKDF
>> computation by omitting the leading zeros is not significant.  Alignment
>> with NIST SP 800-56A is nice, but it is not the reason for my preference.
>>
>> Russ
>>
>>
>> On Mar 28, 2016, at 11:56 AM, Maarten Bodewes 
>> wrote:
>>
>> > Hi all,
>> >
>> > I see that the leading zero is stripped off of the value of Z (the
>> shared secret) before it is used as input to HKDF. This seems to be
>> compatible with TLS 1.2. Then again, it is not compatible with e.g.
>> NISP800-56A which uses the value of Z with the same size of the prime in
>> octets. Furthermore, it is also different with regards to handling the
>> coordinate X as used in ECDH.
>> >
>> > Was this a conscious decision to keep compatibility with TLS? Has the
>> use of the value of Z including zero octets been considered?
>> >
>> > Regards,
>> > Maarten
>>
>> ___
>> 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] Resumption ticket/PSK

[Viktor Dukhovni]

On Thu, May 19, 2016 at 03:09:23PM -0400, Kyle Rose wrote:

> On Thu, May 19, 2016 at 3:05 PM, Viktor Dukhovni  
> wrote:
> 
> > I think this is much too complicated.  Simpler solution is for
> > clients (browsers and the like for which tracking is an issue) to
> > not reuse sessions when their IP address changes
> 
> I don't think this is sufficient. Reusing session tickets will reveal
> distinguishing information about individual clients behind NAT exit
> points, for instance, even when their internal/RFC1918 addresses don't
> change.

It is good enough.  Clients that want strong protection against
tracking by session ids can disable session caching entirely, or
set an idle timeout of ~5 seconds, Ensuring that session re-use
happens only for a quick burst of connections to the same server.

This is only relevant to a particular type of client, and should
not be default protocol behaviour.

> > The burden of tracking counter-measures should fall squarely on
> > the client.
> 
> I agree that it's up to the client, but there are measures the server
> can take to assist the client while not adding to its full handshake
> burden. IOW, it helps the server, as well.

I don't see how constantly generating and transmitting new tickets
helps the server, or helps clients (at fixed network addresses)
that don't need this protection.  Just a waste of bandwidth and
needless churn in the client's session cache.

There are clients where limiting ticket re-use makes sense, these
clients can take appropriate measures.

If some clients desperately want a fresh ticket with every resumption,
I think they should explicitly signal that via an optional new
extension.  I'd have no objection to a zero-length payload extension
that indicates that a fresh ticket is desired even if the session
is resumed.

-- 
Viktor.

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

Re: [TLS] Key Schedule (PRs #453, #454).

[Ilari Liusvaara]

On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote:
> 
> An additional nice point about this design is that it easily
> accomodates additional keys. For instance, if we had some post-quantum
> key exchange method, we could easily add its key in the final
> Add-Secret or add an extra Add-Secret stage before HS. Similarly, if
> we had a long-term DH key as in OPTLSv1, it could replace the 0 in the
> final Add-Secret.

Just one thing to be careful of: If one has off-handshake counter-
keys[1] (like the now-removed GDH 0-RTT mode had), one needs to hash
those in, or one gets all kinds of crypto screw (which may or may not
be actually exploitable...)

The "context identifier" looks real handy for that purpose...
 
> CONTEXT IDENTIFIER
> 
> The resumption_psk is then used as the PSK for resumption and the
> resumption_context is added to the hash of the handshake messages
> whenever you use them, currently just by appending to the hash, as in:
> 
>Hash(handshake messages) +resumption_context
> 
> This is used *both* to derive the keys and for the input to
> the CertificateVerify/Finished. For convenience, I've

Oh, even better than the original "contexts" proposal, as this is
non-checked. As said, if you ever need off-handshake counterkeys
(as above, and you most probably do for adding any sort of realistic
post-quantum capabilities[2]), this looks real handy for mixing those
in.


[1] Any server-side key that isn't explicitly sent as part of the hand-
shake (most probably having been sent before in prior handshake) but
still is involved in the handshake.

[2] There does exist PQ Key Agreement, but it currently just provoded by
one system that is relatively slow (through not completely impractical)
and severly underanalyzed (major problem).


-Ilari

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

Re: [TLS] Resumption ticket/PSK

[Viktor Dukhovni]

On Thu, May 19, 2016 at 11:31:53AM -0700, Eric Rescorla wrote:

> Yes, I think this would be good text. PR wanted :)

I think this is much too complicated.  Simpler solution is for
clients (browsers and the like for which tracking is an issue) to
not reuse sessions when their IP address changes, and/or keep
session lifetime suitably short on the client end.  In addition
implementing a short "idle timeout" for sessions on the client side
would be quite effective.

The burden of tracking counter-measures should fall squarely on
the client.

-- 
Viktor.

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

[TLS] Resumption ticket/PSK

[Kyle Rose]

Regarding the ability for passive observers' tracking of clients
across connections (and potentially across IPs) via a session ticket
used more than once, should there be any language around recommended
practice here, especially for clients?

An appropriately-configured server can help the client avoid this
problem without performance penalty by issuing a new session ticket on
every connection (for non-overlapping handshakes) and/or multiple on
one (to cover that gap), and a client can help by keeping only the
most recent ticket for a particular session and/or using a given
ticket only once.

Thoughts on adding language under "Implementation Notes" such as:

"Clients concerned with privacy against tracking by passive observers
SHOULD use a PSK/session ticket at most once. Servers SHOULD issue
more than one session ticket per handshake, or issue a new session
ticket on every resumption handshake, to assist in the privacy of the
client while maintaining the performance advantage of session
resumption."

For pure PSK I assume tracking is less of an issue, but I'm happy to
entertain thoughts there, as well.

Kyle

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

[TLS] Key Schedule (PRs #453, #454).

[Eric Rescorla]

PR: https://github.com/tlswg/tls13-spec/pull/454

I have uploaded a PR [technically two PRs, but one builds on the
other, so easier to just read the composition] which resolves two out
of the three significant remaining crypto issues (the remaining one is
the long-running discussion of post-handshake keys). The following
message lays out the changes, which are:

- Adopt a more linear key schedule
- Add a context identifier for resumption


KEY SCHEDULE
We had a lot of comments that the existing key schedule was too hard
to understand and implement and could be simplified under the
assumption that keys were available in a specific order (PSK then DH
ZZ). I've been working together with Karthik, Hugo, Antoine, and
others to produce something cleaner. (Note: I believe they consider
this acceptable, but that doesn't mean they wouldn't have designed
every piece exactly as I have.)


The overall key schedule looks like this:

 0
 |
 v
   PSK ->  HKDF-Extract
 |
 v
   Early Secret  --> Derive-Secret(., "early traffic secret",
 | ClientHello)
 | = early_traffic_secret
 v
(EC)DHE -> HKDF-Extract
 |
 v
  Handshake
   Secret -> Derive-Secret(., "handshake traffic secret",
 | ClientHello + ServerHello)
 | = handshake_traffic_secret
 v
  0 -> HKDF-Extract
 |
 v
Master Secret
 |
 +-> Derive-Secret(., "application traffic secret",
 | ClientHello...Server
Finished)
 | = traffic_secret_0
 |
 +-> Derive-Secret(., "exporter master secret",
 | ClientHello...Client Finished)
 | = exporter_secret
 |
 +-> Derive-Secret(., "resumption master secret",
   ClientHello...Client Finished)
   = resumption_secret

  Derive-Secret(Secret, Label, Messages) =
   HKDF-Expand-Label(Secret, Label,
 Hash(Messages) + resumption_context, L))


Derive-Secret is just a wrapper around HKDF-Expand-Label, for reasons
indicated below. If a key is missing you just use 0s.

The general pattern here is that the secrets shown down the left side
of the diagram are just raw entropy without context, whereas the
secrets down the right side include handshake context and therefore
can be used to derive working keys without additional context.  All
the working keys (both encryption keys and finished keys) are
generated using HKDF-Expand-Label off of the traffic secrets.

This design is motivated by the following principles:

- Separate out adding entropy from adding context.
- Incorporate the transcript once and then derive from there.
- Have a narrow, consistent interface for generating the leaf keys
  so they can just start with a base key.
- Derive from keys as soon as practical so that you can destroy them
  (thus the final call to Add-Secret, which isolates the
  Finished keys from the MS).

An additional nice point about this design is that it easily
accomodates additional keys. For instance, if we had some post-quantum
key exchange method, we could easily add its key in the final
Add-Secret or add an extra Add-Secret stage before HS. Similarly, if
we had a long-term DH key as in OPTLSv1, it could replace the 0 in the
final Add-Secret.

One thing I want to call out explicitly is that we are using
HKDF-Expand-Label with the output of HKDF-Expand-Label. This is
cryptographically fine, but means that you need an implementation of
the individual HKDF Expand/Extract primitives. As far as I can tell,
this isn't a hardship for anyone, but please speak up if it is. The
advantage of this is that you remove unnecessary crypto operations.


CONTEXT IDENTIFIER
PR: https://github.com/tlswg/tls13-spec/pull/454

Hugo and Karthik both independently suggested that it would be nice to
have some identity/context bound into the PSK handshake. The second PR
accomodates that by deriving two values from the RMS:

   resumption_psk = HKDF-Expand-Label(resumption_secret,
  "resumption psk", "", L)

   resumption_context = HKDF-Expand-Label(resumption_secret,
  "resumption context", "", L)

The resumption_psk is then used as the PSK for resumption and the
resumption_context is added to the hash of the handshake messages
whenever you use them, currently just by appending to the hash, as in:

   Hash(handshake messages) +resumption_context

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

[Aaron Zauner]

Hi,

> The first step of our attack involves attacker controlled content. So yes 
> (phishing, unauthenticated HTTP, selective company DPI etc.). In our example 
> we use a local proxy to carry out the attack. I hope I can post a full 
> version of the actual paper and PoC to this thread soon.

https://eprint.iacr.org/2016/475
https://github.com/nonce-disrespect/nonce-disrespect

(data-sets should be indexed by scans.io in a bit)

Aaron


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] draft-ietf-tls-falsestart rfc editor note done

[Stephen Farrell]

Dear IESG secretariat, (bcc'd),

As discussed on the telechat I've updated the intended
status in the tracker, added an RFC editor note asking
them to change the header and cut'n'pasted the writeup
into it's proper place. So I think this one is ready
for you to send the usual approval announcement on
Monday. (If anyone sees a glitch there, just ping me
and I'll fix stuff.)

Thanks,
S.



smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls