Subject: [TLS] Question on Stateless TLS Session Resumption

From: "Narayanan, Vidya" <[email-masked]>
Date: Sat, 13 Jan 2007 11:54:54 -0800

All,
RFC4507 makes no mention of ticket replays at all, which I find to be a
bit surprising. It actually doesn't talk about message replays either,
but, since the protocol takes 1.5 RTs,  both parties prove to be live
and so, that is not a problem. But, ticket replays seem to be of some
concern. Based on the fact that the ticket contains a timestamp, using
which expiry can be determined, it appears that a given ticket will be
accepted until its expiry time, even if a newer ticket may have been
issued after that. This itself is not so much a problem, since, the
client really has no incentive in using an older ticket as opposed to
the latest one. However, if a new ticket is either not issued or if the
session is terminated by the server for some reason, this seems to be a
problem. Since there is really no means of ticket revocation or any
server state on the status of a ticket, there seems to be no way to
determine that the client is not supposed to be using that ticket to
resume a session. Also, the fact that the client is allowed to pick a
Session ID makes it infeasible to track a terminated session that must
not be allowed to resume. 

Am I missing something? Has this been talked about before? 

Vidya

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 13 Jan 2007 13:53:18 -0800

[Re-sending to the mailing list...]

"Narayanan, Vidya" <[email-masked]> writes:

> issued after that.

Right. There's nothing wrong with this.

> This itself is not so much a problem, since, the
> problem.

Well, there are two separate issues here. There's no technical
reason why a new TLS handshake between a client/server pair
needs to invalidate and old session between them. Indeed,
I don't know of any server which enforces this before and it
would even in principle be rather difficult to do in the
absence of client authentication, which is fairly rare.

This leaves us with ticket invalidation which does, as you
note, require server side state, though rather less than
that required by an ordinary session cache. 

> Since there is really no means of ticket revocation or any

I don't think I understand this point. Both session IDs and 
tickets are generated by servers.

> Am I missing something? Has this been talked about before? 

Yes, it's discussed extensively in the SBR04 paper on Client-Side
Session Caching.

Shacham, H., Boneh, D., and E. Rescorla, "Client-side
caching for TLS", Transactions on Information and System
Security (TISSEC) , Volume 7, Issue 4, November 2004.

-Ekr

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 13 Jan 2007 16:04:48 -0800

> absence of client authentication, which is fairly rare.

The issue is that of revocation.  If a client's credentials are revoked, 
a full exchange will ensure that the client gets service only after it 
acquires/renews its certificate or whatever.  If there is an old ticket 
that the client can use to get service then it  is able to get around 
having to reauthenticate with new credentials.

> tickets are generated by servers.

Right, that's as per 4346.  However, 4507 says "When presenting a 
ticket, the client MAY generate and include a Session ID in the TLS 
ClientHello."  Given that the client can change the session id, it 
becomes difficult (not impossible as I initially thought) for the server 
to track and invalidate old tickets.  But, perhaps as you say, this is 
generally not an issue in practice.  If the ticket lifetime is generally 
short enough, it is probably not a big deal (although it would have been 
nice to have stated it in 4507).

regards,
Lakshminath

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 13 Jan 2007 16:28:48 -0800

Lakshminath Dondeti <[email-masked]> writes:

> The issue is that of revocation.  If a client's credentials are
> revoked, a full exchange will ensure that the client gets service only
> after it acquires/renews its certificate or whatever.  If there is an
> old ticket that the client can use to get service then it  is able to
> get around having to reauthenticate with new credentials.

Yes, as I said there are *two* issues. One issue is about what
happens when a client simply initiates a full handshake. In
that case there is no general need to invalidate an old ticket.
TLS is quite capable of having two parallel sessions between any
pair of communicating parties.

However, as you indicate, you might want to explicitly terminate
a session. As Vidya indicated, this requires server side state,
though less than a session cache would require.

> becomes difficult (not impossible as I initially thought) for the
> server to track and invalidate old tickets.

It's not difficult at all. You invalidate the ticket, not the
session ID. The details are described in the SBR04 reference
cited below.

> But, perhaps as you say,
> this is generally not an issue in practice.  If the ticket lifetime is
> generally short enough, it is probably not a big deal (although it
> would have been nice to have stated it in 4507).

Well, here's what 4507 says:

5.1.  Invalidating Sessions

   The TLS specification requires that TLS sessions be invalidated when
   errors occur.  [CSSC] discusses the security implications of this in
   detail.  In the analysis in this paper, failure to invalidate
   sessions does not pose a security risk.  This is because the TLS
   handshake uses a non-reversible function to derive keys for a session
   so information about one session does not provide an advantage to
   attack the master secret or a different session.  If a session
   invalidation scheme is used, the implementation should verify the
   integrity of the ticket before using the contents to invalidate a
   session to ensure that an attacker cannot invalidate a chosen
   session.

[CSSC] is a reference to SBR04, which provides a fairly detailed
analysis of a variety of different ticket revocation schemes.

-Ekr

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 13 Jan 2007 18:55:26 -0800

No disagreements, just clarifying below:

> pair of communicating parties.

This and key separation between sessions etc., are quite clear and there 
are no issues there.
> though less than a session cache would require.

Right, this is what I was pointing out as "difficult" (for some degree 
of difficulty :) ).  Either we need more state or more state plus some 
more computation to invalidate a ticket (I am thinking a hash 
computation), if the identity (session id) is not fixed.  Yes, I took a 
quick at the relevant portions of the paper you cite, but that analysis 
assumes that there is a session id and assumes that the server has a 
blacklist of invalidated sessions.

In any event, I understand this better now.  Thanks for the clarifications.

regards,
Lakshminath

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 13 Jan 2007 22:31:25 -0800

Lakshminath Dondeti <[email-masked]> writes:
> computation), if the identity (session id) is not fixed. 

Actually, the existence of the session ID doesn't change matters
much at all. Whatever operations you would follow with the
session ID you follow with the ticket. 

> Yes, I took
> a quick at the relevant portions of the paper you cite, but that
> analysis assumes that there is a session id and assumes that the
> server has a blacklist of invalidated sessions.

RFC 4507 has both a ticket and a session ID. BSR04 uses the
ticket as the session ID.

-Ekr

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 14 Jan 2007 08:54:11 -0800

Thanks Eric.  I guess in my quick scan of your paper, I missed the 
"ticket" as the "session ID" aspect.  In fact, hashing of the ticket as 
a substitute for session ID was what I was thinking about as the "extra" 
computation.   Now the paper does talk about hashing the session ID, 
which makes sense now :).

cheers,
Lakshminath

---

From: Martin Rex <[email-masked]>
Date: Mon, 15 Jan 2007 15:01:56 +0100 (MET)

> Security (TISSEC) , Volume 7, Issue 4, November 2004.

Since you didn't include an URL, I assume this isn't available online
anwhere.

We have just been reported by one of our customers what I consider
a bug in the client side SSL/TLS session cache of a popular Browser,
failing on a flawed assumption.

Scenario:  A host running two seperate SSL/TLS secured services
(a J2EE- and a C/C++-built serice) on different TCP-Ports using
seperate SSL/TLS (one is pure Java, the other pure C) implementations
that differ in the highest supported protocol version.

The Service with the newer implementation is the "main service"
or entry point, and it sometimes generates URLs
referencing the other service (same host, different TCP-Port)
with the older SSL/TLS implementation.

The problem: The popular browser, when trying to access the older
SSL/TLS implementation on a different TCP-Port is sending a
session ID from the newer SSL/TLS implementation, apparently trying
to resume an existing SSL session in the client-side session cache.

The server doesn't recognize that session and replies with
a Server Hello containing his highest protocol version, plus
plus server certificate message plus client cert request plus
server hello done.  The popular Web Browser closes the network
connection without sending any kind of SSL alert and shows
"Page cannot be displayed" to the user.

I firmly believe that this is a conceptual flaw on the client
side, making a flawed assumption about when a cached SSL session
can be expected to be resumable.

The problem is not with the client sending an existing session ID,
it is about dealing with the servers reply during the SSL/TLS handshake.
 - a server on a different port might not be sharing the session
   cache with the other
 - a server on a different port migt be using an entirely different
   SSL/TLS protocol implementation supporting different protocol
   versions and extensions
 - a server on a different port might be using a seperate server cert
 - a server on a different port might be sending/using an independent
   list of trusted CAs in a client certificate request

In our customers case, the Browser might be aborting thinking that
the a version rollback attack is being performed, but honestly, I don't
know what the problem is.  The browsers SSL implementation is
extremely poor/broken when reporting errors.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 15 Jan 2007 15:01:56 +0100 (MET)

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Jan 2007 07:38:04 -0800

> Since you didn't include an URL, I assume this isn't available online

No, I just forgot.

http://www.hovav.net/dist/sslex.pdf

> can be expected to be resumable.

ISTM that there are two issues here:

1. Whether the client should have offered asession ID.
2. Whether it should have choked when the server refused.

Without taking a position on the first, which I think is tricky,
the client should definitely not have choked. Servers can always
refuse to accept a resumption.

-Ekr

---

From: <[email-masked]>
Date: Mon, 15 Jan 2007 08:06:23 -0800

> refuse to accept a resumption.

I reasoned differently, because this is an https context - 
there is thus a URL resolver involved. The validity of a 
secure URL is not the same as the validity of an SSL-named 
layer 4 TCP port (or SSL-named PPP tunnel connection,....)

At the SSL layer, the client sought a session resumption 
from a named layer 4 port. Session resumption means that the 
URL resolver at the https layer, however, is based on the 
client's connection state , not the host/port parsing. This 
includes the binding of URLs used in session creation, and 
the URL used in connection establishment (which are allowed 
to differ)

IN the cited case, a server responding from a given layer 4 
port of the second URL refused to resume a session (for some 
reason, like it didn't share session state records with 
another implementation). It then correctly engaged in a full 
handshake (with unusual custom pipelining of full handshake 
messages).

The client is entitled to reject the handshake, as in any 
full/partial rehandshake case. The client uses the 
conforming option to close the TLS Transport (TCP) rather 
than perform a close. This is reasonable, given the URL 
resource showed no knowledge of the sessionid/keying 
material.

---

I exploit the SSL architecture myself, sending server 
HelloRequests to my clients which respond with a clientHello 
(with special data in the time/nonce), a server Hello is 
similarly sent with similar custom time/nonce, which causes 
the client to finally issue a "sorry no"... alert, 
non-fatal. My special data happens to be time-synced OTPs 
(with CR capability, beyond STD 61), generated by a USB 
smartcard device. Given the flow is occurring over the 
current connection state (which is running mac'ed in my 
cipher suite, and each fragment gets DOA semantics from the 
confidentiality service) I'm adding timing signals to the 
SSL record_layer essentially.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Jan 2007 08:17:35 -0800

<[email-masked]> writes:

> there is thus a URL resolver involved. The validity of a secure URL is
> not the same as the validity of an SSL-named layer 4 TCP port (or
> SSL-named PPP tunnel connection,....)
>
> At the SSL layer, the client sought a session resumption from a named
> layer 4 port. Session resumption means that the URL resolver at the
> https layer, however, is based on the client's connection state , not
> the host/port parsing. This includes the binding of URLs used in
> session creation, and the URL used in connection establishment (which
> are allowed to differ)
>
> IN the cited case, a server responding from a given layer 4 port of
> the second URL refused to resume a session (for some reason, like it
> didn't share session state records with another implementation). It
> then correctly engaged in a full handshake (with unusual custom
> pipelining of full handshake messages).
>
> The client is entitled to reject the handshake, as in any full/partial
> rehandshake case. The client uses the conforming option to close the
> TLS Transport (TCP) rather than perform a close. This is reasonable,
> given the URL resource showed no knowledge of the sessionid/keying
> material.

Peter, 

TLS session IDs do not come with any guarantee that the server will
actually honor a resumption request. The server may implement any
session cache policy it chooses. Therefore the client *must* be
prepared for the server to refuse resumption.

-Ekr

---

From: <[email-masked]>
Date: Mon, 15 Jan 2007 09:05:42 -0800

> prepared for the server to refuse resumption.

So the only thing we are disagreeing on is the definition of 
"must be prepared".

You say choked, I say graceful fail.

So... we are back to the reasserting the old adage: the TLS 
standard DOES NOT constrain or recommend on how TLS 
Transport connections are handled in general. The words in 
TLS could not be much clearer. https is of course both an 
application and a "usage model" for TLS, some SSL-related 
parts of which folks have attempted to create a standard 
profile as regard alert handling.

I fail to see why the UI behavior of a multi-URL-protocol 
browser should be different for https vs other URL 
protocols. Furthermore, a non-Navigator-style web client is 
even less constrained, because it may a moniker resolver 
aswell as a URL resolver built into the application. We all 
know wininet has different https behavior to IE, which is 
yet different to the MSN Explorer. We all know Navigator in 
turn has "unique" security semantics concerning its SSL 
session duplication , and a "unique" trust access model to 
cookies by child windows etc... I have no expectation that 
navigator's client-side sessionid caching policy (for https 
resolution) is the same of the other 3 examples, I gave!

If the particular browser experience design has established 
(via a combined security vs usability tradeoff analysis) a 
certain practice concerning how it visualizes and handles 
(connection) failure cases (cannot "connect" to a resource, 
ultimately) when using all the NON-https URL protocols why 
should it vary this view ...for the session resumption 
exception on the https URL?

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Jan 2007 09:12:11 -0800

<[email-masked]> writes:

> So the only thing we are disagreeing on is the definition of "must be
> prepared".
>

No, I don't agree with this analysis. The server being unwilling
to resume a session is normal behavior. The TLS state machine
explicitly handles such cases. Implementations which choke
rather than doing a full handshake are broken.

-Ekr

---

From: <[email-masked]>
Date: Mon, 15 Jan 2007 09:27:25 -0800

> rather than doing a full handshake are broken.

Perhaps the TLS state machine changed from the SSL state 
machine ? I did notice in your book how you tied your 
concept of the state transitions of an implementation to the 
TCP state machine, something I don't do.

Its like we said for trust chains: regardless of what a 
server sends, what  client APPLICATION uses is up to it. it 
can ignore the server-supplied trust chain, if it chooses.

The same goes for accessing client-side crypto. Jus because 
a server (which has not proved knowledge of secrets from a 
TLS-connection state) seeks me to access my crypto device 
DOES NOT MEAN I DO IT. Im perfectly entitled to have a 
product design that seeks the user to enter a smartcard at 
that point; and close MY connection attempt if the user does 
not present it in some time.

We are now squarely arguing over:-

   One advantage of TLS is that it is application protocol 
independent.
   Higher level protocols can layer on top of the TLS 
Protocol
   transparently. The TLS standard, however, does not 
specify how
   protocols add security with TLS; the decisions on how to 
initiate TLS
   handshaking and how to interpret the authentication 
certificates
   exchanged are left up to the judgment of the designers 
and
   implementors of protocols which run on top of TLS.

and then (note the final clause):-

   If the application protocol using TLS provides that any 
data may be
   carried over the underlying transport after the TLS 
connection is
   closed, the TLS implementation must receive the 
responding
   close_notify alert before indicating to the application 
layer that
   the TLS connection has ended. If the application protocol 
will not
   transfer any additional data, but will only close the 
underlying
   transport connection, then the implementation may choose 
to close the
   transport without waiting for the responding 
close_notify. No part of
   this standard should be taken to dictate the manner in 
which a usage
   profile for TLS manages its data transport, including 
when
   connections are opened or closed.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Jan 2007 09:41:05 -0800

<[email-masked]> writes:

> Perhaps the TLS state machine changed from the SSL state machine ?

No, it didn't. This feature has been there since SSLv3 (and in
variant, since SSLv2).

> Its like we said for trust chains: regardless of what a server sends,
> what  client APPLICATION uses is up to it. it can ignore the
> server-supplied trust chain, if it chooses.
>
> The same goes for accessing client-side crypto. Jus because a server
> (which has not proved knowledge of secrets from a TLS-connection
> state) seeks me to access my crypto device DOES NOT MEAN I DO IT. Im
> perfectly entitled to have a product design that seeks the user to
> enter a smartcard at that point; and close MY connection attempt if
> the user does not present it in some time.
>
>    One advantage of TLS is that it is application protocol independent.
>    Higher level protocols can layer on top of the TLS Protocol
>    transparently. The TLS standard, however, does not specify how
>    protocols add security with TLS; the decisions on how to initiate
>    TLS
>    handshaking and how to interpret the authentication certificates
>    exchanged are left up to the judgment of the designers and
>    If the application protocol using TLS provides that any data may be
>    carried over the underlying transport after the TLS connection is
>    closed, the TLS implementation must receive the responding
>    close_notify alert before indicating to the application layer that
>    the TLS connection has ended. If the application protocol will not
>    transfer any additional data, but will only close the underlying
>    transport connection, then the implementation may choose to close
>    the
>    transport without waiting for the responding close_notify. No part
>    of
>    this standard should be taken to dictate the manner in which a usage
>    profile for TLS manages its data transport, including when

No, I don't agree that we're arguing over this at all. We're arguing
about whether it's appropriate to treat failure to resume as an error.
It's not.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Mon, 15 Jan 2007 19:03:39 +0100 (MET)

> rather than doing a full handshake are broken.

I fully agree with Eric that a client MUST deal gracefully with
a server that does not resume a proposes SSL session (ID) for
whatever reason.

The particular problem in the scenario that I listed might be
that the client, by retrieving a cached session from its cache
thought he had several parameter (including the protocol version)
already established and treated the response from the server
(who didn't resume as proposed) probably more like a renegotiation
rather than a new handshake, and therefore might have considered
the unavailablility of the previous higher protocol version
a rollback attack.

The client-side SSL session cache can not be implemented "transparently"
in the TLS implementation, it needs significant extra information
from the application in order to know whether and which cached
SSL session might be resumed.

Think about a client-side proxy (CONNECT), where the layer above
TLS must perform the CONNECT handshake with the proxy, and where
the network target IP and TCP-Port will be the same for all non-local
addresses.  There, the decision whether and which SSL session cache
entry might be tried for resumption will have to be derived from
the hostname:port from the URL (which is also used for
server endpoint identification).  In our customer's scenario,
no proxy is involved, so the different endpoint is visible on
both, the socket and the URL.

-Martin

---

From: <[email-masked]>
Date: Mon, 15 Jan 2007 10:57:50 -0800

> a server that does not resume a proposes SSL session (ID) 

Show me the text in the standard that says MUST (or even 
half hints MUST from the English wording). Tell me it MUST 
apply to EAP-TLS, too. More importantly, tell me what 
"appropriate" and "graceful" then mean, for packets on the 
wire. Tell me what the server MUST do, if the client does 
not comply. Your both making this out to be security- or 
interoperability- critical (it's a MUST, Peter!!)

Eric is clear that this is not a new concept (for novel 
discussion); but an ancient one. It must be pretty obviously 
disclosed, or have been improved (by now) due to the years 
of text review.

Now, for my part, I already pointed out text that says, I 
the implementer have 100% control over open and closing 
connections. NOTHING IN THIS STANDARD SHALL ...

Now, I will also listen to any decent appeal. I'm willing to 
be convinced (just show me some half reasonable basis from 
the standard), as the text I'm quoting was admittedly highly 
contextualized.  But, it was also an adamant, general claim. 
So, give me some SSl2, SSL3, TLS1.x text (not argument) to 
weigh against it.

Concerning the evidence:-

"The particular problem in the scenario that I listed might 
be
that the client, by retrieving a cached session from its 
cache
thought he had several parameter (including the protocol 
version)
already established and treated the response from the server
(who didn't resume as proposed) probably more like a 
renegotiation
rather than a new handshake, and therefore might have 
considered
the unavailablility of the previous higher protocol version
a rollback attack."

VERY LIKELY! This is in MY purview - as a implementer - to 
decide; Martin, you are making my point for me. My 
implementations don't support ANY of the fallback practices, 
either, by default!

Now that implementation may or may not have a good attack 
signature algorithm; perhaps its intentionally 
non-conforming in its TLS handling of protocol version 
negotiation, even. But, my only point is: its for EITHER 
PEER to decide (right or wrong) on whether it closes a 
connection abruptly. We cannot assume otherwise in any case, 
since the IDS may interdict packet flow anyways, for its own 
reasons. E.g. If you even propose NullWithNull in a non 
private-mode EAP-TLS handshake, you will be dropped by my 
IDS. Period.

Now if I'm am even half convinced that the standard 
specifies what you both assert, I will properly eat crow, 
but I will not actually change my default security policy: 
Ill simply disclose non-conforming (default) behavior. 
Gaining Interoperability in open systems OFTEN DOES demand a 
lowering of absolute thesh-holds - but at the user's 
discretion.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Jan 2007 11:05:24 -0800

<[email-masked]> writes:

> Show me the text in the standard that says MUST (or even half hints
> MUST from the English wording). Tell me it MUST apply to EAP-TLS,
> too. More importantly, tell me what "appropriate" and "graceful" then
> mean, for packets on the wire. Tell me what the server MUST do, if the
> client does not comply. Your both making this out to be security- or
> Eric is clear that this is not a new concept (for novel discussion);
> but an ancient one. It must be pretty obviously disclosed, or have
> been improved (by now) due to the years of text review.
>
> Now, for my part, I already pointed out text that says, I the
> implementer have 100% control over open and closing

RFC 4346 S 7.3.

   If a match is found, and the server is willing to re-establish the
   connection under the specified session state, it will send a
   ServerHello with the same Session ID value.  At this point, both
   client and server MUST send change cipher spec messages and proceed
   directly to finished messages.  Once the re-establishment is
   complete, the client and server MAY begin to exchange application
   layer data.  (See flow chart below.)  If a Session ID match is not
   found, the server generates a new session ID and the TLS client and
   server perform a full handshake.

In other words, refused session resumptions are totally normal
behavior. Clients which treat them as anomalous are confused.

Yes, a client can terminate the connection at any time and for
any reason, including that it doesn't like the phase of the moon,
but that doesn't make the assumption that a server will always
resume a session---presenting an error to the user if it
doesn't---any less insane. No such error occurred.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Mon, 15 Jan 2007 20:23:00 +0100 (MET)

> interoperability- critical (it's a MUST, Peter!!)

I think it is acceptable for a client to have a certain level
of expectation about the servers characteristics for the exact
same target endpoint (host:port), but not for a different one
on the same host.  Especially in the real world of NATs.

It is an implied MUST, not one that is spelled out, based on
common sense and established practices.

Where in the spec do you find an indication that a client
may blindy assume that all processes on one host will share even
the most valuable secrets, like credentials and an SSL session cache.

In the (Berkeley) Sockets interface there is a tradition that a
server process opens a listener Socket and keeps accepting connections
on this sockets for the lifetime of the process.  Different server
processes traditionally listen on different TCP and UDP ports,
and it is a longstanding security practice to not have each and
every service running with full system privileges.

SSL is an extension to the (Berkeley) Socket interface and
has basically inherited these traditions.

> be that the client, by retrieving a cached session from its 
> cache thought he had several parameter (including the protocol 
> version) already established and treated the response from the server

I think it is clear from the protocol handshake and the state machine
that there is a significant difference between a server not resuming
a cached session and an established session doing a renegotiation.
For the denied resume, there is no agreement on a common previous
session state, while for a renegitiation request, there exists
common agreed-upon session state.

-Martin

---

From: <[email-masked]>
Date: Mon, 15 Jan 2007 11:34:43 -0800

> doesn't---any less insane. No such error occurred.

This only partly reflects the case in question. I agree its 
the defining technical paragraph, tho (*).

The server in Martin's case didn't find a match: that was 
the whole point. So, the last phrase controls. And, there is 
not a MUST in there.

Ok. Lets conclude this, procedurally. Who agrees that TLS 
1.2 shall be changed to:-

"If a Session ID match is not found, the server generates a 
new session ID and the TLS client and server MUST perform a 
full handshake."

With that settled, the next implementer get a nice, simple 
conformance case to test. No more interpretive arguments.

------
(*) I think THE FOLLOWING WAS BETTER WRITTEN personally

"   Sessions cannot be resumed unless both the client and 
server agree.
   If either party suspects that the session may have been
   compromised, or that certificates may have expired or 
been revoked,
   it should force a full handshake. "

and lets not forget that maintaining a session resumption 
cache is OPTIONAL for a client in SSLv3.

---

From: <[email-masked]>
Date: Mon, 15 Jan 2007 11:48:18 -0800

----- Original Message -----
From: "Martin Rex" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Monday, January 15, 2007 11:23 AM
Subject: Re: [TLS] Re: when is it ok to resume a cached 
SSL/TLS session

> common agreed-upon session state.

Make your recommendation on the text change I proposed, for 
TLS 1.2. You have two choices really, given your (combined) 
arguments: SHOULD or MUST.

If this is important enough, one of those two changes can be 
incorporated. It's a one word change.

---

From: <[email-masked]>
Date: Mon, 15 Jan 2007 12:35:44 -0800

OpenSSL, following the SHOULD recommendation

Out of interest, in resumption procedures does OpenSSL (a) 
maintain the earliest expiry date of the certs in the 
partys' cert chains in the connection state(s), or (b) 
revalidate cert chains?

If a server receives a client nonce that is later than the 
expiry data of the client cert INDICATED, is this a fatal 
alert case - even before handing the cert chain to the 
application? I assume not, under the "certs are opaque 
objects to SSL protocol machine" rule

While invalidated sessionIds and expired/invalid certs DO 
NOT require either party to drop an ongoing TLS Connection, 
these same conditions CLEARLY control active session 
duplication, session resumption, and full handshakes.

---

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 15 Jan 2007 18:45:35 -0700

An IP/port pair is sacred.  This has two consequences:

1) session IDs should never be leaked beyond the sacred space into
another sacred space, and
2) Even when resumption is requested, the server must be prepared for
the client not to resume, and the client must be prepared for the
server not to resume.

When you 'exploit' the wording of any given publication, you end up
with a situation such as what you describe: whether it's "choking" or
"gracefully failing", the behavior is not what the end-user expects --
and since it's the end-user who must be built to, it's the end-user
who determines what to describe it as, and the developers tasked with
building to that end-user.

"Be conservative in what you send."  This has much more specific
meaning in security-related protocols, because "...and liberal in what
you accept" tends to reduce the security thereof.

If a browser gets a "bad request" response from the server, does it
instantly abort the connection and say "cannot connect"?  No, it goes
through its list of alternate protocols that it can possibly use.

(more comments interspersed)

> So the only thing we are disagreeing on is the definition of

The session-resumption mechanism is explicitly optional negotiation
acceleration in all of the drafts I've seen.  This means that at all
times a new connection is made and security parameters negotiated, it
MUST be possible for either side to say "I want a full negotiation"
and, regardless of the preference of the other side, get it.

>From a user interface standpoint, throwing a fit when you don't get
your way is a surefire way to get users not to use your software.

> You say choked, I say graceful fail.

tomato, tomahto.  To the user of the software, it's the same damned thing.

> resolution) is the same of the other 3 examples, I gave!

Which is why session resumption is an explicitly optional construct.

> exception on the https URL?

How is "unable to connect" to a protocol-conforming server a usability
decision?  That's a usability failure.  But, this is layers 6 and 7,
not layer 4.  Layers 6 and 7 build off of the capabilities of layer 4,
and layer 4 provides its capabilities without reliance on information
only available at higher layers.  This is the only way protocol
designers can keep themselves sane.

TLS is "as transparent as possible".  That doesn't mean that it can be
wholly transparent.

-Kyle H

---

From: <[email-masked]>
Date: Mon, 15 Jan 2007 21:01:18 -0800

> Which is why session resumption is an explicitly optional 

And, its why the protocol has an explicit no_renegotiation 
alert; just because the server ASKS for a renegotiate DOES 
NOT MEAN it gets it. Further, the client can assert 
user_cancelled, mid handshake and post-ServerHello anyways, 
even if the full handshake SHOULD proceed.

---------

So, lets get down to text:-

So, who is for the proposed wording change? If its what 
EVERYONE understands anyways, adding one clarification term 
(MUST) to the text quoted by Eric that governs this case 
..is evidently going to have zero nay votes (I'll be 
abstaining). However, two class C students (me and the 
browser maker cited by Martin) will have been quite properly 
instructed.

Right now, TLS WG is apparently asserting, in effect, that: 
When attempting to resume a session, a client SHOULD NOT 
send a no_renegotiate alert if a server proceeds to a full 
handshake (I.e. populates ServerHello with a non-zero value 
that is different to that in the ClientHello). Furthermore, 
the client SHOULD NOT send a user_canceled alert during such 
a full handshake should the endpoints proceed.

Arguably, the WG is asserting the stronger form for both 
these conditions: MUST.

I’ll offer a compromise here, note. IESG could say: if the 
client seeking session resumption receives a request to 
proceed with a full handshake , it MUST proceed with the 
handshake or it MUST immediately send either a 
no_renegotiation or a user_canceled alert.

user_canceled simply means in this context: give me session 
resumption under the cited ciphersuite, or don’t bother. The 
server can send a hello-request if it invites the client to 
retry the sessionid, given it now has knowledge of the 
"insistence"; otherwise it just closes the TLS connection 
using the conventions of the bearer.

Now, as a principle: Why the SSL application cares to do 
this is up to the designer of the application. In all cases, 
as the standard asserts: its never the business of SSL/TLS 
protocol layer to know or care WHY SSL applications open or 
close connections, or under what conditions. Its just a 
state machine that trundles along, doing its automata thing. 
Whether an SSL application such as https support a usable 
hypermedia or other web usage experience or not... requires 
evaluating https and the web client in question.

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Jan 2007 19:08:15 +0100 (MET)

> browser maker cited by Martin) will have been quite properly 

You have to include me in the count of the class C students
that appreciate somewhat clearer guidelines in the spec.

I think that the TLS spec could elaborate a little more on
non-obvious session caching issues. 

There is, for example the not very obvious session "duplication"
that you mentioned, i.e. several servers and several browsers
put an established SSL session (right after the SSL handshake
has successfully completed) into their session cache and will
duplicate the session for parallel connections to the same server
(per default many browsers open up to 4 parallel connections
to the same target).  The SSL sessions on those parallel network
connection will normally use the exact same SSL session ID.

> a full handshake should the endpoints proceed.

I'm a little confused.  A rejected session-resumption differs from a
renegotiation.  A no_renegotiate alert is not applicable to this situation.
Further protected communication is still possible after a denied
renegotiation, but it is a fatal error if the server can not or
does not want to resume a previous session proposed by the client
on a new connection.

> no_renegotiation or a user_canceled alert.

Requiring a server to be able to resume a session is a bad idea.
The reasons why a server has deleted a previous SSL session from
his cache are manyfold.  I recently added a maintenance API to
our SSL abstraction layer to flush the SSL session cache
mid-flight, e.g. when the server certificate is updated/replaced
or the list of trusted CAs is changed.  Active sessions remain
as they are, but resumption from cache is no longer possible
and all new connections will have to go through a full SSL
handshake and operate with the new parameters (server cert,
trusted CA list).

There are various issues that determine how long an SSL session
will be considered valid by either side (client and server) and
at what point it will be flushed from the cache.  The spec says
that a session should be valid at most two hours.
The SSL session cache management on the server side may flush
them much earlier, in particular when the server is under
heavy load.

HTTP(S)/1.1 keep-alive session also do not live forever.
It is to be expected that the server closes them after some
idle time, 30 to 60 seconds is not unusual.  Clients also
commonly close keep-alive sessions after some idle time.

Client-side SSL session caching has not been universally implemented.
While probably all Web-Browsers have&use it, Apache's mod_proxy
seems to entirely lack it.  Slicing of Mime-headers so that
every line is written as a seperate SSL record is another performance
problem created by mod_proxy.

-Martin

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 16 Jan 2007 19:52:02 -0800

> [CSSC] is a reference to SBR04, which provides a fairly 
> detailed analysis of a variety of different ticket revocation schemes.
> 
> -Ekr
> 

I don't believe the above text captures all of what has been discussed
in this thread. Let's separate the issues of invalidating sessions and
subsequent ticket replays. The above text is referring to the fact that
the hash functions used are not reversible and hence, failure to
invalidate sessions is not a major problem. That is one aspect. However,
as your paper documents, in order to prevent repeated use of invalidated
tickets, the server must maintain a "black list" of sessions. The paper
refers to this in the context of timing analysis of the master secret,
which would involve an attacker different from the client. This also
seems true when the client has been revoked priveleges, for instance -
if the server invalidated a session because the client must no longer be
allowed to access it, the client may continue to replay an unexpired
ticket (essentially, the client becomes the attacker here) and without a
black list on the server, it is impossible to keep track of that. That
does not seem to be captured in the RFC. I think it would have been
useful to explicitly state the need for some minimal state at the server
in order to thwart these attacks. 

Vidya

---

From: Martin Rex <[email-masked]>
Date: Wed, 17 Jan 2007 20:51:08 +0100 (MET)

> extremely poor/broken when reporting errors.

After some further investigation I have been able to reproduce
the error on our machines.

It seems to be related to either the ciphersuite or the
(algorithm) of the server's certificate (RSA vs DSA).
The protocol version doesn't seem to matter in this case.

The customer has installed a DSA server certificate on the newer
J2EE service and an RSA server certificate on the older C/C++ service.

I've just reproduced this behaviour using an IIS with DSA certificate
and my own test-server with an RSA certificate on the same host
but different ports.

When I click an URL referencing the RSA-server on a page served
from the DSA-server, the browser aborts with "Page cannot be displayed".
When I hit "refresh", the page loads. (Maybe the browser invalidates
the client cache entry after the error).

-Martin