Subject: [TLS] Proposed text for removing renegotiation

From: Martin Thomson <[email-masked]>
Date: Tue, 27 May 2014 14:39:29 -0700

I was incapable of doing much real work on a plane last week, so I did this:

https://github.com/tlswg/tls13-spec/pull/41

Here I'm proposing changes that remove renegotiation.  There are some
pieces that are probably separable, and other pieces that might be
controversial, so I'll try to highlight those and then we can discuss
the merits of various approaches.  You know, the regular process.

It's not possible to just remove renegotiation.  After removing
HelloRequest and no_renegotiation, there are some things that need to
be fixed.  The current and pending states for both read and write
direction are integral parts of the spec.

I've proposed a simple mechanism for key refresh.  Basically, either
side sends a ChangeCipherSpec, which triggers the creation of a new
master secret for that direction.  Since CCS was otherwise unused
after removing renegotiation, it can be used to explicitly
indicate/request key refresh.

The proposal mandates a reciprocal CCS to keep the master secret
approximately in sync.  That is, if you receive a CCS, and you haven't
already sent a matching CCS, then you are required to send one.  This
means that an old master secret can be discarded in a bounded amount
of time.

The proposal generates a new master secret from the previous using the
same formula that is used to generate the master from the pre-master
secret.  Obviously, if we change that formula (and it seems likely
that we will) then this should be changed too.

This overloads ChangeCipherSpec, which some might find distasteful,
but I think that it is consistent with it's current use and purpose.

Does this sound like a reasonable approach?

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 May 2014 18:18:14 -0400

> This overloads ChangeCipherSpec, which some might find distasteful, but I think that it is consistent with it's current use and purpose.

Yeah, I'm not thrilled but it, although I admit it is consistent.

I would rather see something like Yoav (?) proposed via Jabber at the interim meeting:  a "reset but don't close" message.  Either side sends it, the other side replies, and at this point all state is thrown away and it's just as if the client first connected.  It avoids TCP reconnect, perhaps requires more work (but the EDH key should be cached), but it seems much clearner.

	/r$

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 May 2014 15:31:05 -0700

> I would rather see something like Yoav (?) proposed via Jabber at the interim meeting:  a "reset but don't close" message.  Either side sends it, the other side replies, and at this point all state…

If I understand you correctly, and I'm not sure, are you proposing
that we close the TLS connection, but not the TCP connection.  Is the
assumption that we have a 0RTT handshake that is piggybacked
immediately after a close alert so that application data can continue
to flow?

It's certainly clean, in the sense that you get a completely new
security context without some of the overhead.

But it seems a little heavyweight to me.  I'm also concerned about the
performance implications.  A 1RTT handshake would end up with dead air
on the client side if they initiate this, and even with 0RTT, the
server is always penalized if they initiate.  That is, unless we allow
for role inversion, which would make my head hurt.

---

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

> I would rather see something like Yoav (?) proposed via Jabber at the interim meeting:  a "reset but don't close" message.  Either side sends it, the other side replies, and at this point all state…

I suspect that, without a lot of API care, this will reintroduce the
original renegotiation attack: client sends a prefix, says "reset but
don't close", and starts forwarding ciphertext from a different client.

--Andy

---

From: [email-masked] (Martin Rex)
Date: Wed, 28 May 2014 02:44:08 +0200 (CEST)

Martin Thomson wrote:
> 
> Here I'm proposing changes that remove renegotiation.
>
> It's not possible to just remove renegotiation.
> After removing HelloRequest and no_renegotiation, there are some
> things that need to be fixed.  The current and pending states for
> both read and write direction are integral parts of the spec.

I haven't looked at the details, but this sound terrible.

The beauty of the original TLS renegotiation is that it doesn't
really exist.  For the state machine, it is a regular full TLS
handshake, for the record layer, it is just a replacement of
the current state with the next state upon CCS.

The only problem with TLS renogitation, if there ever was one,
is with the flawed assumptions of the application about what
characteristics it provides (i.e that another successful TLS
handshake could be abused to provide an OTP-style authentication
of all data previously received over that TLS channel.

Renegotiation could be combined with an abbreviated TLS handshake
to provide fast rekeying of the traffic protection keys (not creating
a new entry in the TLS session cache), and renegotiation could be
combined with a full TLS handshake, creating a new, self-contained
entry in the TLS session cache that can be resumed on different
connections with an abbreviated TLS handshake.

Conceptually, the TLS session cache is readonly after an entry
is created, and that is GOOD, i.e. full TLS handshakes create new,
distict session cache entries, and abbreviated TLS handshakes resume
existing session cache entries and *NEVER* modify them.

The original architecture allows for a very simple and robust
TLS protocol state machine for the TLS handshake (allows!=implies,
you can implement arbitrarily complicated TLS state machines if you
so desire, just look at some of the OpenSource implementations).

> that we will) then this should be changed too.

It sounds like quite a lot more stuff will have to be carried over
from the previous session state to the next.  Now what does this mean
for the abbreviated TLS handshake?  When, where and how do you issue
a new session ID, or how does this change affect abbreviated
TLS handshakes happening on independent parallel connections? 

-Martin

---

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

> of all data previously received over that TLS channel.

The security considerations never mentioned the issue.  In fact you were
one of the codiscoverers, years after the spec was authored. Do you
consider it a nonissue?

One can argue that TLS never has flaws, just assumptions that it is
"secure" which aren't true. Or one could say that we have to provide
semantics people expect.

> TLS handshakes happening on independent parallel connections?

Does resuming the same connection twice make sense? Now that you mention
the issue I see how it can happen. But we only need to refresh the keys
used for data, not the PMS.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 28 May 2014 00:00:00 -0400

Yes, you understand it.  Yes, the trade-offs are like you describe. I happen to think it's cleaner and less likely to have security issues, but we certainly need more discussions.

---

From: Brian Smith <[email-masked]>
Date: Tue, 27 May 2014 22:47:48 -0700

> It's not possible to just remove renegotiation.

Why not? What is the motivation for keeping any form of renegotiation, even
rekeying? It isn't clear from the public mailing list discussions what is
motivating the rekeying feature. (Perhaps I overlooked something; if so, a
link to the past decision on this would be appreciated.)

> After removing

I don't think documenting/managing those states would be integral at all if
we didn't need to support rekeying.

Cheers,
Brian

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 28 May 2014 09:02:03 +0200

> the merits of various approaches.  You know, the regular process.

What problem does this removal solves? There is no motivation written in
your text.

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Wed, 28 May 2014 13:00:00 +0300

On May 28, 2014, at 8:47 AM, Brian Smith <[email-masked]> wrote:

> 
> On Tue, May 27, 2014 at 2:39 PM, Martin Thomson <[email-masked]> wrote:
> Why not? What is the motivation for keeping any form of renegotiation, even rekeying? It isn't clear from the public mailing list discussions what is motivating the rekeying feature. (Perhaps I overlooked something; if so, a link to the past decision on this would be appreciated.)
>  

Why not?  Because people are using it to accomplish things, and you can’t just pull it away without giving them some other way of doing what they’re doing, otherwise you get “TLS 1.3 is not suitable for long-lived connections” or “TLS 1.3 is not suitable for mutual authentication”.

With that in mind, in discussions on this list and at the interim meeting two uses for renegotiation were mentioned:

1. Client Authentication. For various UI reasons, web applications don’t want to send a certificate request on the landing page. They want the certificate authentication in response to a request for a protected resource, one that requires an authenticated client. This is not something that Google, Facebook or Tumblr use, but it’s much more common in SSL VPNs, corporate portals, and some banking web sites.  Martin has a couple of drafts for making this happen in a combination of HTTP authentication method (“go away and come back with a certificate”) and a TLS extension (“I have a certificate. Please send a CertReq”).

2. Connections that carry so much traffic and last so very long that you really need to rekey. This was discussed at the meeting, partially on Jabber ([1]). It’s not that common for the web, but I’m assured that XMPP connections sometimes last basically forever, so they need rekeying. My proposal there (at 19:40) was for this use case. Martin is right that it adds “dead air”, but all these use cases are not that delay sensitive, and I think it’s worth it to get the simplified state machine.

Yoav

[1] http://www.ietf.org/jabber/logs/tls/2014-05-16.html around 19:24

---

From: Yoav Nir <[email-masked]>
Date: Wed, 28 May 2014 13:05:35 +0300

> don't close", and starts forwarding ciphertext from a different client.

Definitely, so we’d need a same or similar indication to prevent abuse. I tend to think that a binary indication of “initial contact” would be enough (as normal clients will always be “initial contact” and a ClientHello with “initial contact” should never appear after StopTLS), but I could be wrong.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 May 2014 09:38:47 -0700

> link to the past decision on this would be appreciated.)

That statement was merely referring to the fact that there are other
considerations that removing renegotiation exposes:

AES-GCM (for example) can't be used with the same key indefinitely.
2^32 records is the limit apparently.  We have reports of services
that use the same connection for up to months with high volumes of
traffic.  Over that period, the sequence number might roll over, even
if the keys are still good.  Rekeying allows for those uses.

It also provides a measure of forward security in that old keys can be
thrown away.  A break of a server only allows the attacker to gain the
plaintext of a connection back to the last rekeying event.

Then there's the use of renego for HTTP, but we've discussed that
already and the tentative plan is to push on HTTPbis to come up with a
solution that doesn't depend on TLS.  Failing that, or in the event
that we discover other users of spontaneous client authentication, we
will build something into TLS.  That will probably be something
lightweight that doesn't cause the sorts of issues Martin (R) doesn't
think are worth worrying about.

>> The current and pending states for both read and write
>I don't think documenting/managing those states would be integral at all if we didn't need to support rekeying.

That's right.  That's a presentation consideration, as alluded to
above.  As much as possible, I tried to make them non-integral in my
proposed text.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 May 2014 09:46:49 -0700

On 28 May 2014 03:00, Yoav Nir <[email-masked]> wrote:
> 2. Connections that carry so much traffic and last so very long that you
> really need to rekey. This was discussed at the meeting, partially on Jabber
> ([1]). It’s not that common for the web, but I’m assured that XMPP
> connections sometimes last basically forever, so they need rekeying. My
> proposal there (at 19:40) was for this use case. Martin is right that it
> adds “dead air”, but all these use cases are not that delay sensitive, and I
> think it’s worth it to get the simplified state machine.

I think that we might be able to mitigate the dead air problem.  At
least if the client initiates the action.

My concerns with this approach are with the obvious tension between
the obvious goal and the goals of the application/API.

The establishment of an entirely new context is only truly useful if
it is treated as such.  But the goal of applications in this context
is to continue to operate seamlessly.  Many of the concerns arising
from renegotiation arise from the way that applications are almost
willfully ignorant of the transition in states.

As Martin (R) observes, renegotiation is fairly precisely defined.  If
you strictly respect it, it can be safe...in theory.  It's just that
it's rarely afforded that respect.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 May 2014 10:02:00 -0700

> existing session cache entries and *NEVER* modify them.

That's a good point.  Something that I missed.  A resumption handshake
would have to include an epoch from the previous session.  That number
would need to be incremented with each update of the master secret.

Alternatively, and I think preferably, we could allow (or require)
servers to send the NewSessionTicket message when they update the
master secret, so that there isn't a master secret lying around
anywhere.

Of course, if you want to argue for unmodifiable state, then maybe you
can provide stronger justification than that.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 May 2014 10:23:49 -0700

> would need to be incremented with each update of the master secret.

That's one option. The other option is just to flush your session cache. To
the best of my knowledge, systems generally either have a lot of connection
setups (which makes session caching attractive) or long-lived connections
(where you would want to change keys) but usually not both.

-Ekr

---

From: Brian Smith <[email-masked]>
Date: Wed, 28 May 2014 10:26:05 -0700

> existing session cache entries and *NEVER* modify them.

That is not true. During session resumption, the server can send a new
session ticket for the existing session and the client has the option of
adding the new ticket to the session (and removing the old ticket).

Also often timestamps (e.g. for LRU replacement bookkeeping) and/or
counters (e.g. for cache hit rate statistics) in a session are updated
during resumption, though these are "just" implementation issues.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Wed, 28 May 2014 10:35:24 -0700

On Wed, May 28, 2014 at 3:00 AM, Yoav Nir <[email-masked]> wrote:

> Why not? What is the motivation for keeping any form of renegotiation,
> even rekeying? It isn't clear from the public mailing list discussions what
> is motivating the rekeying feature. (Perhaps I overlooked something; if so,
> a link to the past decision on this would be appreciated.)
>
> 1. Client Authentication.
>

<snip>

> Martin has a couple of drafts for making this happen in a combination of
> HTTP authentication method (“go away and come back with a certificate”) and
> a TLS extension (“I have a certificate. Please send a CertReq”).
>

FWIW, I think the idea that Martin is pursuing is the right approach to
this issue.

> really need to rekey. This was discussed at the meeting, partially on
> Jabber ([1]). It’s not that common for the web, but I’m assured that XMPP
> adds “dead air”, but all these use cases are not that delay sensitive, and
> I think it’s worth it to get the simplified state machine.
>

As you say, these applications are not delay sensitive. Also, these
applications have to be able to recover from long-lived connections being
broken. So, for these applications, why isn't it acceptable to just close
the connection/session and open a new one?

I think it would be helpful to see some examples of real-world applications
(preferably, but not exclusively open source) that actually do currently
use renegotiation to rekey a long-lived connection.

Assuming rekeying would be an optional feature like renegotiation is, would
web browsers and/or common web servers actually implement rekeying? It
would be very tempting to leave it out to reduce the chance of
implementation mistakes if it were optional.

Cheers,
Brian

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 May 2014 10:42:49 -0700

On 28 May 2014 10:35, Brian Smith <[email-masked]> wrote:
> As you say, these applications are not delay sensitive.

The specific example we've been given was XMPP.  That is somewhat
delay sensitive.  These high volume channels can't really afford to
waste round trips.  Now, a make-before-break arrangement might be
enough.  I can ask an expert.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 28 May 2014 13:46:27 -0400

On 05/28/2014 01:23 PM, Eric Rescorla wrote:
> On Wed, May 28, 2014 at 10:02 AM, Martin Thomson <[email-masked]>wrote:
> 
> That's one option. The other option is just to flush your session cache.

I'm not sure i understand this argument properly, but:

> To

Doesn't the classic XMPP server case have both?  there are a lot of c2s
connection setups which could benefit from session caching, and several
long-lived connections for the s2s connections which could benefit from
being able to re-key.

	--dkg

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 May 2014 10:50:14 -0700

> long-lived connections for the s2s connections which could benefit from

It sounded OK to me.  If you live long enough to require a rekey, then
throw away your session ticket.

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 28 May 2014 12:55:09 -0700

> would need to be incremented with each update of the master secret.

Rather than mucking with the master secret, can't we rearrange the key
hierarchy a bit:

Separately derive master_secret and temporary_secret from
premaster_secret.  Use master_secret as it's currently used for
resumption, but use temporary_secret for encryption and MAC.  When it's
time to rekey, roll over the temporary_secret but leave the
master_secret alone.

Getting resumption right might be a little tricky here: unless a new DH
exchange happens on resumption, the new temporary_secret will have to be
derived from master_secret.

This gets another benefit for free: a compromise of the session cache or
the ticket key doesn't compromise old non-resumed connections.

--Andy

---

From: Brian Smith <[email-masked]>
Date: Wed, 28 May 2014 12:59:32 -0700

On Wed, May 28, 2014 at 9:38 AM, Martin Thomson <[email-masked]>wrote:

> even

Understood. However, as I implied in my other responses today, I don't
think TLS is the place to support that use case. It is enough for the TLS
implementation to be only responsible for ensuring that we don't use a key
beyond safe limits for its usage. How the application recovers from that
limit being reached can be delegated to the application. The advantage with
this is that only the applications that need to deal with this problem are
impacted by it.

> plaintext of a connection back to the last rekeying event.

I understand the idea is that both sides could throw away the old master
secret right away and then nobody would be able to decrypt the traffic
protected by that old master secret. However, the "master secret
advancement" mechanism you proposed is calculated using only the old master
secret plus public nonces, which raises some risk of related-key attacks.
As Martin Rex was saying, the advantage of TLS-1.2-style renegotiation is
that the new master secret is clearly (could be made to be) completely
unrelated to the the previous master secret so that related key attacks
aren't (could be made to not be) an issue.

Thus, while a simpler rekeying mechanism definitely makes the protocol
simpler, we'd be trading a useful cryptographic property for that
simplicity. And, most implementations that would support it would actually
become more complicated by having to support both TLS < 1.3 renegotiation
AND TLS 1.3 rekeying.

Consequently, I still think we should keep trying to get rid of
renegotiation without adding anything new in TLS to replace it.

Cheers,
Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 28 May 2014 16:05:44 -0400

Ø  The advantage with this is that only the applications that need to deal with this problem are impacted by it.

Strongly disagree.  This requires applications to know way to much about the TLS layer:  what cipher is being used, how SSL is packing things into records, and how often a cipher needs to be “reset” and what that entails.

--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]<mailto:[email-masked]>; Twitter: RichSalz

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 May 2014 13:12:27 -0700

> time to rekey, roll over the temporary_secret but leave the

The problem with that is that you end up with the keys to the kingdom
just lying around.  And they only seem to exist in order to enable
resumption.  One property I was looking to gain here was the ability
to have a state that cannot be used to derive past states.  Having the
master_secret sitting around loses that.

> derived from master_secret.

The whole point is to avoid the DH.  The current resumption process
mixes new randoms with the old master_secret.  The old master_secret
is then discarded.  That would seem to have the property you are
looking at.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 28 May 2014 20:12:19 +0000

> Strongly disagree.  This requires applications to know way to much about the
> TLS layer:  what cipher is being used, how SSL is packing things into records,
> and how often a cipher needs to be “reset” and what that entails.

Concur. Rekeying of an otherwise healthy connection must be the TLS job, and
must be done automatically.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 28 May 2014 16:15:30 -0400

> The whole point is to avoid the DH.  

I'm not sure that should be a major design point.  For the one use-case we know, do we know if those long lived xmpp connections are to small clients (such as android phones) or server to server?

	/r$

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 May 2014 13:15:12 -0700

> derived from master_secret.

This seems like it would seriously decrease the value of resumption.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 May 2014 13:17:24 -0700

> I'm not sure that should be a major design point.  For the one use-case we know, do we know if those long lived xmpp connections are to small clients (such as android phones) or server to server?

People who like resumption keep saying that this is the primary
advantage.  Maybe they like the latency advantage, but most of that
would be obviated by faster handshakes, or false start.

---

From: Brian Smith <[email-masked]>
Date: Wed, 28 May 2014 13:47:40 -0700

On Wed, May 28, 2014 at 1:05 PM, Salz, Rich <[email-masked]> wrote:

> Ø  The advantage with this is that only the applications that need to
> deal with this problem are impacted by it.
>
> Strongly disagree.  This requires applications to know way to much about
> the TLS layer:  what cipher is being used, how SSL is packing things into
> records, and how often a cipher needs to be “reset” and what that entails.
>

The application would only have to be aware that the connection may at some
point become unusable because the TLS implementation did something like
simulating a RST when some crypto limit is reached. Applications that are
exchanging more than 2^32 records per connection already have to cope
somehow with these long-lived connections being reset below the TLS layer.

And/or such applications could choose to use cipher suites that aren't
limited to 2^32 records. I have just re-read SP-800-38D section 8.3 which
sets the limit on the number of invocations of AES-GCM with a given key.
SP-800-38D doesn't actually limit AES-GCM to 2^32 invocations as long as
the deterministic construction is used and as long as the invocation field
is larger than 32 bits, if I am reading it correctly. The birthday attack
issue on the 64-bit invocation field used in AES-GCM cipher suites could be
mitigated by tightening the requirements for AES-GCM in TLS 1.3 and/or by
defining new AES-GCM cipher suites that are required to have IVs generated
using the deterministic construction with large(r) invocation fields.

And/or, implementations that send/receive large amounts of data on a single
connection could tune their TLS stacks so that they will never (or almost
never) get close to whatever limit the cipher suite has.

And/or the TLS implementation could optionally provide some kind of simple
notification mechanism to tell the application that the connection will
become unusable "soon," so that an application could start a new
connection/session before the old one stops working, to minimize the
performance impact.

Cheers,
Brian

[1] http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf(section
8.3)

---

From: Geoffrey Keating <[email-masked]>
Date: 28 May 2014 15:25:02 -0700

> if the keys are still good.  Rekeying allows for those uses.

I think this should be handled by TLS, not by having the application
request rekeying or renegotiation.  If TLS handles it, I don't see why
there's a need for a special 'renegotiate' or 'change key' message; it
can quietly change the key when the appropriate limit is hit.

For sequence numbers, rollover also should (indeed must) be handled by
DTLS.  There are many possibilities, but the easiest is that if we're
removing renegotiation, so the cipher state can change at most once,
so in DTLS we can remove the epoch counter and make the sequence
number 64-bit, and say that if the 64-bit counter is exceeded (will
probably never happen) it is an error and the connection should close.

> plaintext of a connection back to the last rekeying event.

This definitely seems like a case where you want to close the
connection and open a new one, directed by the application.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 May 2014 15:45:18 -0700

> can quietly change the key when the appropriate limit is hit.

I wasn't proposing that the application be in control of when rekeying
occurs.  (Yes, if an app needs an explicit break in continuity, then
opening a new connection is a perfectly reasonable way to achieve that
goal.)

Yes, you could just roll on through, identify a point where rekeying
is necessary and automatically do it.  That's even more aggressively
spartan than what I've proposed.

A message enables more than just necessary rekeying.  It also allows
for read and write states to be kept in sync.

It also means that you don't have to go to great lengths to contrive a
rekeying scenario in your testing.  I certainly don't want rekeying to
be rare enough that it breaks the first time that it ever actually
happens.  That's a surefire plan for backup generator syndrome.

---

From: Hubert Kario <[email-masked]>
Date: Thu, 29 May 2014 08:25:14 -0400 (EDT)

----- Original Message -----
> From: "Martin Thomson" <[email-masked]>
> To: "Geoffrey Keating" <[email-masked]>
> Cc: [email-masked]
> Sent: Thursday, May 29, 2014 12:45:18 AM
> Subject: Re: [TLS] Proposed text for removing renegotiation
> 

Transferring 64GB of data with TLS over loopback on a relatively modern
machine (even without AES-NI) takes less than an hour. I wouldn't
call it going to great lengths to test.

-- 
Regards,
Hubert Kario

---

From: Brian Sniffen <[email-masked]>
Date: Thu, 29 May 2014 10:46:14 -0400

> Yes, you understand it.  Yes, the trade-offs are like you describe. I happen to think it's cleaner and less likely to have security issues, but we certainly need more discussions. 

One extra trade-off: apps that abstract over sockets and an assumption
they're "secure" will tend to assume a binding between these two TLS
sessions that isn't justified.  If it only happened on very long
sessions, maybe it wouldn't matter in practice---but I expect the case of a
hot-pluggable authenticator to matter.

Airman Smith plugs in his CAC and authenticates to a web server using
the embedded PKCS#11 authenticator.  An hour later, he pulls the CAC and
walks over to the coffeepot.  His browser sees the CAC missing and
issues a CCS.  Five minutes later, Airman Jones inserts her CAC, causing
another CCS.  The browser state is unchanged---cookies persist.

I'd like to avoid encouraging the origin app to mistake this for one
session.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies

---

From: Martin Thomson <[email-masked]>
Date: Thu, 29 May 2014 09:27:26 -0700

> call it going to great lengths to test.

Seriously?  You think that's an acceptable time to wait for a single
test case to run?  With a message, the test will take milliseconds (as
all tests should).

---

From: Hubert Kario <[email-masked]>
Date: Thu, 29 May 2014 12:59:53 -0400 (EDT)

----- Original Message -----
> To: "Hubert Kario" <[email-masked]>
> Cc: "Geoffrey Keating" <[email-masked]>, [email-masked]
> Sent: Thursday, May 29, 2014 6:27:26 PM

There are test cases and there are test cases.

For a unit test, an hour is definitely far too long, and as you rightfully
point out, a typical unit test should take just few milliseconds.

For an integration test case, an hour is long, but not prohibitive.

For a system test, an hour is basically expected.

-- 
Regards,
Hubert Kario

---

From: James Cloos <[email-masked]>
Date: Thu, 29 May 2014 17:28:02 -0400

>>>>> "HK" == Hubert Kario <[email-masked]> writes:

>>> call it going to great lengths to test.

Did you mean something other that GB there?

150Mbit/s is a bit slow for loopback. ☺

64GB (31 bits of 256-bit blocks) over loopback should take 3-5 seconds.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Hubert Kario <[email-masked]>
Date: Fri, 30 May 2014 05:36:03 -0400 (EDT)

----- Original Message -----
> From: "James Cloos" <[email-masked]>
> Cc: "Martin Thomson" <[email-masked]>, "Geoffrey Keating" <[email-masked]>, [email-masked]
> Sent: Thursday, May 29, 2014 11:28:02 PM

It's not slow for AES though.

That was the example of slowest performance for this, in a full functional test -
where the application is in production configuration. That is, it does everything
from certificate verification to AES-GCM crypto, all in software on a few year
old hardware with encryption and decryption running in parallel.

With AES-GCM done in hardware (e.g. AES-NI) on a multi core CPU, the test shouldn't
take more than 10-15 minutes.
-- 
Regards,
Hubert Kario

---

From: James Cloos <[email-masked]>
Date: Fri, 30 May 2014 13:45:26 -0400

>>>>> "HK" == Hubert Kario <[email-masked]> writes:

HK> That was the example of slowest performance for this, ...  all in
HK> software on a few year old hardware with encryption and decryption
HK> running in parallel.

I see.  The post gave the impression that it were intended as an example
on more recent hardware.  Although even a K10 is closer to 150 MB/s than
150 Mbit/s.

-JimC