Subject: [TLS] Unifying tickets and sessions

From: "Salz, Rich" <[email-masked]>
Date: Mon, 20 Oct 2014 16:11:21 -0400

It's proposed that we unify tickets and sessions at the protocol level.

--------------------------------

For 1.3 we bring in the extension definitions from 5077. For the wire format, it doesn't matter if the information is a session identifier (a short string, referring to state maintained on the server) or a ticket (the actual crypto state, stored on the client). Perhaps to be general, we call it session token.

A TLS 1.3 client MUST send an empty session_id field. It may send a ticket extension. If the server is willing to accept the crypto state, it sends a "1" in the returned session_id field, otherwise it sends an empty session_id. This is the only use of session_id in TLS 1.3.

The session token may either be an opaque identifier of local server state, or a serialization of the state the server needs, encrypted with some key. General security considerations require that this information not be kept on long-lived media, and that the identifier or encryption key be rotated periodically. These are server-side implementation details.

The session token can be used to tie together multiple transactions with a loss of forward secrecy. Clients can always omit the session token. Servers SHOULD set the lifetime to an appropriate value (and MUST NOT be more than nn hours).  [Where nn is TBD; either 24 or 48.]

"MUST NOT" for more than 24 hours seems to strict. If you rotate keys every 24 hours, session tickets end up being valid for up to 2 * 24 hours (+ fudge) unless you start to reject them while the server still has the key, which seems pointless. Depending on how you set up cron, that could be 49 hours+ in practice due to DST.

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Mon, 20 Oct 2014 22:58:06 +0200

Nice to see this merge and I directly +1 the token wording.

How about **MUST NOT** for more than 24 hours for the encryption key and 
**MUST NOT** for more than 3 x 24 hours for decryption keys? That should 
account for all possibilities and one can use three keys to achieve it 
that rotate at the same intervals.

The RFC should clarify that the negotiated cipher **MUST** be honored 
when encrypting the state that will be sent to the client. [1]

Regards
Richard

[1] https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf

On 10/20/2014 10:11 PM, Salz, Rich wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

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

> Nice to see this merge and I directly +1 the token wording.
++

> when encrypting the state that will be sent to the client. [1]
While I'm sympathetic with the goal, I'm afraid that will complicate
implementations more than necessary. How about requiring to use a key length at
least a high as the highest supported ciphersuite instead?

One concern is that it's generally not recommended to use the same key with
different ciphers, so implementations would need to derive a key for each cipher
from a master key. That's certainly doable, but it adds a bit of complexity.

Another point is that we need to be sure that the same ciphersuite be selected
on resumption than on the original handshake. Since some extensions are needed
to choose the ciphersuite (at least SNI, signature_algorithms, the EC
extensions), it means those extensions need to be parsed before picking the
ciphersuite but the session_ticket extension after picking it. Nothing
insurmountable obviously, but again, complexity.

(Thinking while writing.) Perhaps more importantly, if a ciphersuite becomes
weak enough, an attacker could create tickets by forcing the server to
decrypt/authenticate them with the least secure ciphersuite it's willing to
accept, and use that to bypass client auth and.or mount other kind of attacks in
the server.

I'm not so sure the last paragraph is a real threat, but if it is, then it's
probably much safer to pick a single trusted cipher (or AEAD-cipher) and
conservative key size (such as 256 bits) for all tickets: of course it creates
an upper bound on the security of all sessions, but also a lower bound on ticket
authentication.

Manuel.

---

From: Brian Smith <[email-masked]>
Date: Mon, 20 Oct 2014 16:34:50 -0700

Rich,

I think your suggestion is a very good idea. In particular, note that
session tickets could be encrypted during the handshake, but
ServerHello.session_id
cannot. This is valuable because it allows for a level of unlinkability
between the initial connection for a session and a resumption of that
session. If the server rotates tickets for a session on every connection
(resumption or otherwise), this unlinkability would be maintained against
all connections for a session. This seems like a valuable privacy feature.

On Mon, Oct 20, 2014 at 1:11 PM, Salz, Rich <[email-masked]> wrote:

> For 1.3 we bring in the extension definitions from 5077. For the wire
> format, it doesn't matter if the information is a session identifier (a
> short string, referring to state maintained on the server) or a ticket (the
> actual crypto state, stored on the client). Perhaps to be general, we call
> it session token.
>

I suggest, to minimize changes from RFC 5077, and to minimize confusion,
that we continue to call it a session ticket.

A TLS 1.3 client MUST send an empty session_id field. It may send a ticket
> extension. If the server is willing to accept the crypto state, it sends a
> "1" in the returned session_id field, otherwise it sends an empty
> session_id. This is the only use of session_id in TLS 1.3.
>

This change from RFC5077 is not necessary. You just make this change
instead:

-  If a server is planning on issuing a session ticket to a client that
-  does not present one, it SHOULD include an empty Session ID in the
-  ServerHello.  If the server rejects the ticket and falls back to the
-  full handshake then it may include a non-empty Session ID to indicate
-  its support for stateful session resumption.  If the client receives
-  a session ticket from the server, then it discards any Session ID
-  that was sent in the ServerHello.

-

-  When presenting a ticket, the client MAY generate and include a
-  Session ID in the TLS ClientHello.  If the server accepts the ticket
-  and the Session ID is not empty, then it MUST respond with the same
-  Session ID present in the ClientHello.  This allows the client to
-  easily differentiate when the server is resuming a session from when
-  it is falling back to a full handshake.  Since the client generates a
-  Session ID, the server MUST NOT rely upon the Session ID having a
-  particular value when validating the ticket.  If a ticket is
-  presented by the client, the server MUST NOT attempt to use the
-  Session ID in the ClientHello for stateful session resumption.

-  Alternatively, the client MAY include an empty Session ID in the

-  ClientHello.  In this case, the client ignores the Session ID sent in

-  the ServerHello and determines if the server is resuming a session by

+  The client MUST always include an empty Session ID in the ClientHello.

+  The server MUST always include an empty Session ID in the ServerHello.

+  The client determines if the server is resuming a session by

the subsequent handshake messages.

This is a smaller change for implementations and leaks less
information in the plaintext part of the handshake. In particular, on
top of this change, you could in theory make it so that the full
handshake and the resumption handshake look the same on the wire
(modulo leaking the distinction via timing). As I said before [2], I
think that is worth trying to accomplish, both for maximizing interop
as well as improving privacy.

Cheers,

Brian

[1] https://tools.ietf.org/html/rfc5077#section-3.4
[2] http://www.ietf.org/mail-archive/web/tls/current/msg10903.html

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Oct 2014 23:58:33 +0000

> > when encrypting the state that will be sent to the client. [1]

I am having trouble parsing the original suggestion above.

> least a high as the highest supported ciphersuite instead?

Does it mean (as I think you're saying) that session tickets MUST
be encrypted with the session's negotiated ciphersuite?  That seems
rather unmanageable.  A single sufficiently strong key is likely
far more realistic.

With keys for clusters of servers rotated by code external to the
TLS library, asking for a key for every algorith/size is impractical.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Oct 2014 23:00:03 -0700

>    the subsequent handshake messages.

I'm going to suggest going one further.  Remove the session ID from
the ServerHello entirely.

---

From: Brian Smith <[email-masked]>
Date: Mon, 20 Oct 2014 23:11:31 -0700

> the ServerHello entirely.

That would be dependent on having TLS 1.3 use a different value from TLS
1.2 in the ServerHello.server_version field, which appears to cause too
many interop problems to be viable. To avoid creating unnecessary interop
problems, it is better to make the TLS 1.3 handshakes look as much like TLS
1.2 resumption handshakes as possible. Or, at least, avoid making
gratuitous changes to the format of ServerHello and other plaintext
messages.

Cheers,
Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Oct 2014 02:11:53 -0400

I think the spec should mention the issues of re-using keys.  But it should stay silent on which crypto suite to use.  It's totally a server issue; it could use ROT-13 if it wanted.

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Oct 2014 02:15:14 -0400

I agree with Brian, saving the field seems like the wrong interop tradeoff.

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Tue, 21 Oct 2014 09:10:29 +0200

I was to vague in regards to implementation, sorry. Of course we only 
want a single key or rather one long blob of random data to manage. The 
idea of using a key length of at least the 'highest supported 
ciphers'[*] sounds very good to me and would honor the ciphers in use. 
By always using a 128 bit key (current OpenSSL implementation) higher 
ciphers are essentially downgraded.

[*] Better would be 'from all ciphers in use' otherwise one ends up with 
a (insert ridiculous high value here) bit key while only using 128 bit 
ciphers in the configuration. Dropping the key if a new stronger 
configuration is loaded seems like a good idea to me at this point. I'm 
looking at this from a performance perspective and glimpsing over to the 
fact that the cryptography community agrees that 128 bit security will 
be enough for the next 10 to 20 years.[2] I really can't tell if this 
would be problematic from an implementation point of view. I think that 
single hosts won't have a problem here and I guess that it wouldn't be 
for clusters as well. The cluster configuration should be in sync but it 
could become a problem if one node has a differing configuration (for 
whatever reason). What opinion/insights do you have on this?

Regards
Richard

[1] http://www.keylength.com/

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Oct 2014 00:27:35 -0700

On 21 October 2014 00:10, Richard Fussenegger, BSc
<[email-masked]> wrote:
> The idea of using a key length of at least the 'highest supported
> ciphers'[*] sounds very good to me

There is no technical reason that you would want a minimum length on
the ticket.  If you are using stateful resumption, a ticket of "1" or
"2" is perfectly sufficient.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Oct 2014 16:34:14 +0000

On Tue, Oct 21, 2014 at 09:10:29AM +0200, Richard Fussenegger, BSc wrote:

> I was to vague in regards to implementation, sorry. Of course we only want a
> single key or rather one long blob of random data to manage. The idea of
> using a key length of at least the 'highest supported ciphers'[*] sounds
> very good to me and would honor the ciphers in use. By always using a 128
> bit key (current OpenSSL implementation) higher ciphers are essentially
> downgraded.

OpenSSL gives applications the freedom to use alternative keys and algorithms:

    http://www.postfix.org/postconf.5.html#tls_session_ticket_cipher

For now Postfix defaults to aes-128-cbc, I might change the default
to aes-256-cbc before 2.12 ships.

-- 
	Viktor.

---

From: Richard Fussenegger <[email-masked]>
Date: Tue, 21 Oct 2014 19:34:38 +0200

Many thanks for this information, didn't know that until now.

Richard

---

From: David Leon Gil <[email-masked]>
Date: Tue, 21 Oct 2014 14:33:43 -0400

On Tue, Oct 21, 2014 at 3:10 AM, Richard Fussenegger, BSc
<[email-masked]> wrote:
> I'm [. . .] glimpsing over to the fact that the
> cryptography community agrees that 128 bit security will be enough for the
> next 10 to 20 years.[2]

This really isn't true. See djb's "matching AES security" at
https://www.ietf.org/mail-archive/web/cfrg/current/msg04820.html

Summarizing: The workfactor of a multi-target attack is much lower for
symmetric-key crypto than for attacks against asymmetric-key crypto.
This is exactly the sort of attack that is useful for mass
surveillance.

We need to start moving away from AES-128 now, not in 10 years.

(Note that a number of cryptographers think that 2^90 operations per
year is feasible today; djb is lowballing the number a bit.)

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Tue, 21 Oct 2014 21:20:43 +0200

> "2" is perfectly sufficient.
I think there's a misunderstading here: it's about the size of the *key* used to
encrypted the ticket in case it's an actual ticket (as opposed to the more
general "token" notion).

Manuel.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 22 Oct 2014 14:56:40 +0200

> year is feasible today; djb is lowballing the number a bit.)

That assumes that you have the space to store all those communications, most 
of which will be utter garbage for you (spdy/HTTP2.0 as a whole and HTTP1.1 
keep alive connections), then you need to have the ability to reference all 
those 2^50 keys in close to real time.

Yes, it doesn't require "hard" computation, but it does require massive 
amounts of relatively fast memory.

It's a classic memory-time tradeoff, isn't it?

And looking at current computers, time is cheaper and is getting cheaper 
faster than memory is, as it has for at least past 20 years...

-- 
Regards,
Hubert Kario

---

From: David Leon Gil <[email-masked]>
Date: Wed, 22 Oct 2014 10:27:32 -0400

There are, obviously, two things a server should be able to use for a
unified session id/ticket:

 - An opaque identifier
 - Encrypted session state using a construction like RFC 5077's.

Right now, RFC 5077 recommends: AES-128 with a 128-bit key and
HMAC-SHA256 with a 256-bit key.

Or, uselessly high 256-bit security against active attackers, and
uselessly low 128-bit security strength against global passive
adversaries.

There should be a recommended session ticket construction at a 256 bit
security strength for privacy to replace RFC 5077 s.4's.

--

On Wed, Oct 22, 2014 at 8:56 AM, Hubert Kario <[email-masked]> wrote:
> That assumes that you have the space to store all those communications,

I frankly don't understand this.

According to the newspapers, at least, the NSA *does* store *all*
encrypted communications pending eventual decryption. So evidently
they do, at least.

> then you need to have the ability to reference all those 2^50 keys in close to real time.

This is a few petabytes of data, or a few thousand 1 TB SSDs. This is
not a large amount of data.

> amounts of relatively fast memory.

No. It doesn't. It requires less than one cipher block per key for
most of the computation. (The main expense is memory bandwidth.)

> It's a classic memory-time tradeoff, isn't it?

No. The gains are better than linear. See
http://cr.yp.to/snuffle/bruteforce-20050425.pdf, but for "circuit"
read "graphics card/SPU/MIC".

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Oct 2014 15:16:23 +0000

> security strength for privacy to replace RFC 5077 s.4's.

The same construction works just fine with AES-256-CBC, so it is
merely a matter of updating the draft to recommend AES-256-CBC for
the encryption.  (I've updated the Postfix default ticket cipher
to AES-256-CBC as planned for the next release).

Mind you, I would not call AES-128-CBC "uselessly low".  Assume
classical attacks, and suppose circuitry running at 1W power-draw
with 2^16 parallel AES units, each of which does 2^32 AES-128
encryptions per second.  The total energy requirement for an AES-128
brute force attack is then:

	(2^128 / 2^16 / 2^32) J = 2^80 J

If this is powered by a sizeable ~4 GW (2^32 W) power plant, it
will take 2^48 seconds to generate the requisite energy.  With
somewhat less than 2^25 seconds per year, we're looking at ~2^23
or ~8 million years of output from such a plant.

If we assume attacks that reduce AES from 128 to 120 bits, that
number comes down to a "mere" 2^15 or 32K years of 4GW power.  The
energy cost is prohibitive, and we've not taken into account the
costs of storage if this is to be a pre-computation for a space-time
trade-off to attack multiple encrypted payloads.

And all this ignores the fact that AES is rarely used in ECB mode
with the same fixed plaintext encrypted by all parties under varying
keys.  The use of random IVs or similar "whitening" makes
pre-computation substantially less effective.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 22 Oct 2014 13:46:07 -0500

> I am having trouble parsing the original suggestion above.

Even parsed as the context implies, there's problems: a) the client
can't verify that the ticket is encrypted in any given cipher, b) why
on Earth should the server let the client choose what cipher is used
for the Ticket?, c) given (a), what is to be gained by any party from
the server using the client's desired cipher for encrypting the
ticket?

>> least a high as the highest supported ciphersuite instead?

This is just as silly.  The server should choose what cipher to use, full stop.

> rather unmanageable.  A single sufficiently strong key is likely

Yes.

> TLS library, asking for a key for every algorith/size is impractical.

One would derive keys for all ciphers from a single cluster master
key.  Nonetheless, it's just plain silly to let the client/connection
dictate how to encrypt the ticket -- that's the server's prerogative.

Nico
--

---

From: Richard Fussenegger <[email-masked]>
Date: Wed, 22 Oct 2014 20:59:05 +0200

> the server using the client's desired cipher for encrypting the
[erm] That was not the original suggestion and 'negotiated cipher' 
doesn't imply that the cipher was chosen by the client. It's merely a 
fact that the server and the client have to negotiate a cipher before 
they can establish an encrypted communication channel. It doesn't matter 
how they do that, but at some point they'll negotiate a cipher (or no 
connection is established at all).

If the two of us agree upon using AES-256, wouldn't you be a little bit 
disappointed if I send you an encrypted ticket of that stuff we agreed 
upon to encrypt with AES-256 that is actually encrypted with AES-128? 
You wouldn't notice, because you can't read the ticket and trust that I 
honor our negotiations (after all, we were communication through a 
AES-256 secured channel which we negotiated, didn't we).

Well—fact is—today web servers are doing exactly that with tickets and 
that's why some people have problems with them and that's what I was 
referring to in my very first mail (quoted above).

> This is just as silly.  The server should choose what cipher to use, full stop.
It does.

>> rather unmanageable.  A single sufficiently strong key is likely
I already agreed upon the single key solution.

> dictate how to encrypt the ticket -- that's the server's prerogative.
That's impractical for administrators that aren't running dedicated key 
generation servers within their own data center.

Actually everything Viktor Dukhovni said is perfectly correct and Nico I 
think you may have misunderstood a few things here.

Regards
Richard

---

From: Nico Williams <[email-masked]>
Date: Wed, 22 Oct 2014 14:43:03 -0500

On Wed, Oct 22, 2014 at 08:59:05PM +0200, Richard Fussenegger wrote:
> doesn't imply that the cipher was chosen by the client. It's merely
> [...]

It does imply that the client at least constrained the choice of cipher.

This is unnecessary complexity.  I thought we were all for simplifying.

> If the two of us agree upon using AES-256, wouldn't you be a little
> bit disappointed if I send you an encrypted ticket of that stuff we
> agreed upon to encrypt with AES-256 that is actually encrypted with
> AES-128? You wouldn't notice, because you can't read the ticket and

No: because I couldn't prove that it isn't AES-256, because the server
couldn't prove that it is, because the only way to do so would be for
the server to give me its ticket encryption key, which would defeat the
purpose.

Well, I tell a lie: the server could give the client the ticket
encryption key for expired tickets issued to the same client.  But this
means having a per-client set of keys, which means having some client ID
to derive keys from, probably a public key that the client can
demonstrate it has possession of the corresponding private key, and so
on and so forth -- all much, much too complex.

The client already has to trust the server for all sorts of things.
Having to trust it to handle ticket encryption appropriately is not much
more to ask, especially since any reasonable choice on the server's part
is such a large optimization/win over not having session resumption that
it's worth the risks of the complexity of session resumption (because
the alternative is risking less deployment).

> [...]

So you want the server to say "fine, I'm using the XYZ cipher that you
wanted", and now what changes?  The server can't prove that it did / the
client can't prove that the server didn't.  What did we gain, besides
more [in this case worth-less] complexity?

One answer: someone could audit the server's compliance with this.  But
who?!  Not the client.  Some authority perhaps, which then opens a can
of worms.  And then what do we gain?  What about clients who end up
getting weaker ticket encryption ciphers than the server's preference?

Nico
--

---

From: Richard Fussenegger <[email-masked]>
Date: Wed, 22 Oct 2014 22:27:55 +0200

This isn't getting anywhere here, I'll try again but only once.

> This is unnecessary complexity.  I thought we were all for simplifying.

Negotiation -> TLS Handshake [1] -> ssl_prefer_server_ciphers=on [2]

The client will always create constraints because clients aren't 
supporting only the strongest ciphers and protocols. That's the reason 
why people configure more than one cipher and try to rescue SSL 3.0 from 
the POODLE.

> the alternative is risking less deployment).

Uh … nope …

> more [in this case worth-less] complexity?

Uh … nope …

> getting weaker ticket encryption ciphers than the server's preference?

Telling people to use appropriate keys during all involved steps is 
exactly what I propose and absolutely nothing of what you are alleging 
me of.

 > Key strength **MUST** be at least of equal strength for ticket/token 
encryption of the strongest supported cipher. Thus not downgrading any 
of the available ciphers that can be used for communication. [3]

I'm getting the uncomfortable feeling that all I've written so far was 
in Klingon …

Regards
Richard

[1] 
http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS_HANDSHAKE 
"Negotiating a secure TLS tunnel is a complicated process, […]"
[2] 
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_prefer_server_ciphers
[3] The RFC shouldn't use the word 'negotiated' because it apparently 
isn't understood correctly.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Oct 2014 18:18:35 -0400

I understand the concern:  the ticket should be encrypted at least as strongly as the bulk encryption of the traffic.

But that concern is misplaced (a server could have a one-time-pad and do XOR), and it is not up to the client to tell the server how to operate.  The client can always not send the ticket if it has concerns, and is able to justify/prove them.

---

From: Richard Fussenegger <[email-masked]>
Date: Thu, 23 Oct 2014 01:10:46 +0200

> I understand the concern:  the ticket should be encrypted at least as strongly as the bulk encryption of the traffic.

Exactly :)

> […] and it is not up to the client to tell the server how to operate.  The client can always not send the ticket if it has concerns, and is able to justify/prove them.
>

I never proposed that the client should do anything; not sending or even 
accepting tickets is what clients with concerns should do. Exactly as it 
is now!

Manuel's remarks to my original proposal are great additions to the 
discussion 
(http://www.ietf.org/mail-archive/web/tls/current/msg14048.html), so let 
me try to sum it up once more incorporating what he said and thought of.

Regarding https://tools.ietf.org/html/rfc5077#section-5.5

  * The server has a list of server-side supported cipher suites of
    which the strongest is using SUPER-CIPHER-9999. This means that ALL
    tickets/tokens **MUST** be encrypted with at least SUPER-CIPHER-9999
    on the server-side.
  * The server has a list of server-side supported cipher suites of
    which the strongest is using GENERIC-CIPHER-123. This means that ALL
    tickets/tokens **MUST** be encrypted with at least
    GENERIC-CIPHER-123 on the server-side.

  * It doesn't matter which cipher suite was actually used for the tunnel.
  * It doesn't matter which client it is.
  * Nothing of all that complexity matters!
  * The only thing that the server has to make sure is that it doesn't
    downgrade the strongest server-side supported/configured cipher.
    Simply saying that all tickets have to be (e.g.) AES-256 isn't going
    to cover it, because this would result in the same situation as we
    have it right now with OpenSSL and AES-128-CBC. It's like you said
    Rich, the RFC should stay silent on the actual algorithms that are
    used but it should ensure that developers aren't implementing
    something that will constantly downgrade encryption.

Regarding https://tools.ietf.org/html/rfc5077#section-5.6

  * The server **MUST NOT** have more than one encryption key which
    **MUST** be rotated (used as decryption key and replaced by a newly
    generated encryption key) or discarded after at least 24 hours after
    generation.
  * The server **MAY** have multiple decryption keys which **MUST** be
    discarded after at least 72 hours after generation.

Good example for clustering and rotation 
https://blog.twitter.com/2013/forward-secrecy-at-twitter
Good example for how this proposal could be implemented was partly given 
by Viktor.

On a last note, I like the idea of derived keys but it makes clusters 
much more complicated and I honestly don't think that this is necessary. 
With many possible algorithms to choose from, how could anyone know how 
the ticket was actually encrypted? (Right now that would be easy to know.)

Richard

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 23 Oct 2014 01:22:27 +0200

> This is just as silly.  The server should choose what cipher to use, full stop.
I'm afraid you didn't understand what I was actually trying to suggest, but my
sentence was ambiguous: my suggestion was that the server choose what cipher to
use, by looking at what ciphersuites it is prepared to negotiate, and then
picking the most secure symetric cipher from this list (or one of those with
maximal key size).

Eg, if a server is only going to negotiate 128-bit suites because it thinks it's
enough and doesn't want to waste cycles on more than that, then encrypting the
tickets with a 128-bit key is fine. If it is prepared to negotiate 256-bit suite
with some clients, it should encrypt the tickets with a 256-bit key.

Manuel.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 23 Oct 2014 01:27:08 +0200

On 23/10/2014 00:18, Salz, Rich wrote:
> I understand the concern:  the ticket should be encrypted at least as
> strongly as the bulk encryption of the traffic.
> 
Yep.

> But that concern is misplaced (a server could have a one-time-pad and do
> XOR), and it is not up to the client to tell the server how to operate.  The
> client can always not send the ticket if it has concerns, and is able to
> justify/prove them.
> 
I don't think this is correct. Once the server emits the ticket (if we're
speaking about a ticket that contains session state including the MS), it's out
there in the clear* for an attacker to play with. That the client chooses to
ignore the ticket doesn't change that fact.

The server is fully responsible of protecting key material and not sending it
with a protection much weaker than the one used for the traffic.

* For TLS 1.2 I mean. For 1.3 that might be different.

Manuel.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Oct 2014 20:56:56 -0700

On 22 October 2014 16:10, Richard Fussenegger <[email-masked]> wrote:
> MUST

The only concern here is your insistence on the use of that word,
particularly in the captilized form.

I don't think that anyone objects to a recommendation of the sort you
describe.  I suspect that many will happily acknowledge that using the
weakest cipher on offer isn't advisable either, since the floor on
cipher acceptance is unfortunately low due to a pressure on servers to
be maximally compatible.  So we can *recommend* the use of the
strongest cipher a server is willing to apply.  ...and RFC 5077 pretty
much says that (and more).

But your requirement remains completely unverifiable and therefore
unenforceable.  Using "MUST" is threatening to use a weapon you
provably cannot use.

---

From: Richard Fussenegger <[email-masked]>
Date: Thu, 23 Oct 2014 11:42:33 +0200

> particularly in the captilized form.

Not insisting, you're the first to raise concerns in this regard and we 
should of course discuss that if it's the problem with the proposal.

> ...and RFC 5077 pretty much says that (and more).

Yes, but the result of these recommendations is that implementations are 
always using AES-128-CBC and ignoring any supported ciphers (that's the 
concern here at hand).

> unenforceable.

What exactly is unverifiable?

> “[…] the ticket key might be weaker than the cipher used for the 
> connection. For example, OpenSSL uses 128-bit AES keys for this purpose.”
> —Ivan Ristić: “Bulletproof SSL and TLS”, p. 58, online: 
> https://www.feistyduck.com/books/bulletproof-ssl-and-tls/

> “128 bit of security is all you get (at best), regardless of the 
> cipher which has been negociated” [sic!]
> —Florent Daigniere: “TLS “Secrets””, p. 8, online: 
> https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf

> “The encryption of the SessionTicket depends on 128-bit AES with the 
> IV field.”
> —Joey Dreijer and Sean Rijs: “Perfect forward not so secrecy”, p. 6, 
> online: 
> https://os3.nl/_media/2013-2014/courses/ssn/projects/perfect_forward_not_so_secrecy_report.pdf

Richard

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 23 Oct 2014 15:34:01 +0200

hi *,

i really like the initial suggestion by rich salz.

> On 22.10.2014, at 16:27, David Leon Gil <[email-masked]> wrote:
> 
> HMAC-SHA256 with a 256-bit key
hash functions have n/2 security. 

> security strength for privacy to replace RFC 5077 s.4's.

it's more likely that they'd use specially designed integrated circuits/ASICs/FPGAs - if you use google you'll even find companies that sell these to 'government'.

as somebody also working in HPC: the real tradeoff is still time/energy/money. how much does one want to spend for a single decrypted communication?

btw: the whole quantum discussion is just out of place here;
1) we're far far far away from a feasible solution. yeah all that media coverage sounds dangerous; that doesn't make it real
2) implementations
3) the appropriate reaction should be to use post-quantum crypto algorithms instead of doubling the keysize for existing ones. I don't know of any algorithm that can be used for a protocol like TLS as of now.

(mobile)

Aaron

> https://www.ietf.org/mailman/listinfo

---

From: Hubert Kario <[email-masked]>
Date: Thu, 23 Oct 2014 16:03:16 +0200

On Thursday 23 October 2014 01:22:27 Manuel Pégourié-Gonnard wrote:
> >>> implementations more than necessary. How about requiring to use a key
> >>> length at least a high as the highest supported ciphersuite instead?
> > 
> I'm afraid you didn't understand what I was actually trying to suggest, but
> my sentence was ambiguous: my suggestion was that the server choose what
> cipher to use, by looking at what ciphersuites it is prepared to negotiate,
> and then picking the most secure symetric cipher from this list (or one of
> those with maximal key size).
> 
> Eg, if a server is only going to negotiate 128-bit suites because it thinks
> it's enough and doesn't want to waste cycles on more than that, then
> encrypting the tickets with a 128-bit key is fine. If it is prepared to
> negotiate 256-bit suite with some clients, it should encrypt the tickets
> with a 256-bit key.

While it may negotiate AES-256 (because it wants to interoperate with clients 
that are configured to not to present weaker ciphers), doesn't mean that it as 
a whole is configured to the 256 bit level of security.

With TLS1.2 it may sign the (EC)DHE parameters using SHA-1, it may use RSA key 
exchange using only 2048 bit keys, it may be just a local proxy server that is 
hard coded to connect using AES-128 with the backed servers over open 
Internet.

Yes, server should encrypt the tickets with as strong algorithm as its most 
secure cipher, but there are many situations where it's not necessary. "MUST" 
is certainly not applicable.

-- 
Regards,
Hubert Kario

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Oct 2014 14:22:04 +0000

> hash functions have n/2 security. 

The n/2 is collision resistance.  Here the hash function is used
in an HMAC construction.  I don't believe that n/2 applies for
HMAC-SHA2-256.

-- 
	Viktor.

---

From: Richard Fussenegger <[email-masked]>
Date: Thu, 23 Oct 2014 16:21:35 +0200

> 3) the appropriate reaction should be to use post-quantum crypto algorithms instead of doubling the keysize for existing ones. I don't know of any algorithm that can be used for a protocol like TLS…

NTRU [1][2] is the only one that is said to be post-quantum [3][4] and 
it even has a library [5] and seems to have very good performance [6][7].

Richard

[1] https://tools.ietf.org/html/draft-ietf-tls-ntru-00
[2] https://en.wikipedia.org/wiki/NTRUEncrypt
[3] 
http://middleware.internet2.edu/idtrust/2009/papers/07-perlner-quantum.pdf
[4] 
http://94.242.221.125/bookreader.php/135832/Bernstein_-_Post_Quantum_Cryptography.pdf
[5] http://www.yassl.com/yaSSL/Home.html
[6] 
https://www.securityinnovation.com/uploads/ntru_speed_benchmark_research.pdf
[7] http://paper.ijcsns.org/07_book/200708/20070812.pdf

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 23 Oct 2014 16:26:07 +0200

> hard coded to connect using AES-128 with the backed servers over open 
Yes, good points.

> is certainly not applicable.
I agree, and I'm not advocating for a MUST.

Manuel.

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 23 Oct 2014 16:35:27 +0200

> On 23.10.2014, at 16:22, Viktor Dukhovni <[email-masked]> wrote:
> 

oh. that's true.

thanks for pointing that out.

Aaron

---

From: Douglas Stebila <[email-masked]>
Date: Thu, 23 Oct 2014 15:11:43 +0000

On Oct 23, 2014, at 4:21 PM, Richard Fussenegger <[email-masked]> wrote:
> NTRU [1][2] is the only one that is said to be post-quantum [3][4] and it even has a library [5] and seems to have very good performance [6][7].

There are other algorithms besides NTRU.  Here is some recent work by some colleagues and I on using the ring learning with errors (ring-LWE) problem for key exchange in TLS.

	http://eprint.iacr.org/2014/599
	links to source code: http://www.douglas.stebila.ca/research/papers/bcns14

Douglas

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 23 Oct 2014 15:18:41 +0000

I've three concerns with NTRU:
- licensing (patents);
- (large) key size; 
- lack of (unbroken) digital signature.

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Richard Fussenegger [mailto:[email-masked]]
Sent: Thursday, October 23, 2014 09:21 AM
To: [email-masked] <[email-masked]>
Subject: Re: [TLS] Unifying tickets and sessions

Richard

---

From: Richard Fussenegger <[email-masked]>
Date: Thu, 23 Oct 2014 19:21:08 +0200

On 10/23/2014 4:03 PM, Hubert Kario wrote:
> While it may negotiate AES-256 (because it wants to interoperate with 
> clients that are configured to not to present weaker ciphers), doesn't 
> mean that it as a whole is configured to the 256 bit level of 
> security. With TLS1.2 it may sign the (EC)DHE parameters using SHA-1, 
> it may use RSA key exchange using only 2048 bit keys, it may be just a 
> local proxy server that is hard coded to connect using AES-128 with 
> the backed servers over open Internet. Yes, server should encrypt the 
> tickets with as strong algorithm as its most secure cipher, but there 
> are many situations where it's not necessary. "MUST" is certainly not 
> applicable. 

Those are good and valid arguments for a RECOMMENDED regarding session 
ticket/token key algorithms or simply dropping one word and uppercasing 
another does the trick (?):

https://tools.ietf.org/html/rfc5077#section-5.5
>    o  The keys and cryptographic protection algorithms should be at
>       least 128 bits in strength.  Some ciphersuites and applications
> -     may require cryptographic protection greater than 128 bits in
> +     REQUIRE cryptographic protection greater than 128 bits in
>       strength.

But the MUST regarding key rotation, key discarding, and key count hard 
limits is still appropriate in my opinion because PFS is a MUST in TLS 
1.3 (unless this has changed and I didn't read about it).

To answer Rich Salz's initial question, if we'd have 24h encryption and 
72h decryption on the server-side (as I proposed and nobody said 
anything pro or contra) the MUST NOT for ticket/token lifetime would 
become 48h.

server-side key:
          24h enc
|------------------------|         24h denc
                          |------------------------|        24h denc
|------------------------|
client:
                                                 48h
|-------------------------------------------------|

I personally think that this illustrates the rationale behind my timings 
(on which I'm not insisting, just an idea I share with you and want to 
discuss). If the client receives a ticket/token just before the first 
rotation, it can revisit within 48h and the ticket/token is still valid 
if three keys are in use (and I wouldn't allow for more, otherwise 
there's a hole in the RFC that allows people to keep keys until their 
storage runs out). Of course there might be some edge cases where the 
ticket/token is still valid according to the lifetime but with this big 
window it shouldn't matter anymore.

Richard

---

From: Richard Fussenegger <[email-masked]>
Date: Thu, 23 Oct 2014 19:31:12 +0200

>                          |------------------------|        24h denc

The drawing got messed up, see here: http://pastebin.com/1iAatbWm

Richard

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Oct 2014 17:45:38 +0000

On Thu, Oct 23, 2014 at 07:21:08PM +0200, Richard Fussenegger wrote:

> To answer Rich Salz's initial question, if we'd have 24h encryption and 72h
> decryption on the server-side (as I proposed and nobody said anything pro or
> contra)

There is another variable at play here, in many implementations
there is a potentially independent upper bound on the lifetime of
resumed sessions, whether stateful or otherwise.

In Postfix (which is based on OpenSSL) I arrange for the session
lifetime limit to be double the key rotation interval.  Say that
is 1 hour, then the session lifetime is set to 2 hours.  Each key
is used to encrypt new traffic for an hour, then it becomes the
cached decryption key and a new encryption key is used.

There are only ever two keys sets in memory: the current encryption
key set and prior encryption (additional decryption) keyset.  I
say key set because we need an encryption key and an HMAC key and
both are rotated together, with these is associated a 16 octent id
(could be a counter or simply random).

> the MUST NOT for ticket/token lifetime would become 48h.
> 
> server-side key:
>          24h enc

The set of sessions encrypted under a single key is still 24 hours,
but the length of time for which the key is exposed on the server
is 48 hours.  And indeed a session is valid for anywhere between
24 and 48 hours depending on when in the encryption key's lifetime
it got created.

> If the client receives a ticket/token just before the first rotation, it can
> revisit within 48h and the ticket/token is still valid if three keys are in
> use.

Actually two key sets are sufficient.  There is no need for a third
key set.  Take a look at postfix/src/tls/tls_scache.c the relevant
functions are tls_scache_key() and tls_scache_key_rotate().

This is used in postfix/src/tls/tls_mgr.c tls_mgr_key().

    https://github.com/vdukhovni/postfix

-- 
	Viktor.

---

From: Richard Fussenegger <[email-masked]>
Date: Thu, 23 Oct 2014 20:17:33 +0200

> (could be a counter or simply random).

I like the wording 'key set' and it's actually what I was referring to 
too. The key sets that are generated in my script for nginx are simply 
48 B of random data (key_name, iv, key, mac):

https://github.com/Fleshgrinder/nginx-session-ticket-key-rotation/blob/master/config.sh#L420-L457
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key

>      https://github.com/vdukhovni/postfix

I adopted the three key idea from Twitter[1] and yes two key sets are 
sufficient. I thought that Twitters rational behind the three keys was 
to extend the lifetime of tickets on the client side (as in my drawing 
http://pastebin.com/1iAatbWm) without extending the lifetime of the 
encryption key. Of course I could be terribly wrong here but Jacob 
Hoffman-Andrews for sure had some idea behind this rational.

If the upper limit is said to be two tickets, Twitter has to adopt there 
system. Since we already have a prominent example that uses three 
tickets, its imho a good idea to let them continue doing so. Note that 
your approach would still be perfectly valid because you're below the 
hard limit of three tickets. Hence if one decides to use a single key 
and simply send it to nirvana after 24h then that's okay as well. The 
goal is that we don't botch PFS and not to dictate how keys are implemented.

That said, I have no problem with two keys especially if there is an 
argument against using three keys in regards to security. Maybe I should 
ask Jacob Hoffman-Andrews from Twitter why they are using three keys?

Richard

[1] https://blog.twitter.com/2013/forward-secrecy-at-twitter

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Oct 2014 13:21:31 -0500

> * For TLS 1.2 I mean. For 1.3 that might be different.

The ticket has to always be sent in the clear during resumption,
otherwise there's no point in having session resumption with tickets :)

The key material to super-protect a ticket would have to come from
somewhere: if not the ticket, then from a slower key exchange... that
session resumption means to avoid.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Oct 2014 18:36:37 +0000

On Thu, Oct 23, 2014 at 08:17:33PM +0200, Richard Fussenegger wrote:

> I like the wording 'key set' and it's actually what I was referring to too.
> The key sets that are generated in my script for nginx are simply 48 B of
> random data (key_name, iv, key, mac):

The iv should not be part of the persistent key set.  It is a new
random value for each client, returned to the server as part of
the ticket.  The key set is just (name, key, mac).  The in memory
version in Postfix also holds a timeout:

    typedef struct TLS_TICKET_KEY {
	unsigned char name[TLS_TICKET_NAMELEN];
	unsigned char bits[TLS_TICKET_KEYLEN];
	unsigned char hmac[TLS_TICKET_MACLEN];
	time_t  tout;
    } TLS_TICKET_KEY;

> sufficient. I thought that Twitters rationale behind the three keys was to
> extend the lifetime of tickets on the client side (as in my drawing
> Hoffman-Andrews for sure had some idea behind this rationale.

There is no particular advantage to three keys,  it just means that
the range of session lifetimes is between 2T and 3T, rather than
between T and 2T, if that's compelling (less variance) go for it.

> system. Since we already have a prominent example that uses three tickets,
> its imho a good idea to let them continue doing so. Note that your approach
> would still be perfectly valid because you're below the hard limit of three
> tickets.

I think you mean "key sets" not "tickets", and still I have no idea
what the above is talking about.  There is no "hard limit".  One
can use 24 keysets each good for encryption for 1 hour and decryption
for 23 after that.  It just means more data to shuffle in memory.
I used 2 key sets because it was simpler.

> argument against using three keys in regards to security. Maybe I should ask
> Jacob Hoffman-Andrews from Twitter why they are using three keys?

The number of key sets is irrelevant, all that matters is how long
each one is retained.  Postfix defaults to 2 hours (1 hour encrypt
and 1 hour decrypt).  With N keysets, you'd have (T encrypt, (N-1)*T
decrypt).

-- 
	Viktor.

---

From: Richard Fussenegger <[email-masked]>
Date: Thu, 23 Oct 2014 20:55:28 +0200

> 	unsigned char hmac[TLS_TICKET_MACLEN];

I didn't implement it but nginx requires 48 B otherwise it's not working 
and that's definitely more than only key and mac. Maybe the complete 
thing is broken in nginx then? [1]

> I used 2 key sets because it was simpler.

Absolutely, I meant 'key sets' not tickets. Well, I proposed that three 
key sets could become a hard limit and was referring to that proposition 
[2] because: [3]

> otherwise there's a hole in the RFC that allows people to keep keys 
> until their storage runs out

You may swap 'storage' with 'RAM' in that sentence, doesn't matter.

Richard

[1] 
https://github.com/nginx/nginx/blob/bb8c0683da773566e09797ef8a4ee00ad1e0f956/src/event/ngx_event_openssl.c#L2628-L2739
[2] http://www.ietf.org/mail-archive/web/tls/current/msg14168.html
[3] http://www.ietf.org/mail-archive/web/tls/current/msg14188.html

---

From: Stephen Checkoway <[email-masked]>
Date: Thu, 23 Oct 2014 15:35:59 -0400

> and 1 hour decrypt).  With N keysets, you'd have (T encrypt, (N-1)*T

This seems perfectly reasonable (both for general N and for specific N = 2 or N = 3). But does it make any difference from a protocol perspective? The only way a client could tell if a server is doing something wrong is if the client knows the upper limit on the ticket's validity  NT and sends a ticket after that time which the server accepts.

I'm probably missing something but it seems like there's no real way to detect if the server has followed any particular policy for a ticket so the details (such as key rotation and symmetric algorithm strength) should be left entirely up to the server. (Or resumption should be dropped from 1.3.)

Giving guidance seems reasonable. Setting unenforceable limits does not.

-- 
Stephen Checkoway

---

From: Richard Fussenegger <[email-masked]>
Date: Thu, 23 Oct 2014 21:53:35 +0200

> Giving guidance seems reasonable. Setting unenforceable limits does not.

Some parties think that only giving recommendations isn't enough 
(example quoted below), so why not give some rules then? Of course 
there's no way for a client to validate anything, but at least people 
can perform code reviews to check open or their own closed source 
projects to see if they are implemented correctly according to the RFC.

> The RFC doesn’t describe how key management should be performed and 
> merely emits recommendations. This has been found to be problematic in 
> OpenSSL’s case […]
> —Florent Daigniere: “TLS “Secrets””, p. 7, online: 

I know, I'm using that reference too much, still …

Richard

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Oct 2014 20:01:34 +0000

On Thu, Oct 23, 2014 at 03:35:59PM -0400, Stephen Checkoway wrote:

> This seems perfectly reasonable (both for general N and for
> specific N = 2 or N = 3). But does it make any difference from a
> protocol perspective? The only way a client could tell if a server
> is doing something wrong is if the client knows the upper limit on
> the ticket's validity  NT and sends a ticket after that time which
> the server accepts.

OpenSSL at least enforces the N*T time-limit on sessions, and in
case would not be able to decrypt a session ticket whose key has
been discarded.  So Postfix sets 2*T as the session lifetime, and
as a result if a session ticket is decrypted the session will not
be accepted.

> I'm probably missing something but it seems like there's no real way to
> detect if the server has followed any particular policy for a ticket so
> the details (such as key rotation and symmetric algorithm strength) should
> be left entirely up to the server. (Or resumption should be dropped from
> 1.3.)

Indeed the client has no way to know whether the server has erased
previous session ticket keys.

> Giving guidance seems reasonable. Setting unenforceable limits does not.

I have no opinion on whether any limit needs to be "enforceable".
Key rotation needs to happen, but the client has no way to verify,
that's just life.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Oct 2014 20:07:02 +0000

On Thu, Oct 23, 2014 at 08:55:28PM +0200, Richard Fussenegger wrote:

> I didn't implement it but nginx requires 48 B otherwise it's not working and
> that's definitely more than only key and mac. Maybe the complete thing is
> broken in nginx then? [1]

The reason nginx has 48 bytes is that it stores a 16 byte name,
followed by a 16-byte (AES-128) key and a 16-byte HMAC secret.

Postfix uses 16 + 32 + 32 = 80, because the key is for AES-256 and
the HMAC key for SHA2-256 is also chosen to be 256 bits.

The nginx implementation can be "strengthened" from AES-128 to
AES-256 just in case someone wants to burn a few million years of
a 4GW power plant to brute force a session ticket on a classical
computer, or future quantum computers can search a 2^128 key space
in 2^64 time.

-- 
	Viktor.

---

From: Richard Fussenegger <[email-masked]>
Date: Fri, 24 Oct 2014 00:38:52 +0200

> as a result if a session ticket is decrypted the session will not

With N = 2 your tickets are either T or 2 * T, depending on the time the 
client received the ticket. The client sends the ticket to the server 
expecting to continue were it left of but instead ends up with a full 
new handshake because the ticket is rejected, although the lifetime 
indicates that it's valid. (Of course no big deal.)

With N = 3 your ticket is always 2 * T, no matter when the client 
received the ticket. I tried to illustrate that in my simple drawing[1] 
and its the reasoning behind 3 key sets.

That's also were I see the difference for the protocol because all 
clients are treated equally in terms of ticket lifetime and can trust 
that they aren't storing garbage tickets (assuming it was configured 
correctly, but that could be handled by the library).

Richard

[1] http://pastebin.com/1iAatbWm

---

From: Richard Fussenegger <[email-masked]>
Date: Fri, 24 Oct 2014 00:52:19 +0200

> followed by a 16-byte (AES-128) key and a 16-byte HMAC secret.

Oh silly me, I could have found that myself: 
https://github.com/nginx/nginx/blob/master/src/event/ngx_event_openssl.h#L99-L107

> computer, or future quantum computers can search a 2^128 key space

But then nginx needs additional code, as you wrote earlier. It would be 
better (and that's also what the nginx devs want) if the library takes 
care of all that. Right now nginx has not a single line of code for 
session tickets (beside that function for external key sets). Well, we 
can only hope that you might take care of that and commit some OpenSSL 
code. ;-)

Richard

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Oct 2014 22:58:20 +0000

On Fri, Oct 24, 2014 at 12:38:52AM +0200, Richard Fussenegger wrote:

> expecting to continue were it left of but instead ends up with a full new
> handshake because the ticket is rejected, although the lifetime indicates
> that it's valid. (Of course no big deal.)

This is not true, I only promise the client a lifetime of T, so
the client asks for a new session after T anyway.  And the time
the ticket is good for is not discrete, it varies uniformly between
T and 2*T.

> With N = 3 your ticket is always 2 * T, no matter when the client received
> the ticket.

Not true, it varies uniformly between 2*T and 3*T.  The client
lifetime hint should be 2*T in this case.

-- 
	Viktor.

---

From: Richard Fussenegger <[email-masked]>
Date: Fri, 24 Oct 2014 01:00:28 +0200

> the ticket is good for is not discrete, it varies uniformly between

Ah, of course if you advertise T then everything is alright. I got you 
wrong there.

> lifetime hint should be 2*T in this case.

Yap, 2 * T for the lifetime in case of N = 3.

Richard

---

From: Hubert Kario <[email-masked]>
Date: Fri, 24 Oct 2014 12:50:33 +0200

> another does the trick (?):

yes, I agree.

> 1.3 (unless this has changed and I didn't read about it).

Yes, while a large key size is recommended ("SHOULD"), a frequent key rotation 
(in order of days) is a "MUST" with shorter time scales recommended, given 
other parts of TLS 1.3.

-- 
Regards,
Hubert Kario

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 24 Oct 2014 09:58:54 -0700

> (in order of days) is a "MUST" with shorter time scales recommended, given
[Joe] Personally, I don't think that PFS is a MUST for session resumption.
  I think an implementation can attempt to provide PFS like behavior, but
if one is really interested in PFS I think the full handshake is the way to
go.

I'm a bit concerned that we're going down the path of trying to mandate a
particular implementation.  I think we have the following areas under
discussion:

1.  Hard RFC 2119 requirements for things that are verifiable.  For
example, perhaps you would want to make sure that the client could request
the server issue a new ticket (the client can actually verify that the
ticket is different).

2.  Strong guidelines for the ticket and key management.  RFC 5077 has some
of these, they can be improved upon.  These would not necessarily be RFC
2119 language.

3.  Implementation guidance for ticket and key management.  Again RFC 5077
has some of this, but it can be improved upon.

I think we should be focusing first on 1 because it is normative and
affects interop.  2 is also important, but it should not force a particular
implementation.   3 is useful, but I do not think it should be normative
and I think it may be difficult to come to consensus on what the guidance
should be.  A discussion on 3 may help us with 1 and 2, but I think its a
secondary part of the discussion.

I want to make sure we have a clear understanding of 1 and 2.

--

---

From: Hubert Kario <[email-masked]>
Date: Fri, 24 Oct 2014 19:17:56 +0200

> the server issue a new ticket (the client can actually verify that the

We already have ticket lifetime hints and basically nobody sets them higher 
than 48h (>99%), vast majority limit to 24h(>96%)[1]. That's including servers 
that don't use tickets at all! Of servers that do enable tickets, over 70% 
leave them at a 300s default. Nearly half of servers don't enable them at all.

That clearly means that server administrators don't consider renegotiation of 
clients that connect less often than once a day to be a burden on servers...

> of these, they can be improved upon.  These would not necessarily be RFC

...so if the actual use agrees with theory, nearly no one will be negatively 
impacted if all the frameworks actually started to enforce those limits (not 
that I think this should, let alone will happen). As such, I don't see why we 
shouldn't use the RFC 2119 language.
 
> secondary part of the discussion.

As it was pointed out, proper key management of server is non-verifiable by 
client, it may only be verified by auditing. Definite language there does 
help.

 1 - https://securitypitfalls.wordpress.com/2014/09/29/scan-results-for-september-2014/

-- 
Regards,
Hubert Kario

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 24 Oct 2014 13:27:41 -0400

> if one is really interested in PFS I think the full handshake is the way to

If we decide to merge session resumption with PSK as discussed at the
interim meeting, then deciding that session resumption doesn't get
forward secrecy means that forward secrecy wouldn't be an option with
PSK.

Today, we have several forward-secret PSK ciphersuites:

0 dkg@alice:~$ gnutls-cli --list --priority NORMAL:-KX-ALL:+DHE-PSK:+ECDHE-PSK:-SIGN-ALL
Cipher suites for NORMAL:-KX-ALL:+DHE-PSK:+ECDHE-PSK:-SIGN-ALL
TLS_DHE_PSK_AES_128_GCM_SHA256                    	0x00, 0xaa	TLS1.2
TLS_DHE_PSK_AES_256_GCM_SHA384                    	0x00, 0xab	TLS1.2
TLS_DHE_PSK_CAMELLIA_128_GCM_SHA256               	0xc0, 0x90	TLS1.2
TLS_DHE_PSK_CAMELLIA_256_GCM_SHA384               	0xc0, 0x91	TLS1.2
TLS_DHE_PSK_AES_128_CBC_SHA1                      	0x00, 0x90	SSL3.0
TLS_DHE_PSK_AES_128_CBC_SHA256                    	0x00, 0xb2	TLS1.0
TLS_DHE_PSK_AES_256_CBC_SHA1                      	0x00, 0x91	SSL3.0
TLS_DHE_PSK_AES_256_CBC_SHA384                    	0x00, 0xb3	TLS1.0
TLS_DHE_PSK_CAMELLIA_128_CBC_SHA256               	0xc0, 0x96	TLS1.0
TLS_DHE_PSK_CAMELLIA_256_CBC_SHA384               	0xc0, 0x97	TLS1.0
TLS_DHE_PSK_3DES_EDE_CBC_SHA1                     	0x00, 0x8f	SSL3.0
TLS_DHE_PSK_ARCFOUR_128_SHA1                      	0x00, 0x8e	SSL3.0
TLS_ECDHE_PSK_AES_128_CBC_SHA1                    	0xc0, 0x35	SSL3.0
TLS_ECDHE_PSK_AES_128_CBC_SHA256                  	0xc0, 0x37	TLS1.0
TLS_ECDHE_PSK_AES_256_CBC_SHA1                    	0xc0, 0x36	SSL3.0
TLS_ECDHE_PSK_AES_256_CBC_SHA384                  	0xc0, 0x38	TLS1.0
TLS_ECDHE_PSK_CAMELLIA_128_CBC_SHA256             	0xc0, 0x9a	TLS1.0
TLS_ECDHE_PSK_CAMELLIA_256_CBC_SHA384             	0xc0, 0x9b	TLS1.0
TLS_ECDHE_PSK_3DES_EDE_CBC_SHA1                   	0xc0, 0x34	SSL3.0
TLS_ECDHE_PSK_ARCFOUR_128_SHA1                    	0xc0, 0x33	SSL3.0

Certificate types: CTYPE-X.509
Protocols: VERS-TLS1.2, VERS-TLS1.1, VERS-TLS1.0, VERS-SSL3.0, VERS-DTLS1.2, VERS-DTLS1.0
Compression: COMP-NULL
Elliptic curves: CURVE-SECP192R1, CURVE-SECP224R1, CURVE-SECP256R1, CURVE-SECP384R1, CURVE-SECP521R1
PK-signatures: none
0 dkg@alice:~$ 

It would be a shame to lose the ability to combine forward secrecy with
PSK.

        --dkg

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Oct 2014 13:42:56 -0500

> forward secrecy means that forward secrecy wouldn't be an option with

Why would that follow?  Joe says that PFS should not be REQUIRED for
resumption.  That doesn't mean it shouldn't be possible at all.

It's true that without merging PSK and resumption there would be no
need to support PFS in resumption handshakes: the whole point of
resumption is to reduce the number of PK key exchanges.  But it's not
obvious that a merger can't provide PFS as an option [that typically
just wouldn't be used in the resumption case].

Nico
--

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 24 Oct 2014 14:51:50 -0400

> resumption.  That doesn't mean it shouldn't be possible at all.

Sure, understood.  I just want to make sure that we retain the
possibility to do both PSK and session resumption with forward secrecy
if the peers want it, and not drop that combination on the floor.

	--dkg

---

From: David Leon Gil <[email-masked]>
Date: Sun, 26 Oct 2014 19:01:20 -0400

On Wed, Oct 22, 2014 at 11:16 AM, Viktor Dukhovni
<[email-masked]> wrote:
> the encryption.

Yep.

> (I've updated the Postfix default ticket cipher

This is really excellent to hear. :)

--

The rest is, strictly speaking, irrelevant to session tickets. Unless,
that is, you believe that 128 bits is a reasonable level of protection
for TLS master secrets.

> With somewhat less than 2^25 seconds per year, we're looking at ~2^23

Right now, a gigawatt buys you roughly 2^77 linpackflops / year (see
Green500). (I get roughly the same number of symmetric crypto block
ops / year for that hardware -- mostly from the GK110s.)

And by 2020, the top 500 supercomputers will be doing about 2^88
linpackflops / year. See http://www.top500.org/statistics/perfdevel/

(Note that it's undesirable to search the full 2^128 keyspace in any
event; efficiency goes down once you've gotten most of the keys.)

> The use of random IVs or similar "whitening" makes pre-computation substantially less effective.

There's no precomputation. (Storage costs during the attack are <1
block for CTR/GCM, 1 block for ECB, and < 2 blocks for CBC and CFB.)

Ryan: There's very little point in performing this attack with a
quantum computer for TLS; solving dlog is much easier. (Also, the
D-wave thing is not a quantum computer.)