Subject: [TLS] Consensus Call: FNV vs SHA1

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 10 May 2010 10:39:28 -0700

I don't see much new being added to this discussion at this point.  I'd
like to close on this.  If you have an opinion please indicate if:

a) You favor SHA-1
b) You favor FNV-1a

Thanks,

Joe

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 10 May 2010 19:48:25 +0200

> like to close on this.  If you have an opinion please indicate if:

I favor FNV-1a.

/Simon

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Mon, 10 May 2010 13:49:18 -0400

1. FNV-1a

On 5/10/10  13:39 , "Joseph Salowey (jsalowey)" <[email-masked]> wrote:

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

-- 
Regards,
Uri

---

From: Adam Langley <[email-masked]>
Date: Mon, 10 May 2010 13:58:47 -0400

> b) You favor FNV-1a

b) - I favour FNV-1a

AGL

---

From: Marsh Ray <[email-masked]>
Date: Mon, 10 May 2010 13:00:15 -0500

b) I favor FNV-1a

- Marsh

---

From: "Robert Dugal" <[email-masked]>
Date: Mon, 10 May 2010 14:07:47 -0400

I favor (a) SHA-1 

-- 
Robert Dugal		Senior Software Developer
Certicom Corp.		A Subsidiary of Research In Motion 
[email-masked]
direct        905.501.3848
fax             905.507.4230
www.certicom.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joseph Salowey (jsalowey)
Sent: Monday, May 10, 2010 1:39 PM
To: [email-masked]
Subject: [TLS] Consensus Call: FNV vs SHA1

a) You favor SHA-1
b) You favor FNV-1a

Thanks,

Joe

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 10 May 2010 20:14:30 +0200

a) I favor FNV-1a

/Stefan

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 May 2010 14:09:55 -0500

> like to close on this.  If you have an opinion please indicate if:

I lean towards (a) from a purely political point of view: I don't think
it's a good idea to train auditors to act reflexively.  However, from a
purely technical point of view I have no preference whatsoever at this
time, but I'd like answers to my questions below.

If the consensus is (b) then I think the following changes should be
made:

 - Add an informative reference to FNV (and expand the acronym).

 - Refer to FNV as a checksum (or even hash, or better, non-
   cryptographic hash) rather than as a digest.

   In the context of TLS )RFC5246), "digest" definitely refers to
   cryptographic hash functions.  We should not confuse the terminology.

 - Add a description of what happens if cached object checksums collide.

   No, the current security considerations section doesn't deal with
   this, and rightly so _if_ collisions are not a security problem, but
   what happens when there are collisions?  Do hanshakes fail?

   Also, could caching have been done without reference to hash
   functions?  E.g., by having servers assign IDs to objects for client
   caching?  Is it too late to consider this approach?

Cheers,

Nico
--

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 10 May 2010 21:24:02 +0200

Sorry, that was meant to say:

b) I favor FNV-1a

---

From: Martin Rex <[email-masked]>
Date: Mon, 10 May 2010 22:35:43 +0200 (MEST)

> like to close on this.  If you have an opinion please indicate if:

b) I favour FNV-1a

I think that (a) is underexplained, whereas (b) is pretty clear to me.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 10 May 2010 14:10:35 -0700

>   caching?  Is it too late to consider this approach?

Again, +1 to what Nico says here. If we're trying to make using FNV sensible for future use as well, let's do the work to get it right here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 May 2010 16:30:36 -0500

On Mon, May 10, 2010 at 02:10:35PM -0700, Paul Hoffman wrote:
> Again, +1 to what Nico says here. If we're trying to make using FNV
> sensible for future use as well, let's do the work to get it right
> here.

Thanks.  Note that I don't see FNV as having a bright future in our
protocols, so that I'm not concerned about making it easier to use in
the future.

I'm, however, concerned that the design of this protocol won't handle
collisions very well, whether FNV or SHA-1.  At first glance it sure
looks that way.  And ISTM that there's a better design that is or can be
impervious to hash collisions.  I could review the document thouroughly
and convince myself one way or the other, but I'm lazy -- I'd rather
hear from the authors, then evaluate their explanations.

Nico
--

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 10 May 2010 23:32:24 +0200

On 10-05-10 11:10 PM, "Paul Hoffman" <[email-masked]> wrote:
> Again, +1 to what Nico says here. If we're trying to make using FNV sensible
> for future use as well, let's do the work to get it right here.
> 

I'm OK with everything Nico suggests with respect to FNV (If Joe is fine
with an informational reference to a web page)

On the last question I think the correct answer is: Yes it is possible to do
a variant of the protocol without a hash function but it does not make the
protocol any better. Rather it make it worse. Both in terms of functionality
and complexity.

/Stefan

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Mon, 10 May 2010 17:35:20 -0400

On 5/10/10  17:30 , "Nicolas Williams" <[email-masked]> wrote:
> ...... Note that I don't see FNV as having a bright future in our

And you see a bright future for SHA-1???

> hear from the authors, then evaluate their explanations.

+1
-- 
Regards,
Uri

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 May 2010 16:39:25 -0500

> with an informational reference to a web page)

There are many examples of informational references to non-IETF,
non-standard documents.  For example, BCP0106 (remember the RNG thread?)
has an informational reference to "Turbid" in the form of a URL that is
clearly not stable in the same way that an RFC number is.  If you look
around you'll find many information references in RFC to I-Ds (usually
labeled "work in progress").

> protocol any better. Rather it make it worse. Both in terms of functionality

That's just a statement without an argument; I'm unconvinced.  Convince
us.  If you can show that collisions don't result in failure to complete
a TLS handshake successfully then all will be fine, so start there.
Else I think you should explain how a collision-free protocol would be
worse than the current proposal, then we could weigh the two approaches.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 May 2010 16:45:16 -0500

> And you see a bright future for SHA-1???

No, for the same reason I don't for FNV: I think we'll generally[*] need
cryptographic hash functions in our protocols.  The fact that FNV is not
a cryptographic hash functions is actually the red flag that started me
wondering about the design of this protocol.

Aside from that, I think FNV is a great hash function.  Its place will
typically not be in Internet protocols, but in implementations.

[*] I _can_ think of non-cryptographic uses of hash functions in
    Internet protocols, starting with the use we made in GS2.  But in
    general I think we'll want to review such uses carefully.  In the
    case of GS2 it saved us the bother of creating a registry of SASL
    mechanism names for GSS-API mechanisms.  Here the hash is used to
    identify cached items, which seems fine provided that collisions are
    well-handled.  In the GS2 case we decided that collisions were not a
    problem for us (after all, we could always assign new OIDs to GSS
    mechanisms that collide).

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 10 May 2010 23:48:09 +0200

>    what happens when there are collisions?  Do hanshakes fail?

I agree that it is important to explain this.

If collisions happen, it appears that we do get slightly weaker
semantics of what it means for a handshake to succeed: we aren't
cryptographically certain (in the sense that there is cryptographic
reduction) that the client and server agree on the data used during the
handshake for cached items (CA cert list, server certificate) after the
handshake has concluded.

It seems a server could easily create two pairs of server certificates
that results in the same FNV-1a value but are different certificates.  A
client connecting to a server offering a cached value for the server
certificate would not know which server certificate was intended, even
after completing the handshake.  If correct, that seems surprising.

This requires a conspiring server, so maybe it is irrelevant.

This problem would be solved if the Finished message were computed over
the replaced data rather than the digest value.  Then any data
mismatches would be detected at the TLS Finished computation, and the
handshake fail.  Perhaps this is simpler than introducing a
cryptographic digest.

It is late here, so I may be totally missing some aspect.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 May 2010 16:56:52 -0500

> handshake for cached items (CA cert list, server certificate) after the

In the success case I think we are certain that we don't care about
collisions, if there were any: the cryptographic properties of TLS
ensure this.

It's the failure case I'm concerned with.  If failures occur, how do you
recover?  If failures occur, will users want this?

> after completing the handshake.  If correct, that seems surprising.

If the server figures it out, who cares.  If not, bad.

> This requires a conspiring server, so maybe it is irrelevant.

Or just a CA to issue colliding certs.  Think rollover.

> handshake fail.  Perhaps this is simpler than introducing a

I think modifying the way Finished msgs are computed would make this
protocol way too complicated.  I'd be happier with the server assigning
object IDs to cacheable objects.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 May 2010 17:03:29 -0500

> collisions, if there were any: the cryptographic properties of TLS

Actually, maybe not!  I think on the server side we won't care about
collisions, but on the client side I think we care very much.  I think
the key is this: the client MUST NOT cache any objects from failed
handshakes.  Anyways, I've not done a careful analysis because I'm lazy
and I'd rather see what the authors have to say first :)

Nico
--

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 May 2010 00:06:48 +0200

> worse than the current proposal, then we could weigh the two approaches.

Yeah I know,

I was hoping I didn't have to since we have been through that debate
already.

If you force the Server to assign identifier you are adding complexity to
the protocol. The server now need to remember the relationship between
identifiers and objects instead of just calculating them when needed.

It also limits functionality since the client now first have to ask each
server about their identifiers, store them (per server) and replay them to
the server. With a hash, the client can try caching directly without first
asking the server for it's identifiers as soon as the client have a guess
about the cached info (e.g. By pulling info from a repository)

What if this is a cluster and two servers give out different identifiers for
the same cached object???  To me this simply smells like a lot of
un-necessary problems.

What if a collision occurs?

That is pretty deterministic too. The server and the client may then agree
on a cached value by mistake. They will then go ahead and try to complete
the handshake with different opinions on a cached security critical value,
such as disagreeing about the server certificate chain. This will inevitably
lead to a handshake failure.

Upon a failed cached handshake, the client and server tries a new handshake
without caching, updates it's cache and moves on with life.

However, the risk that a 64 bit FNV will collide by mistake (not as a result
of a malicious attack) is so small that the risk inconvenience of a
collision is acceptable.

Does this make any sense?

/Stefan

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 May 2010 17:15:32 -0500

> I was hoping I didn't have to since we have been through that debate

That's fine: I'd have accepted a URL to that debate.

> identifiers and objects instead of just calculating them when needed.

The server sure could use a hash, leaving it to the operator to look for
and address collisions.

> about the cached info (e.g. By pulling info from a repository)

True!  That's one thing I was looking for.  It's more than enough for me
to prefer the client-hashes approach to the server-assigns object IDs
approach.

> lead to a handshake failure.

That's what I thought.

> without caching, updates it's cache and moves on with life.

Well...  Many applications might not.  Can the handshake be retried
transparently to the application?  Or will the application have to
close() its socket and re-connect()?

> Does this make any sense?

Just a pair of questions left (see above).

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 11 May 2010 00:19:29 +0200

> collisions, if there were any: the cryptographic properties of TLS

Ensures what?  As far as I can see, it doesn't ensure that the server
knows which server certificate the client saw, or that the client knows
which ca-cert-list the server offered.  Both could influence which
client certificate the client selects, which seems potentially bad.

For example, I looked in the document, and I don't see any requirement
that clients only cache information from a server _after_ having
performed a successful handshake against the server.  Without that, an
attacker could setup a fake server that causes clients to cache some
information (different from what the real server would send), fail the
handshake, and let the client re-try against the real server, and the
client would then use the wrong cached information.

> recover?  If failures occur, will users want this?

I also want to see these questions (+ answers) covered in the document.
The answers aren't clear to me.

> object IDs to cacheable objects.

Doesn't this have the same problem with collisions?

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 May 2010 00:29:39 +0200

> close() its socket and re-connect()?

I agree that the draft may be underspecified here.

Would it help to say that upon handshake failure using cached information,
client and servers MUST NOT retry the same handshake using the same cached
information.

I would expect this to be totally transparent to a client application above
the socket.

/Stefan

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 May 2010 17:34:45 -0500

> client and servers MUST NOT retry the same handshake using the same cached

That's part of it, yes.

> I would expect this to be totally transparent to a client application above

Really?  So TLS libraries can do N>=1 failed handshakes without the
application noticing, without re-doing the TCP (or whatever) connection?
What about DTLS?

Nico
--

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 May 2010 00:51:44 +0200

On 10-05-11 12:19 AM, "Simon Josefsson" <[email-masked]> wrote:

> (different from what the real server would send), fail the

And.... ?

I don't mean to be rude, I just want you to complete the threat scenario.

In what way may this serve the attacker?
In what way may this cause serious harm to the victim?

If the client is fooled to cache the wrong server certificate, key
establishment will fail.

If the client is fooled to believe in a false set of acceptable CA names,
then the client may fail to find an acceptable client certificate to use.

Both will cause the handshake to fail (and cause next attempt to be without
caching).

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 May 2010 00:58:20 +0200

> application noticing, without re-doing the TCP (or whatever) connection?

I would expect the logic deciding whether to cache or not, to be transparent
to the application.

/Stefan

---

From: Hovav Shacham <[email-masked]>
Date: Mon, 10 May 2010 20:09:30 -0700

> like to close on this.  If you have an opinion please indicate if:

a) I favor SHA-1.

-hs.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 11 May 2010 09:59:51 +0200

> Both will cause the handshake to fail (and cause next attempt to be without

I'm thinking about two scenarios:

 1) the undetectable modification of the list of acceptable CA names
    cause the client to select and use an unintended certificate.

 2) where multiple server certificates can be used to successfully
    establish the key.  That can happen if two certificates use the same
    public key.  Once connected, the client will not know the server by
    the same identity (certificate) as the server believe the client
    used.

This is not an problem in the sense that an attacker gains some benefit
(for 1 the client chose to proceed with the certificate and for 2 the
attacker needs to know the private key of the server): instead I'm
pointing at a semantic problem because, with the extension, the
historically true invariant that the client, after handshake, will know
which certificate the server used, does not hold strongly.

This doesn't necessarily have to affect the document in any way, but it
is an interesting property.

/Simon

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 May 2010 12:29:16 +0300

(b) - FNV-1a

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joseph Salowey (jsalowey)
Sent: Monday, May 10, 2010 8:39 PM
To: [email-masked]
Subject: [TLS] Consensus Call: FNV vs SHA1

a) You favor SHA-1
b) You favor FNV-1a

Thanks,

Joe

Scanned by Check Point Total Security Gateway.

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 May 2010 15:39:50 +0200 (MEST)

Nicolas Williams wrote:
> Stefan Santesson wrote:

Re-thinking this scenario, I do not think that is a workable approach.

The reason why I originally asked for using a (sha-1) hash value over the
replaced data instead of a simple, server-assigned identifier,
was robustness.  Going through a handshake failure is _NOT_ an option.
I wanted to avoid the cache of the server and client to get out-of-sync,
and the use of a sha-1 hash value over the real data instead of that
data should be sufficiently robust so that the server will send the
real data in case the clients cached value differs from what the
server would normally send.

It is generally impossible to recover from a TLS handshake failure.
It normally requires closure of the existing connection and opening
of a new connection because it is completely unspecified how to
recover from a TLS handshake failure on a connection (and how to
clear the network pipe from unprocessed data from the previous handshake).

If a client-side proxy traversal is involved, a full app-level proxy
handshake is required.  If proxy traversal requires an OTP authentication,
it will be completely impossible without user interaction.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2010 10:21:54 -0500

> was robustness.  Going through a handshake failure is _NOT_ an option.

That's what I expect as well, that handshake failure is not transparent
to _all_ applications, and that any retry logic will have to be in the
application.  That makes this protocol a bit problematic -- failures
will be rare, no doubt, so rare that we might not care, but when they
happen the application won't know that the failure is not permanent.
For browsers that may not be a problem (the user will just reload); for
non-browser apps (and scripts running in the browser!) this could be a
problem.

> server would normally send.

I don't see how to recover from collisions, transparently to apps,
without either adding round-trips, which is supposed to be a big no-no,
or making handshakes retriable (I'm assuming they aren't).

> It is generally impossible to recover from a TLS handshake failure.

Well, the app can retry.

Also, StartTLS protocols might be able to retry without the application
having to disconnect/reconnect.

> clear the network pipe from unprocessed data from the previous handshake).

It's easy to clear the "pipe" since the records have lengths.

> it will be completely impossible without user interaction.

Is there such a thing as proxies that require OTP for authentication?

Nico
--

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 May 2010 16:45:51 +0200

Wouldn't this be solved automatically if the cache is flushed upon failure?

/Stefan

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2010 10:57:38 -0500

> Wouldn't this be solved automatically if the cache is flushed upon failure?

Not really:

a) the failed handshake will be visible to the application
(handshake_failure is a fatal error);

b) the failure will eventually happen again (since the user will most
likely want to talk to the same servers whose objects' checksums
collided.

I think you'll want to say that the cache must not be flushed, but
rather that objects with colliding checksums must be flagged as such so
that they are never used again via this extension.

Again, I expect this will not often be a problem, but when and if it is
then this problem might be difficult to diagnose and re-occur too often.

I think this argues for a cryptographic hash.  Collisions are not a
security problem here, but they are an operational problem.  IMO this
rules out FNV-1a.  Also, as Uri points out, you will want to have larger
numbers of hash bits (64 is too few for this application).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2010 11:04:35 -0500

> like to close on this.  If you have an opinion please indicate if:

Subsequent discussion shows that hash collisions are a problem for this
protocol, though not a security problem.  As such I believe that (b) is
now out of order, and therefore I now favor (a), with less or no
truncation.

I believe additional text is required to explain what to do when
collisions result, and also how to detect collisions (I think collisions
can only be detected heuristically on handshake failure, but can
confirmed on subsequent retry).

I believe too that a protocol design where collisions are avoided
altogether is not desirable.  But something to consider might be to send
not just a checksum/hash of cached objects, but also the name of the
first cert in any cert/cert chain or other nameable object -- this would
make collisions entirely avoidable by having operators check for them
before installing new certs.

Nico
--

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 May 2010 17:11:23 +0200

> (handshake_failure is a fatal error);

Yes

> likely want to talk to the same servers whose objects' checksums

Yes, and with the cash for that server flushed, the client will be bound to
retry without caching (since it has no data cached anymore).

The client will then (typically) update it's cache on the next successful
handshake and problem should be fixed.

/Stefan

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 11 May 2010 18:19:28 +0200

> now out of order, and therefore I now favor (a), with less or no

I'd like to see the document nail down what properties is required from
the digest, and explain the hash collision problem.  If hash collisions
really is a problem, that prompts the old question if we need hash
agility after all.  It isn't clear to me that moving from FNV-1a to
SHA-1 actually improves anything wrt collisions.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2010 11:33:41 -0500

> retry without caching (since it has no data cached anymore).

It's not a forgone conclusion that the client will retry.  The retry
will have to be at the application layer, and the application might not
be prepared to retry (since it won't know that the fatal error isn't
quite so fatal).

> handshake and problem should be fixed.

If one collision arises once, it will arise again, and again, and again
until all or all-but-one of the colliding objects are retired from use.
The client will have to detect collisions and then mark colliding
objects as must-not-use-from-cache.

Detecting collisions is hard.  If the application does not retry then
you can only heuristically decide that fatal errors imply collisions,
which will often not be the case.  If the application does retry then
the collision can be detected.  The server can't detect collisions any
more reliably nor sooner than the client (the server may have less
context than the client), I think.

Nico
--

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 11 May 2010 09:38:31 -0700

With a birthday collision of 64 bits (thanks Dave for reminding me of
this), you would need about 6 million server certificates to achieve a
probability of 1 in a million that 2 of those 6 million certificates
hash to the same value.  Since servers change certificates about once
a year, and a client doesn't need to remember any hashes of expired
certificates, and there is no problem if the certificates of unrelated
servers collide, this seems to be a non-issue.

The only question is whether FNV is as good of a hash function as is
required to resist the birthday attack.  My simple test showed that it
might be, but IANAC and don't know how to determine that.

Mike

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 May 2010 18:40:52 +0200 (MEST)

> or making handshakes retriable (I'm assuming they aren't).

A theoretical possibility would be some kind of "epoch" counter by
the server (or more general "peer", when caching is later extended
to apply to client-side handshake data as well).  The server would
have to bump that counter whenever it knows (or can not rule out)
that the cachable data has changed.

> It's easy to clear the "pipe" since the records have lengths.

There is *NO* guarantee that there are _only_ valid and complete TLS records
left in the pipe.

Flushing an orphaned closure alert is something that may be used to clear
a TLS connection after successful communication and a closure alert
handshake http://tools.ietf.org/html/rfc5246#section-7.2.1
but the current TLS spec doesn't provide grounds for interoperably clearing
a connection from residue of a failed TLS handshake.  It amounts to
heuristics based on good faith.

> Is there such a thing as proxies that require OTP for authentication?

I think that SOCKS has been used with OTP authentication.

TLS does't imply HTTP-over-TLS and client-side proxy doesn't imply
HTTP-proxy with CONNECT method and header-based authentication.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 11 May 2010 12:48:23 -0400

b) FNV-1a

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2010 12:01:52 -0500

> that the cachable data has changed.

That only helps when colliding objects all come from the same server.

> There is *NO* guarantee that there are _only_ valid and complete TLS records

Yeah, TLS handshakes are just not retriable.  You could have an
extension that makes them retriable, but if the TLS-GSS extension
foundered on state machine issues resulting from adding round-trips,
then so would an extension that makes handshakes retriable.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2010 12:04:19 -0500

> servers collide, this seems to be a non-issue.

I agree that collisions will be extremely unlikely.  My concern is how
to recover from them if they occur.

> might be, but IANAC and don't know how to determine that.

Based on a gut feeling I'd rather go with a cryptographic hash if
collision resistance is desired.  (Though, of course collision
resistance is not the same thing as having a low rate of collisions
with real world inputs.)

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 May 2010 19:35:14 +0200 (MEST)

> That only helps when colliding objects all come from the same server.

I assumes that ought to be an implicit requirement,
-- but forgot about the possibility of NAT-style server-side
load-balancing that may send you to a different server on
each connection.

The "prior art" about caching in TLS is TLS session caching,
where the session cache ID is 32-octets...

It appears that in principle, the caching extension should use
mostly the same granularity and scoping as the TLS session cache.

> then so would an extension that makes handshakes retriable.

The issue may be more complex.  What about a renegotiation handshake
under protection of a previous ciphersuite?  To what exact state do
you return when the server determines an error trying to process
the clients finished message?  What would it send back, under protection
or without, and what should the client reply, under protection or
without?  To me, that looks like a can of worms.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 11 May 2010 13:38:40 -0400

In general, protocols and standardized data structures may make use of
non-cryptographic hash functions in cases where collisions are
anticipated and well-handled: i.e. as optimizations (optional) rather
than as integrity (required) mechanisms.  PKIX AKI/SKI is an example:

   "The authority key identifier extension provides a means of
   identifying the public key corresponding to the private key 
   used to sign a CRL. ... This extension is especially useful
   where an issuer has more than one signing key, either due to
   multiple concurrent key pairs or due to changeover."

PKIX suggests two SHA-1 -based methods of generating SKIs (including the
4 bit constant 0100 followed by the 60 least significant bits of the
SHA-1 hash of a public key), and says "Other methods of generating
unique numbers are also acceptable."

The same reflexive "broken algorithm" evaluation concerns may exist for
this use of SHA-1, and FNV would perform the function just as well
without raising any eyebrows.

If a collision did occur, an implementation would have to do an extra
signature validation if it first picked the wrong certificate to
validate a signature.  Not much of a penalty, and one which would have
to be handled anyway for the case where AKI/SKI is not populated at all.

Dave

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 11 May 2010 14:03:39 -0400

This sounds like a general problem unrelated to caching.

If a non-browser app cannot recover from failures, what happens when a
bit error gets through multiple layers of detection and correction, or a
DSL connection dies and restarts?   "Stuff happens" all the time, and
humans know how to hit the "retry" button.  An unattended application
that doesn't know how to recover from unexplained errors is not ready
for prime time.

Dave

-----Original Message-----
From: Nicolas Williams

---

From: Marsh Ray <[email-masked]>
Date: Tue, 11 May 2010 13:28:13 -0500

>     the same identity (certificate) as the server believe the client

Frankly, this scares the hell out of me.

I admit now that part of why I supported the simple 'hashtable' function
was to ensure that this aspect got thoroughly analyzed.

> (for 1 the client chose to proceed with the certificate

Hmm, this could enable an attacker to influence the client to choose a
client cert using different information than the server thought he sent,
and in a way which doesn't break the Finished hashes?

Let's say I have separate "administrator" and "normal user" client
certs, both recognized by a server. Could mitm trick me into authing
with the admin cert even if the server app didn't intend to ask for it?

Note MS IIS has a feature for client-cert-to-user mapping, so
theoretically that could end up running code with different actual user
permissions.

> and for 2 the

Historically, it has turned out to be notoriously difficult to put
limits on the effects of a violated security guarantee. We may not be so
familiar with all the dependencies and assumptions made in the original
analysis that we can run through them backwards.

I recommend we walk through the security analysis on this again from
scratch. This time with extra focus on an attacker who can trivially
craft collisions.

Also, we should look into how this might interact with running multiple
servers on the same IP address (and same stack) using SNI. Sometimes
things that are secure in isolation do not produce a secure system when
composed.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2010 14:09:58 -0500

> that doesn't know how to recover from unexplained errors is not ready

Fatal errors are fatal.  But the error here isn't quite as fatal.  I
suppose I can agree to view as such though and then there's no real
problem.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2010 14:23:50 -0500

> If the server figures it out, who cares.  If not, bad.

I didn't think this through yesterday.  Let me try again.

The only way the collision could happen and the handshake succeed is (at
least for the cipher suites I've thought about) if a) the two certs have
the same public key, b) the client had seen one or both server certs
earlier.

And the attack?  I think it could be mostly harmless because the server
thinks the client authenticated the server as one entity name while the
client thinks it authenticated the server as another -- but both server
names must have been reasonably close to equivalent (HUGE assumption;
keep reading).  Sure, the client could get redirected to another server,
but only if the incorrect cert was properly signed, and only if the
client cache learns about that object (more assumptions).

The devil's in the details!

Some of those devilish details:

 - Clients MUST NOT cache objects from failed handshakes.

 - Clients MAY cache objects from succesful handshakes, and only when
   the clients authenticate the server (including validation of the
   server's cert chain to a TA).

 - In particular there MUST NOT be any caching in cases where the server
   is authenticated by the use of pre-shared certificates.

    - There must be no chance of caching objects when a user clicks
      through one of those "give your money to the bad guys?" dialogs.

Any others?  Yes, I should review the document closely now.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Tue, 11 May 2010 14:27:37 -0500

> that doesn't know how to recover from unexplained errors is not ready

FTP, telnet, and friends were considered to work well enough for a long
time. I think SSH still doesn't have any reconnection support in the
protocol.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Tue, 11 May 2010 14:32:12 -0500

> suppose I can agree to view as such though and then there's no real

1. Caching can't be done on the first handshake (for obvious reasons)

2. Cached info must be thrown out on any failure to successfully
complete a handshake (for security reasons)

So how much better is this caching scheme than what you could have today
with session resumption?

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2010 14:46:21 -0500

> So how much better is this caching scheme than what you could have today

I recall this question being asked long ago.  IIRC the idea is that you
could cache a cert chain for many servers' certs -- if they all have the
same validation chain, then you don't need to get a copy of it every
time you connect to one.  Also, session resumption state does expired,
whether kept as state on the server or via tickets.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Tue, 11 May 2010 14:51:24 -0500

>  - Clients MUST NOT cache objects from failed handshakes.

Bad guy may see the impending failure and delay the client's recognition
of it arbitrarily.

>    server's cert chain to a TA).

It appears that in a large class of client applications, the client TLS
stack may not even know how to fully verify the certificate until he
returns to the application code. Commonly the TLS stack validates that
the server's cert chains to a TA, but the application code queries for
and checks the CN after-the-fact. The method for checking CN is
protocol-specific.

Does the current proposal give more semantic meaning to the exchange of
Finished messages than was expected by such an application?

>    is authenticated by the use of pre-shared certificates.

Sorry if I missed this earlier, what's special about PSK here?

>       through one of those "give your money to the bad guys?" dialogs.

Haven't seen that one.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2010 15:00:24 -0500

> Bad guy may see the impending failure and delay the client's recognition

I didn't mean that clients could cache objects from in-progress
handshakes.  I realize that I wasn't sufficiently precise.  But thanks
for making that clear.

> and checks the CN after-the-fact. The method for checking CN is

In those cases the application should manage the cache (mostly by
calling TLS APIs that do the dirty work).  The caches for different apps
using different TAs should NOT meet.

> Finished messages than was expected by such an application?

Yes, though it doesn't change the computation of the Finished message
(maybe it should!).

> Sorry if I missed this earlier, what's special about PSK here?

You're right, I think it isn't.  I think I must have intended to say
that apps using different TA sets (and/or pre-shared certs) must use
different caches as well.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Tue, 11 May 2010 15:04:38 -0500

On 5/11/2010 2:46 PM, Nicolas Williams wrote:
> could cache a cert chain for many servers' certs

Isn't one of the implications of the choice of a non-collision-resistant
hash that you must use a completely separate cache for each hostname?

> -- if they all have the

- Marsh

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 11 May 2010 16:04:46 -0400

If there is a script to FTP a bunch of files, and one of the files
fails, then either a human or a manifest-understanding application needs
to notice the error and retry.  FTP itself doesn't have to be as
persistent about recovery as wget, but something above it needs to be.
How would FTPS with a cache collision induced failure be different?

Dave

-----Original Message-----
From: Marsh Ray [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 3:28 PM
To: Kemp, David P.
Cc: [email-masked]
Subject: [POSSIBLE SPAM] Re: [TLS] Collisions (Re: Nico's suggestions -
Re: Consensus Call:
Importance: Low

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2010 15:07:28 -0500

> hash that you must use a completely separate cache for each hostname?

I don't think that's clear yet.  However, it is clear that making this
extension safe will require more care than it seemed to me the first
time I glanced at it.  It may well be that the answer to your question
is "yes", in which case I think you'd be right that session resumption
is plenty good enough.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 11 May 2010 15:19:12 -0500

> How would FTPS with a cache collision induced failure be different?

I think that's the right question for us to be asking.

One way in which things are different is that this proposal introduces
the caching of long-term data. We have to ensure that a one-time
drive-by attacker cannot use the feature to cause the caching of
something that might adversely affect some unrelated operation in the
future.

We should also be careful to prevent data leaks. There is the potential
that server 'a' could engineer a probing collision to determine if
you've previously connected to server 'b'.

- Marsh

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 11 May 2010 17:16:34 -0400

The security analysis should focus on the bizarre Finished message
calculation rather than on the hash algorithm.  The essence of caching
is that cached data has the same effect as transmitted data, only faster
:-).  Section 4 violates that assumption:

   "The handshake protocol will proceed using the cached data as if it
   was provided in the handshake protocol. The Finished message will
   however be calculated over the actual data exchanged in the handshake
   protocol."

If the Finished message is not calculated as if the data were actually
transmitted, then it cannot ensure the integrity of that data.  Strike
the second sentence and the problem goes away.  The transmitter has to
perform Finished calculations on the original datastream, then
post-process it to substitute hashes where possible.  The receiver first
has to expand hashes into data, and then perform handshake operations
including Finished calculations.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marsh Ray
Sent: Tuesday, May 11, 2010 2:28 PM
To: Simon Josefsson
Cc: [email-masked]
Subject: [POSSIBLE SPAM] Re: [TLS] Collisions (Re: Consensus Call: FNV
vs SHA1)
Importance: Low

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Tue, 11 May 2010 16:30:48 -0500

> is "yes", in which case I think you'd be right that session resumption

Note: I didn't say precisely that I thought session resumption was good
enough, nor did I say that cached info isn't the greatest thing since
sliced bread. I just wanted to ask some direct questions.

Alternatively, if we determine that indeed the non-collision-resistance
of the hash function is the root of all remaining concerns that would be
very positive. We could solve them all in one stroke with
s/FNV-1a/SHA-256/g.

*ducks*

- Marsh

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 May 2010 23:00:15 +0200

Nico,

For there to exist two server certificates with the same public key but
entirely different certificate data, which are crafted to create a hash
collision, you must have at least one bad certificate issued by a dishonest
CA who validates to a root trusted by the client.

If this is the case, then cached info is the least of your problems.

For example, you have real problems if that same bad CA issues the attacker
a certificate (with the same name but another public key) through which the
attacker (having the corresponding private key) actually can fool the client
to authenticate the attacker as the legitimate server.

On the other hand, I would not object to include a requirement that data
should/must only be cached from a successful handshake where the server is
successfully authenticated. That should remove any residue of this issue.

/Stefan

---

From: Marsh Ray <[email-masked]>
Date: Tue, 11 May 2010 17:01:54 -0500

>    however be calculated over the actual data exchanged in the handshake

It is definitely a mismatch, but I think it's the simplest and least
inconsistent of the possible ways it could be defined.

> transmitted, then it cannot ensure the integrity of that data.

Not as easily and directly, but it can if we can prove either:

A. the values transmitted are perfect equivalents for the values used, or

B. a mismatch (no matter how carefully engineered by the attacker) can
not make a semantic difference to any reasonable application code other
than what would result from an ordinary Finished verify failure.

> Strike
> the second sentence and the problem goes away.

And you gain a harder one in return...

> The transmitter has to

But these things happen at different layers of the protocol.

The Finished messages are calculated on the handshake layer as carried
by the record layer (IIRC this includes the HandshakeType and length
bytes). Currently it can be implemented by keeping a running hash of the
bytes without actually buffering them in memory. That code shouldn't
need to change at all.

Operations like iterating a list of TAs to find a client cert or
validating a server cert are typically going to be performed at a higher
layer in the code that probably already has similar function defined for
processing those items.

If you needed to calculate a Finished message by retroactively modifying
the handshake data stream, it would be harder. You would have to do
things like fix up length fields (potentially recursing up multiple
layers). That would certainly make introducing new
CachedInformationTypes more disruptive. It would also effectively
require implementations to buffer everything until all substitutions
were resolved.

That's why I think the draft does it the best way.

- Marsh

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 May 2010 23:15:32 +0200

> very positive. We could solve them all in one stroke with

I'm not convinced this is required, but I could live with it.
I would hate to have to add agility and hash negotiation though.

/Stefan

---

From: Marsh Ray <[email-masked]>
Date: Tue, 11 May 2010 17:55:39 -0500

> I would hate to have to add agility and hash negotiation though.

I agree that negotiation of the hash function would be (to put it
mildly) somewhat less than ideal. Really, a successful use of cached
info has only got one shot to work (server hello, client hello).
Negotiating the algorithm at the same time as negotiating the hashed
values sounds like a lot to expect!

If a cryptographically strong hash function turns out to be required, it
ought to follow TLS-1.2's lead and be defined as SHA-256.

> CA who validates to a root trusted by the client.

Keep in mind that some implementations don't actually start validating
the cert chain until the Finished message is received. There's some
logic to this: it hasn't really been proven to have not been "adjusted"
by an attacker until that point anyway and there are good reasons to not
give away precisely at what point the handshake was considered to be a
failure. In practice, it's probably more of a "fits with existing
architecture" decision though.

> If this is the case, then cached info is the least of your problems.

Which is not to say it's not a problem or could never happen.

> to authenticate the attacker as the legitimate server.

What about if the private key were leaked and the cert was subsequently
revoked?

Does this extend then to fully checking against CRLs?

Could oddball types of certs (PSK, static DH, etc) work any differently
in this regard?

Just tossing out questions.

> successfully authenticated. That should remove any residue of this issue.

If "successfully authenticated" is only fully determined sometime after
returning application code, does that mean that this extension should
never come enabled by default for a TLS library?

- Marsh

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 May 2010 23:05:55 +0200

> never come enabled by default for a TLS library?

There is a difference between passing path validation, which is done by the
crypto library, and deciding if the certificate subject is an appropriate
entity, which is done by the application.

In this case I think it is enough that the certificate pass path validation
to a trusted root.

/Stefan

---

From: Marsh Ray <[email-masked]>
Date: Tue, 11 May 2010 22:29:07 -0500

> In this case I think it is enough that the certificate pass path validation

Usually something like that is either critical to the security of the
protocol (and thus needs a cryptographic-strength guarantee) or it's not
(in which case whatever is fine).

I don't see what cert validation directly solves here. After all, the
bad guy can get certs signed, too. Why would it matter if the CN is
different if the CN isn't checked?

In the certificate, the "to-be-signed" tbsCertificate subfield is the
only part directly covered by the signature. Is it possible that an
attacker can modify unused bytes, or append any additional junk in the
part that's not signed? For example, it looks like an RSA signature (RFC
2313 PKCS #1 v 1.5) might admit some nul prefix bytes (it's an integer).
It wouldn't take many modifiable bytes to be able to engineer an
arbitrary FNV-1a value.

Of course the trusted_cas type remains trivially collidable.

- Marsh

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 12 May 2010 11:30:41 +0200

> very positive. We could solve them all in one stroke with

If collision-resistance is a required property (I'm not convinced yet),
I believe we need hash agility for the possibility that SHA-256 is weak.

/Simon

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 12 May 2010 09:26:36 -0500

Simon Josefsson wrote:
> > Alternatively, if we determine that indeed the
> > non-collision-resistance of the hash function is the root of all
> > remaining concerns that would be very positive. We could solve them
> > all in one stroke with s/FNV-1a/SHA-256/g.
> 
> If collision-resistance is a required property (I'm not convinced yet), I
believe we
> need hash agility for the possibility that SHA-256 is weak.

In that case, it would be better to consider a new design that follows the
session ID / server-public-key-id design, where the server provides a
cryptographically secured (by TLS) opaque identifier (format totally
unspecified) for the cached data that the client can then use in subsequent
connections. 

Somebody earlier in this thread made a good point that you rarely need this
caching extension if you make good use of session resumption. I think it may
be much better to consider extensions to session resumption that make it
safe(r) to keep sessions open indefinitely (many weeks/months/years).
Perhaps we just need a new extension that says "use this ticket to create a
session using the same server certificate and/or client cert CA list that
was used when the session ticket was created."

Regards,
Brian

---

From: Marsh Ray <[email-masked]>
Date: Wed, 12 May 2010 09:33:16 -0500

> I believe we need hash agility for the possibility that SHA-256 is weak.

But perhaps that agility already exists in the form of the protocol
version negotiation.

TLS 1.2 appears to effectively depend on SHA-256 (at least in HMAC form)
for the PRF. If that gets broken, we can probably not trust anything
else negotiated in the handshake and a rev of the base protocol will be
required to fix it anyway.

If bare SHA-256 is a concern, the hash could be defined as something
like hmac_sha256("Cached Info", object_bytes).

Just a thought.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 12 May 2010 07:55:01 -0700

Can someone please remind me why we want cached-info?  It seems that
the problems it creates aren't worth the small optimization it might
provide.

Mike

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 12 May 2010 17:05:48 +0200

> the problems it creates aren't worth the small optimization it might

I still have hope we can rescue the extension.  The use-case I have seen
is that server cert chains and list of trusted CAs can easily make a TLS
30-40kb large.  Caching would reduce this.

However, TLS session resume also solves this problem, and it is
relatively easy to implement in most libraries.

/Simon

---

From: Adam Langley <[email-masked]>
Date: Wed, 12 May 2010 11:11:25 -0400

> the problems it creates aren't worth the small optimization it might

In order to support multi-ocsp stapling in the future without
overflowing the initcwnd limit.

AGL

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 12 May 2010 10:47:42 -0500

Adam Langley wrote:
> In order to support multi-ocsp stapling in the future without overflowing the
> initcwnd limit.

I don't think that a caching mechanism based on hashing the OCSP responses is going to be optimal for this. A different caching mechanism that allows the client to ask specifically for only *newer* (not just *different*) OCSP responses would be much better.

Regards,
Brian

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 12 May 2010 08:58:04 -0700

> overflowing the initcwnd limit.

I know what OCSP is, but not the rest.  Even so, shouldn't we wait
until this "future" need exists before we try to optimize it?

Or better yet, design multi-ocsp stapling itself to be optimized
the way you want.

Mike

---

From: Adam Langley <[email-masked]>
Date: Wed, 12 May 2010 11:58:30 -0400

> I don't think that a caching mechanism based on hashing the OCSP responses is going to be optimal for this. A different caching mechanism that allows the client to ask specifically for only *newer*…

The specific case that I'm worried about is a client connecting to a
server for which the previously cached OCSP responses have expired.

As an example, consider a server which returns two certificates: 806
and 807 bytes long. The OCSP responses for these certs are 1085 bytes
long. So the total return is 3783 bytes, not including the overhead of
the ServerHello etc. This is very close to the three packet limit.

AGL

---

From: Marsh Ray <[email-masked]>
Date: Wed, 12 May 2010 11:59:38 -0500

On 5/12/2010 10:05 AM, Simon Josefsson wrote:
>> Can someone please remind me why we want cached-info?

It saves KB++ at the beginning of handshakes, which is a really big deal
for some deployments.

>> It seems that
> I still have hope we can rescue the extension.

Me too. It may be as simple as agreeing on the right hash function (or
the minimally functional subset of the extensible set containing all
negotiable choices).

> The use-case I have seen

The important thing that this _could_ enable, which resumption does not,
is the ability to persist the cached info onto
less-than-perfectly-trusted media. I.e., save it as /tmp files and if
the hard drive is sold on ebay it doesn't represent a disclosure.

Come to think of it, that may be the best argument of all in favor of a
strong hash function: it enables the cache to be kept for arbitrary
lengths of time without special protections or serious security
considerations.

- Marsh

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 12 May 2010 12:01:07 -0500

Adam Langley wrote:
> I don't think that a caching mechanism based on hashing the OCSP responses is
> going to be optimal for this. A different caching mechanism that allows the
> client to ask specifically for only *newer* (not just *different*) OCSP responses
> would be much better.
> 

Yes, I understand. But, just because the server has a different OCSP response, doesn't mean that it's OCSP response is better than the cached one. For example, two responses could have different producedAt times but the same thisUpdate/nextUpdate times. Or, even thisUpdate might be slightly newer, but not enough to make it worthwhile to download it. AFAICT, optimally the client would ask for an OCSP response with thisUpdate >= X, where X is some time significantly later than its cached OCSP response's thisUpdate but before its cached OCSP's responses nextUpdate.

At any rate, I think it would be better to discuss the optimal way of caching OCSP responses first, independent of syntax. Then it would be clear whether this syntax or another one would be best.

Regards,
Brian

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 12 May 2010 13:25:48 -0400

It's not obvious that cache substitution could not be integrated cleanly
into the TLS record layer.  A hypothetical
CompressionMethod.CachedObject algorithm would know nothing about the
specific types of objects being cached, it would just have a
register-object method that creates an equivalence between an opaque
object-id string and an opaque object-content string.

Higher-level code that knows about TAs, certificates, etc would hash the
objects it has cached and register them with the compression algorithm
at application startup, and from that point on the record layer would
match and compress/expand any registered objects encountered in the data
stream (with escaping as necessary).  This should all be invisible to
the handshake layer; I can't think of a reason why it would require
"retroactive" data modification.  It might require modification of the
TLS spec, since currently a compresson algorithm is not permitted to
expand the content length by more than 1024 bytes and the best cached
objects are larger than that.

Of course this is just a napkin sketch; it certainly might turn out to
be impractical to implement.  But I don't see any big impediments yet.

Dave

-----Original Message-----
From: Marsh Ray [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 6:02 PM
To: Kemp, David P.
Cc: [email-masked]
Subject: Re: [TLS] [POSSIBLE SPAM] Re: Collisions (Re: Consensus Call:
FNV vs SHA1)
Importance: Low

A. the values transmitted are perfect equivalents for the values used,
or

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 12 May 2010 10:26:39 -0700

Adam Langley wrote:
 > This is very close to the three packet limit.

What is this three packet limit you speak of?

Mike

---

From: Adam Langley <[email-masked]>
Date: Wed, 12 May 2010 13:33:08 -0400

> What is this three packet limit you speak of?

TCP's initial congestion window is three frames (for now). So a TLS
server which needs more than three frames to send ServerHello through
to ServerHelloDone will have to wait additional round trips for
acknowledgments from the client.

AGL

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 May 2010 12:39:35 -0500

> 30-40kb large.  Caching would reduce this.

If we must keep this extension I say:

 - use HTTP to get them and modify the Finished message computation
   modified to include the objects obtained out of band;

 - the URLs would replace the SHA-1/FNV-1a hashes in the protocol.

> relatively easy to implement in most libraries.

Yes.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 May 2010 12:46:29 -0500

> lengths of time without special protections or serious security

It's not the only solution that does.  I just proposed using URLs to
name cacheable objects.  Objects at any URLs would never change; to
change the object you'd change the URL.

The key to making the protocol secure is to add the cached objects as
extra inputs to the Finished message computation.

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 12 May 2010 10:51:43 -0700

> It saves KB++ at the beginning of handshakes, which is a really big deal

Can you point to some real examples?

3G networks operate at 144kbps, so each KB takes 56 ms to download.
That might be sorta slow, but the rollout of 4G is already taking place
and the speeds will be crazy fast at 100Mbps.

If you're concerned about memory use, consider that the 1st generation
iPod touch had 128 MB of RAM; 3rd gen has 256.  Even old Blackberries
had 64 MB of RAM.

What constrained environments exist today that will still be constrained
once they are upgraded to support this cached-info extension?

Mike

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 May 2010 13:08:14 -0500

> acknowledgments from the client.

I think this argues for using URLs for cacheable objects.

Nico
--

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 12 May 2010 11:22:48 -0700

Would they be https URL's?  Then you would have an infinite-recursion
problem....

Mike

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 May 2010 13:28:28 -0500

> Would they be https URL's?  Then you would have an infinite-recursion

No, why should they be?  The data is public, and integrity protection
would be provided by having the objects be added as inputs to the
Finished message computation.

Nico
--

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 12 May 2010 11:36:27 -0700

> Finished message computation.

Whoa, changing the Finished computation?  I understand that that
would work, but we weren't even willing to do that to solve the
exploitable MITM-thru-renegotiation problem.

Mike

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 May 2010 13:42:57 -0500

> exploitable MITM-thru-renegotiation problem.

Paul Hoffman proposes an extension to add inputs to the Finished message
computation.  There's no objection yet to Paul's proposal on the grounds
you state.

In any case, one of the problems with the caching extension as proposed
result from not binding the cached objects to the Finished message,
which at the very least complicates the security analysis of the
protocol, and possibly compromises it altogether.  We MUST NOT make the
same mistakes we've made before.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Wed, 12 May 2010 22:13:34 +0300

802.15.4 networks operate at 10-40 kbps. A kilobyte takes just under a second at low power, or a quarter second at full power.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Michael D'Errico [[email-masked]]
Sent: Wednesday, May 12, 2010 20:51
To: TLS Mailing List
Subject: Re: [TLS] Justification

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 12 May 2010 12:15:06 -0700

> computation.  There's no objection yet to Paul's proposal on the grounds

Then perhaps it needs to be taken up as a WG item.

> same mistakes we've made before.

Certainly.  I agree that using the hash value in place of the
actual data could be a huge problem.  Putting the actual data
into the Finished computation probably fixes it.  But the need
to do this takes away all the enthusiasm I originally had for
the cached-info optimization.

Mike

---

From: Martin Rex <[email-masked]>
Date: Wed, 12 May 2010 21:41:15 +0200 (MEST)

> I think this argues for using URLs for cacheable objects.

Personally, I strongly dislike this idea, just as much as I dislike
the client-cert-url extension and AIA in X.509v3 certs.
It amounts to out-of-band signaling, which creates a magnitude
larger problems than it solves.

Previously, since the original design conveyed the information only
inband, protected and authenticated with an original TLS session
(I dislike the idea of out-of-band-cache-population), the identification
of the cached data did not need a secure strong agile hash.

If the data is conveyed out-of-band, or even completely unprotected,
then we would have to put the secure strong agile hash over the
*real* data back into the protocol, or it'll be a security problem.

The TCP slow start (result of TCP congestion control) issue is actually
an interesting reminder.  I've seen it affecting the TLS handshake
in a different setup, but don't know the exact details.
There seem to be limits on the number of initial TCP segments as
well that can interact badly with the 200ms delayed ACK in
Windows TCP (at least XP).  I've seen it with a server SSL stack
that did _not_ coalesce the handshake Server->Client handshake messages
ServerHello+Certificate(+ServerKeyExchane+CertificateRequest)+ServerHelloDone
into a single TCP segment.

Is it really about "3 packets" or rather the result of a rather small
"TCP maximum segment size" (MSS) resulting in a fragmentation of the
application write into 2+ TCP segments?

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 12 May 2010 14:46:32 -0500

> computation.  There's no objection yet to Paul's proposal on the grounds

I'm not sure the discussion got that far, so it's not evidence of much.

> same mistakes we've made before.

Agreed, but we should be just as careful not to make new ones.

Sorry if you explained this earlier, but how would the "use URLs"
approach be different than an arbitrary server-chosen identifier?

- Marsh

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 12 May 2010 19:47:57 +0200

IMO, changing the finished calculation is a bad idea.

Its way more complex to implement than using a secure hash function.
Using a secure hash function binds securely the actual data to the finished
calculation.

I'm still not convinced we have a security problem, but no matter that,
using a secure hash is always simpler than changing the finished
calculation.

This is also why I don't like using URLs, since it increase the argument for
changing the finished calculation.

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Wed, 12 May 2010 23:32:06 +0200 (MEST)

Yoav Nir wrote:
> 
> 802.15.4 networks operate at 10-40 kbps. A kilobyte takes just
> under a second at low power, or a quarter second at full power.

There is the theoretical maximum bandwith and there is reality.

When I try to exchanges files between my laptop (XP) and my desktop (XP)
through Remote desktop via 54-bit WLan at home I get only ~250KByte/s.
So I keep plugging an RJ45 cable between the gigabit lan sockets whenever
I need to transfer serious amounts of data (which yields ~7 MByte/s)

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 13 May 2010 10:15:36 +0300

I kind of fail to see where the discussion shifted. In fact we have NOT determined that *malicious* collision resistance is a concern.

A client connects to a server and caches the credentials. Next time it connects to the *same* server, it shows an extension that proves knowledge of the credentials. Assuming the credentials haven't changed, the server can skip sending the credentials, but still has to prove ownership by signing something or by decrypting the pre-master secret. So what could an attacker do?

- It can hijack the connection, and not accept the cached credentials, but then it would need to present credentials of its own. Fail.

- It can hijack the connection, and accept the cached credentials, but assuming it doesn't have the same public/private key pair, it will then not be able to sign or decrypt. If it does have the same public/private key pair, it could use the legitimate server's credentials anyway. Fail again.

- It could get the client to connect to his malicious server first. In some magical way he has acceptable credentials, which the client caches. What happens next is not relevant, because the attacker has already won, but for the sake of argument, let's go on. The next time, the client connects to the legitimate server. It tries to use the cached credentials, which somehow collide with the attackers' even though the public key is different (I don't think we could attack even CRC this way). So the legitimate server accepts the cached credentials, but the handshake fails, and the client clears the cache. 

The third thing seems to succeed, but it depends on being able to predict a CA signature to such an extent, that you can make two certificates with a different public key collide in FNV, and it depends on being able to at least once dupe the client into thinking your server is the legitimate one. And all you get is a one-time DoS.

OK. So where's the real attack?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf of Marsh Ray
Sent: Wednesday, May 12, 2010 5:33 PM
To: Simon Josefsson
Cc: Kemp, David P.; [email-masked]
Subject: Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:

Just a thought.

- Marsh

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 13 May 2010 08:00:53 +0200

Very well put.
This is my thinking as well.

For the sake of completeness there is also the scenario:

- It can hijack the connection as a MITM and try to replace the list of
acceptable CAs to the client with another which somehow has a colliding
hash. This will however lead to handshake failure since finished calculation
will fail and nothing will be cached. Fail.

/Stefan

On 10-05-13 9:15 AM, "Yoav Nir" <[email-masked]> wrote:

> I kind of fail to see where the discussion shifted. In fact we have NOT
> determined that *malicious* collision resistance is a concern.
> 
> A client connects to a server and caches the credentials. Next time it
> connects to the *same* server, it shows an extension that proves knowledge of
> the credentials. Assuming the credentials haven't changed, the server can skip
> sending the credentials, but still has to prove ownership by signing something
> or by decrypting the pre-master secret. So what could an attacker do?
> 
> - It can hijack the connection, and not accept the cached credentials, but
> then it would need to present credentials of its own. Fail.
> 
> - It can hijack the connection, and accept the cached credentials, but
> assuming it doesn't have the same public/private key pair, it will then not be
> able to sign or decrypt. If it does have the same public/private key pair, it
> could use the legitimate server's credentials anyway. Fail again.
> 
> - It could get the client to connect to his malicious server first. In some
> magical way he has acceptable credentials, which the client caches. What
> happens next is not relevant, because the attacker has already won, but for
> the sake of argument, let's go on. The next time, the client connects to the
> legitimate server. It tries to use the cached credentials, which somehow
> collide with the attackers' even though the public key is different (I don't
> think we could attack even CRC this way). So the legitimate server accepts the
> cached credentials, but the handshake fails, and the client clears the cache.
> 
> The third thing seems to succeed, but it depends on being able to predict a CA
> signature to such an extent, that you can make two certificates with a
> different public key collide in FNV, and it depends on being able to at least
> once dupe the client into thinking your server is the legitimate one. And all
> you get is a one-time DoS.
>

---

From: Marsh Ray <[email-masked]>
Date: Thu, 13 May 2010 09:42:23 -0500

On 5/13/2010 2:15 AM, Yoav Nir wrote:
> I kind of fail to see where the discussion shifted. In fact we have
> NOT determined that *malicious* collision resistance is a concern.

I have determined that I am concerned about malicious collisions, until
I get a comfortable feeling that they're not a problem. It's certainly
not anyone else's job to make me feel a certain way, but I hope you
don't mind if I ask a bunch of questions.

We should also keep in mind that the extension only addresses two types
of cached data at this time, but could possibly later include more. If
security analysis needs to based on the particulars of a given cached
item type that should get written down somewhere in the draft.

> A client connects to a server and caches the credentials. Next time
> it connects to the *same* server,

The client may intend to connect to the same server, but we can't assume
it actually *is* connecting to the same server at this point in the
handshake. Proving that it actually is the same server is the #1 goal of
the handshake, and can't be considered a success until the Finished
message is checked.

> it shows an extension that proves
> knowledge of the credentials.

How does it do that?

The extension is sent in-the-clear so it's not a shared secret. I don't
see any signing operation either.

Without collision resistance, attacker may have arranged for the client
to cache something different with the same hash. Client and server may
be using the same hash to talk about different things.

> Assuming the credentials haven't
> changed, the server can skip sending the credentials, but still has
> to prove ownership by signing something or by decrypting the
> pre-master secret. So what could an attacker do?

Are we discussing only the certificate_chain caching right now?

There's also the trusted_cas type and any defined in the future (if in
fact this is a general extensible facility).

- Marsh

---

From: Dean Anderson <[email-masked]>
Date: Thu, 13 May 2010 20:23:33 -0400 (EDT)

I rather thought the objective of caching was to have faster startup by
having to move less data around, particularly when its already been
moved before. But I haven't been following the extension too closely. 

I am only concerned when I see suggestions that 'http be used to get TLS
data. I'm not sure whether to those were serious or tongue-in-cheek.  
HTTP secured by and depends on TLS, so you can't draw on HTTP to solve
HTTP-TLS-HTTP without looping or creating security holes.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 17 May 2010 15:58:08 +0200

I would like to wrap up the discussion about cached info, if possible.

I have to admit that I'm stuck as editor. I have a draft that I think is
done with a possible amendment to the security considerations and some
additional informational references to FNV.

I don't think the discussion has shown that the security assumptions are
wrong, I.e. That any alteration of cached data in the sense that the server
and the client are in disagreement of what the cached data is, will lead to
a handshake failure.

Threats are therefore reduced to inconveniences upon handshake failures (as
far as discussion has showed.

However, there is still a possible alteration of the security properties of
the finished calculation. That is, it is possible upon a FNV collision to
disagree on the cached data without failing the finished calculation.

I can't see any practical exploit of this fact. If this is considered a
blocking problem, then it is easiest solved by using a secure hash (SHA-256)
which effectively restores the security properties of the finished
calculation. This is best done by s/FNV/SHA-256. No agility.

I will not lead an effort to specify a variant of this protocol where the
server provides the identifiers, either as any random identifier or in the
form of a URI. If that is the desire of the WG, I will be happy to hand over
editorship to anyone, assigned by the chairs, who wants to take over.

I request WG chair guidance on how to proceed, if at all with this document.

/Stefan

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 May 2010 09:57:38 -0500

> and the client are in disagreement of what the cached data is, will lead to

If only "any alteration of cached data" in that sense were to lead to
handshake failure, then the protocol would be secure.  The fact that
we've not shown as much means that the protocol is suspect.

We should not be concerned with DoS attacks here because DoS attacks on
handshakes can't be defended against by TLS.  We're concerned with all
other active attacks, and these matter a lot more than DoS attacks.

I believe the only obvious and simple way to prevent such attacks and,
crucially, simplify the security analysis of this protocol, is to bind
the cached objects' data into the handshake, almost as if they'd not
been cached in the first place.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 May 2010 17:17:17 +0200

> been cached in the first place.

+1.  I think this is a good extension for Paul's additional random input
framework.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 May 2010 10:20:12 -0500

> data. I'm not sure whether to those were serious or tongue-in-cheek.  

First, HTTP already is used to get what you might call TLS data, such as
CRLs.

Second, I only want to assign URIs to cacheable TLS data, not so much
make it fetchable via URIs.  This is a variant of my earlier suggestion
of server-side object IDs; this variant can result in efficient caching
of the same objects used by many servers (e.g., certification chains).

> HTTP-TLS-HTTP without looping or creating security holes.

You clearly didn't read what I'd written.  The key problem with this
extension is that the cached objects aren't bound into the handshake.
IMO regardless of how the cached object IDs are obtained, whether by
SHA-1 hashing, FNV-1a hashing, server-assigned IDs, or URIs, the object
data must be bound into the handshake.  Given such binding then it
doesn't matter how you retrieve these objects (which are, for the most
part, public data).

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Mon, 17 May 2010 10:30:36 -0500

> I would like to wrap up the discussion about cached info, if possible.

For the record, I think this could be a really useful extension that
saves huge amounts of aggregate bandwidth and latency in specific
circumstances.

It would be a shame for it to be dropped basically just because of the
lack of obvious choice of a hash function at the current time.

> I can't see any practical exploit of this fact.

Specifically:

1. Bad guy can, without detection, cause the client to consider a
different set of options when selecting a client certificate. He could
cause the client to be unable to select a client certificate when it
should, or cause it to select a different one than it would have. This
is clearly an unanticipated semantic change for application code and may
introduce a vulnerability somewhere.

2. Bad guy can cause a collision to be cached an indefinite length of
time and thus arrange for a failure to occur at some point in a future
handshake, possibly as a drive-by without even being a MitM. Since
recovery from failure requires coordination between the TLS stack and
the application managing the underlying transport, it's impractical for
this WG to gauge the likely success of the reconnect. This represents an
escalation of the attacker's capability over the status quo.

3. Much of this draft is written as if a generic facility is proposed,
yet the security analysis is only addressing the two specific cases. Any
future object types would need their own analysis concerning the lack of
collision resistance, or perhaps they would need yet another mechanism.

> If this is considered a

+1

This also has the effect of "binding the cached objects' data into the
handshake" as Nico had wanted, without modifications to the calculation
of the Finished messages.

- Marsh

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Mon, 17 May 2010 11:33:25 -0400

Stefan,

There is one problem.

If it turns out that you need SHA256 for security reasons - then you'll also
need algorithm agility because nobody can guarantee that SHA256 will hold
(remember - MD4, MD5, SHA1...? :-).

Also, do you care how many bits the hash outputs, and how many of those bits
you use? 

Let's provide the analysis and hope that it shows no security issues here.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 May 2010 10:34:40 -0500

> editorship to anyone, assigned by the chairs, who wants to take over.

I don't care how the cached objects are identified.

It's not clear to me either how collisions in the cached object
checksums can be exploited, but it is clear that the security analysis
of the protocol is much simpler if you bind the cached objects into the
handshake.  Which is why I strongly encourage you to add such a binding
to the protocol.  I may well be alone in this, in which case I'd settle
for a requirement that one be able to disable caching in all
implementations.

If the WG agrees to proceed without adding such a binding, then I'd also
like to see a detailed analysis of possible attacks and why they either
cannot happen or are of no value to the attacker.

Nico
--

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 17 May 2010 17:35:24 +0200

On 10-05-17 5:20 PM, "Nicolas Williams" <[email-masked]> wrote:

> The key problem with this
> data must be bound into the handshake.

How can the cached data NOT be bound to the handshake if they are hashed
with a secure hash which in turn are included in the finished calculation?

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 May 2010 10:43:15 -0500

> I'm not sure the discussion got that far, so it's not evidence of much.

Fair enough.

> Agreed, but we should be just as careful not to make new ones.

How could binding the cached objects into the handshake be a new mistake
given that we bind them in now?

> approach be different than an arbitrary server-chosen identifier?

URIs would be useable across many servers, as opposed to server-assigned
IDs.  But this is not important.

I don't care how the objects are named.  I care only that they be bound
into the handshake.

(Earlier I had thought that we could avoid the SHA-1 vs. FNV-1a issue by
having server-assigned object IDs, however, that was incorrect.  It's
not how we name the objects but how we agree that two peers have the
same cached/cacheable objects that matters.  I'm sorry I even mentioned
server-assigned object IDs.  If I'd thought about it longer I'd have
understood the real problem earlier and avoided this little detour.)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 May 2010 10:51:24 -0500

> with a secure hash which in turn are included in the finished calculation?

They are certainly NOT bound if we use FNV-1a, which is the proposal on
the table.

Plus, if we agree that we need this binding and we want to keep the
current proposal more or less as-is, then we'll need hash agility, which
complicates the protocol.

I'd rather we do something along these lines instead:

 - use FNV-1a (or whatever) to _name_ the objects by checksum;

 - locally hash all the objects' data using the (rather, a) hash
   function used by TLS's Finished message computation and add this hash
   as an input to the Finished message computation:

    - this could be done without modifying the Finished message
      computation by adding a message bearing the hash of all cached
      objects' data to be sent before the first Finished message (then,
      by virtue of being a handshake message, this new message will be
      bound into the Finished messages).

On collision the handshake then fails.  The client should cache
handshake failure information so that on retry it can forgo caching and
then detect collisions.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Mon, 17 May 2010 11:02:43 -0500

> (remember - MD4, MD5, SHA1...? :-).

At some point, you have to trust something. After all, any capability
negotiated in the handshake is only as good as the hash which covers it.
TLS 1.2 seems to trust hmac_SHA256.

If, worst-case, SHA-256 turns out to be completely broken, the world
could switch to a stronger scheme for generating those 256 bits
relatively easily.

> Also, do you care how many bits the hash outputs, and how many of
> those bits you use?

I think that's probably the more important thing to fix in the spec.
It's probably a bit easier (should the unfortunate need arise) for
existing implementations to use a different hash of the same width than
it is to change the width of protocol elements.

> Let's provide the analysis and hope that it shows no security issues here.

We don't have to use SHA-256, but it sounds to me like the easiest
choice to explain (and thus get agreement on).

A quick glance at Wikipedia
http://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions
lists the only attack against SHA-256 to be against an egregiously
weakened (24 instead of 64 rounds) variant.

- Marsh

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 17 May 2010 09:29:44 -0700

I agree with Uri, that if you determine you need SHA-256 then you should
plan for hash agility.  TLS 1.2 plans for hash agility.  

What about Nico's proposal where a checksum is used to identify the
cached data and the actual handshake contains the actual data hashed
with the algorithm used in the PRF negotiated with the cipher suite? 

This way we don't have to introduce hash agility into the extension, but
we have cryptographic hash agility where it matters in the Finished
computation.  Does it solve the problem?  

Joe

> Sent: Monday, May 17, 2010 9:03 AM
> To: Blumenthal, Uri - 0668 - MITLL
> Cc: [email-masked]
> Subject: Re: [TLS] Wrapping up cached info
> 
> > If it turns out that you need SHA256 for security reasons - then
you'll
> also

---

From: Marsh Ray <[email-masked]>
Date: Mon, 17 May 2010 12:02:55 -0500

> computation.  Does it solve the problem?  

It could perhaps be made to solve the problem, but IMHO it would require
so much additional complexity (aka attack surface) that it wouldn't be
worth it.

While I don't like to reject anything out-of-hand, injecting data into
the calculation of the Finished messages raises a lot of concerns. The
way it currently works (the data interpreted logically is just the bytes
as seen in the hanshake records) has a certain elegant simplicity that
would be a shame to lose. The consequence of the loss of integrity in
the calculation of the Finished messages is pretty much a complete
compromise of the security.

For example, how will the injected data be wrapped? (It must be
delimited somehow or ambiguities may be possible). If they are replaced
as in-line substitutions will lengths of enclosing objects be fixed up?
If there are multiple substitutions, in what order will the replacements
be injected? For an attacker who can efficiently create checksum
collisions does it make any precomputed attacks easier? Will this
require changes in any commonly used APIs (PKCS#11, Schannel, etc)?

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 May 2010 12:08:10 -0500

> so much additional complexity (aka attack surface) that it wouldn't be

Really?  It'd be a single extra message consisting of the hash of all
the objects' data, concatenated in some canonical order (or maybe the
hash of the XOR of the object data hashes, to avoid having to define a
canonical order), that the first node to sent a Finished message would
have to send, and which the other node would have to check.  Where's all
that additional complexity, and how does it compare with the complexity
of the protocol's security analysis as it stands now?

> While I don't like to reject anything out-of-hand, injecting data into

But you just did.

> the calculation of the Finished messages raises a lot of concerns. The

You mis-read.  Re-read.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 17 May 2010 18:17:37 +0100

> of the protocol's security analysis as it stands now?

This is, of course, equivalent to using the hashes as identifiers in the
first place :-)

Why is agility a problem, though - could we not say that any hash that is
currently required as a signature hash can be used, and identify the hash in
the extension message?

---

From: Ben Laurie <[email-masked]>
Date: Mon, 17 May 2010 18:17:37 +0100

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 May 2010 12:27:36 -0500

On Mon, May 17, 2010 at 06:17:37PM +0100, Ben Laurie wrote:
> > ...

Almost!  Using the object ID hashes for this before we negotiate a hash
function creates a hash agility issue.  There's also the problem that
using secure hashes to ID the objects means using up more bits on the
wire, as Uri points out.  There's also the problem that if the client
and server disagree as to what hash to use to ID cacheable objects then
objects aren't cached at all.

If we do it the way I propose we: a) don't have to think about agility,
b) don't have to think too much about security analysis, c) never have
to change the hash function we use for naming objects (unless FNV proves
to be deeply unsatisfying), d) barely change the protocol (though the
changes to implementations are somewhat larger).

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Mon, 17 May 2010 12:50:20 -0500

> of the protocol's security analysis as it stands now?

Try this: write up that "single extra message" in unambiguous RFC form.
The protocol message definition, the canonical order, server behavior,
client behavior, how to require per-server client caches when the server
hasn't yet been authenticated, etc. Security considerations for future
cached object types. Consider writing code to implement it including
test cases with actual checksum collisions.

Then put after it "... or we could just use a collision resistant hash
function."

>> While I don't like to reject anything out-of-hand, injecting data into

Sorry if it sounds that way. I didn't reject it, I said "It could
perhaps be made to solve the problem" and asked a bunch of pointed, but
answerable, questions. This is my way of saying that I could accept the
idea and inviting others to overcome those objections.

If I'd really wanted to reject it, I would have made just one
unanswerable objection like "I spoke to secret government cryptographers
who will not go on record and they said it was insecure" (again, this
did not happen just an example).

>> the calculation of the Finished messages raises a lot of concerns. The

Which part? I don't get it.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Mon, 17 May 2010 13:14:56 -0500

> currently required as a signature hash can be used, and identify the hash in

Sure we could, but is it worth the cost?

Client Hello and Server Hello offer one shot to negotiate the use of
caching and the identifiers being used. Having it also negotiate the
hash algorithm at the same time raises the difficulty a bit!

As I see it, here are some challenges raised by hash agility:

1. TLS implementations will have to implement all the schemes or risk
interoperability issues or at least missed caching opportunities.

2. Probably just one scheme will be used in practice anyway. It's likely
not to be the most secure of the defined choices. The other schemes may
get little testing.

3. Clients and servers will be required to maintain multiple hashes for
every cacheable object.

4. Clients will likely have to send multiple hash formats until it sees
what kinds the specific target server can work with.

5. The "cross-hashfn collision" attack must now be considered. E.g. a
preimage of one hash fn could collide with a value from another, unless
the algorithm id is somehow incorporated into the hash value itself.

6. Bad guy may be able to influence client and server to use his choice
of hash functions for caching. He could inject phony failures for
example. This could create a "weakest link" situation where the attacker
can choose the weakest hash function among all supported alternatives.

All in all, good clean fun. :-) I just don't want a reflexive "gotta
have agility" to make the proposal inelegant and unwieldy so it has
trouble gaining widespread acceptance.

- Marsh

---

From: Ben Laurie <[email-masked]>
Date: Mon, 17 May 2010 19:29:46 +0100

> hash algorithm at the same time raises the difficulty a bit!

I am not suggesting negotiation, I am suggesting a statement. Since the hash
is already required elsewhere in the protocol, there is no need to
negotiate.

---

From: Martin Rex <[email-masked]>
Date: Mon, 17 May 2010 21:16:01 +0200 (MEST)

> computation.  Does it solve the problem?  

Yes, I think so.
This approach should solve the issue at the technical level.

Going more into detail, one would hash/mac only the data that got
actually replaced in the handshake, each prefixed by a (locally computed)
length field.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 17 May 2010 12:21:05 -0700

It just hit me that we might be able to do caching in a different
way, similar to the http If-Modified-Since header (and ETag -- see
the last paragraph).

The server would keep track of the time at which its certificate
chain (or CA list) was configured.  This could be determined by
looking at the modification time in the filesystem, or even just
by keeping track of when the server was started or was told to
reconfigure itself.

A connecting client would tell the server, "I have a certificate
chain with this timestamp," and the server would either respond
saying that the timestamp matches the current chain, or not.  If
it matched, the certificate message sent by the server would be
empty.

A client that has never connected to a server would request the
server's timestamps by sending an empty extension.  The server
would respond with the current type/timestamp pairs it supports.

When reconnecting, the client lists its type/timestamp pairs and
the server responds with its list.  Any timestamps that matched
would cause the server to omit the data.

But probably we'd also need to have id's for the objects similar
to the ETag header to disambiguate things, especially when the
server handles more than one virtual domain.  The server could
generate those either using a hash (no agility needed) or some
other way, with the only requirement being that the type-id-
timestamp triple would need to be unique.

Mike

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 17 May 2010 15:45:19 -0400

>> [Nico] Paul Hoffman proposes an extension to add inputs to the
Finished 
>> message computation.  There's no objection yet to Paul's proposal on 
>> the grounds you state.
>
> [Marsh] I'm not sure the discussion got that far, so it's not evidence
of much.

Was this a verbal proposal?  Paul has submitted the following I-Ds:

draft-hoffman-tls-additional-random-ext-01  -- Additional Random
Extension to TLS
draft-hoffman-tls-master-secret-input-01    -- Additional Master Secret
Inputs for TLS

but nothing that would add inputs to the Finished computation other than
what was actually transmitted over the wire.

I agree with using a checksum to identify the cached data while
including the actual data in the finished calculation.   I don't see any
mechanism for doing that using either of the Hoffman drafts, but I still
think it could be done in a relatively straightforward manner by
defining a "CachedObject" compression algorithm that would "compress"
and "expand" by direct substitution of checksums for data.

----------

And on a different topic, What is This Function?

RFC 5246 section 4.3 defines the notation for two types of vectors:
  Fixed length:     T T'[n];
  Variable length:  T T'<floor..ceiling>;

and section 7.4.9 defines the structure of the Finished message:

      struct {
          opaque verify_data[verify_data_length];
      } Finished;

      verify_data
         PRF(master_secret, finished_label, Hash(handshake_messages))
            [0..verify_data_length-1];

What sort of notation is a function PRF() followed by a floor and
ceiling expression enclosed in square brackets []?

Assuming it means that the PRF output is truncated to some variable
number of bytes, why is the floor 0 bytes and the ceiling 11 bytes when
all verify_data vectors MUST be either exactly 12 (current ciphersuites)
or at least 12 (future ciphersuites) bytes???

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joseph Salowey (jsalowey)
Sent: Monday, May 17, 2010 12:30 PM
To: Marsh Ray; Blumenthal, Uri - 0668 - MITLL
Cc: [email-masked]
Subject: Re: [TLS] Wrapping up cached info

Joe

---

From: Martin Rex <[email-masked]>
Date: Mon, 17 May 2010 22:18:22 +0200 (MEST)

> ceiling expression enclosed in square brackets []?

The output of the PRF() is substantially larger than the size
of the finished message.  The notation is probbly meant to
refer to the initial verify_data_length octets from the
opaque result of PRF().

The "verify_data" vector in the finished message has a fixed size,
which means that it is encoded without a seperate length field.

But since the verify_data is also the only content of the finished
handshake message, the size of verify_data is the same as the
sized handshake message body given in the handshake message header.

> or at least 12 (future ciphersuites) bytes???

The existing spec does not allow verify_data to be of variable size.
(variable size objects would require an additional length field
 preceding the value).

verify_data must always be fixed size, but that fixed size can be defined
in the specification of a cipher suite to be larger than 12 octets.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 17 May 2010 22:34:39 +0200

Guys,

Where I come from we have a say "don't cross the river to get to the water".
And to me this proposal to change the finished calculation is just that.

Look at it.

The proposal is to bind the cached data by adding a hash of the cached data
to the finished calculation.

The proposal is further to avoid hash agility by picking the hash algorithm
used by TLS's Finished message computation.

Now there are two ways to achieve this goal.

1) The crossing the river to get water approach:  Exchange FNV hashes of the
cached data in the handshake protocol exchange and then inject hashes of the
same data into the finished calculation through an alteration of the TLS
protocol.

2) The simple approach: Use the hash algorithm of the finished calculation
to hash the cached data (according to the current draft).

Alternative 2 securely bind the hashed data into the finished message
calculation without altering the algorithm.

Alternative 2 requires at most a hash algorithm identifier added to the
protocol, if at all. We don't need to add negotiation since we always use
the hash of the finished message calculation. Adding this identifier would
be the only change made to the current draft.

Alternative 2 don't require additional security analysis. If the hash used
to calculate the finished message is broken, then we are screwed anyway.

/Stefan

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 May 2010 15:44:09 -0500

> draft-hoffman-tls-master-secret-input-01    -- Additional Master Secret

draft-hoffman-tls-master-secret-input-01.

> what was actually transmitted over the wire.

It changes the computation of the master secret, therefore it changes
the computation of the Finished message.

But none of that matters now because IMO the simplest fix here is to add
a handshake message that has a cryptographic hash of all the cached
objects' data -- or something along those lines.

Nico
--

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 18 May 2010 00:24:06 +0200

As Martin pointed out to me privately, the hash used in the finished
calculation becomes known to the client only after receiving the serer
hello.

It would therefore be natural for the client to use the hash function used
to calculate the finished message at the time when the data was cached.

The client would then indicate which hash algorithm it used and upon
acceptance, the server will honor the request.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 19 May 2010 15:42:37 +0200

Not sure how I should interpret the silence?

I guess it means that everyone agrees with me :)

To repeat in short. Here is what I suggest based on the latest traffic:

1) A client, caching information also caches what hash algorithm was used to
calculate the finished message at the time of caching.

2) On repeated connections, the client indicate cached info by sending a
hash of the cached object using the cached hash algorithm. (No use of FNV
hash)

3) The server accepts by returning the received hash instead of the cached
data.

4) The only hash agility provided is that the client will send a hash
algorithm identifier with the hash.

5) The client MUST NOT send more than one hash per cached object, and MUST
used the cached hash algorithm.

This solves all issues raised (securely binds the cached data to the
finished calculation) and removes the need for hash agility
Syntactically it just requires adding a hash identifier and adjusting the
vector length for hash data.

So I basically wander:
- Would this be acceptable?
- Who could NOT live with this solution?
- Who think it is worth the effort to agree on a better solution, and why?

Regards

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 19 May 2010 07:19:00 -0700

Hi Stefan,

To me this sounds like a good approach.  I have some questions on
whether the hash chosen is dependent upon the cipher suite used below.

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Wednesday, May 19, 2010 6:43 AM
> To: Stefan Santesson; [email-masked]; Joseph Salowey (jsalowey)
> Cc: [email-masked]
> 1) A client, caching information also caches what hash algorithm was
used
> to
[Joe] Will this be the same as the hash function used in the PRF of the
cipher suite?  It seems that using the same hash might make security
analysis a little easier. 

> 3) The server accepts by returning the received hash instead of the
cached
[Joe] In the event that a different cipher suite is used with a
different hash would the cached hash still be valid?  

> algorithm identifier with the hash.
[Joe] This seems sufficient. 

> > It would therefore be natural for the client to use the hash
function
> used
> >> Where I come from we have a say "don't cross the river to get to
the
> water".
> >> The proposal is to bind the cached data by adding a hash of the
cached
> data
> >> 1) The crossing the river to get water approach:  Exchange FNV
hashes
> of the
> >> cached data in the handshake protocol exchange and then inject
hashes
> of the
> >> same data into the finished calculation through an alteration of
the
> TLS
> >> protocol, if at all. We don't need to add negotiation since we
always
> use
> >> the hash of the finished message calculation. Adding this
identifier
> would
> >> Alternative 2 don't require additional security analysis. If the
hash
> used
> >>>> This way we don't have to introduce hash agility into the
extension,
> but

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 19 May 2010 16:32:00 +0200

The thought is that you would apply the same rules as you do when choosing
hah for the finished calculation.

To the extent that choice is dependent on the prf, then choice of this hash
will also be dependent on the prf.

There is no reason to chose any different hash algorithm than the one used
for the finished calculation since the security aspects of this is tied to
the finished calculation anyway. That is, you can't do better than the hash
of the finished calculation, and if you pick the same hash, you can't do
worse. Analysis is therefore easy.

Since the hash chosen to calculate the finished message is known only after
receiving the server hello, the client have to choose the one used on a
previous handshake, i.e. The one when the data was cached.

Yes, I think it would be OK for the server to not accept the choice of a
hash algorithm if it is less secure than the one used in the finished
calculation, but I see no reason to demand it. It could be left to the
server to decide based on local policy, but I would not object to require
the server to reject the cached data if that is the general preference.

/Stefan

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 19 May 2010 08:02:52 -0700

> I guess it means that everyone agrees with me :)

Then by that logic everyone also agrees with me to use http caching
as the model!

Seriously, I think that the current draft might be too simple.  For
example, consider caching the list of certificate_authorities in a
CertificateRequest message.  A web application might have several
different lists of certificate_authorities based on what the resource
is and who is trying to access it.  If cached-info can only cache one
object of any particular type, then it will not be very helpful for
such an application.

Also, exactly how would you hash the Diffie-Hellman parameters in a
ServerKeyExchange message?  You can't just hash the message since it
also contains a unique Ys which changes frequently if not every
handshake.

Allowing the server to instead name the objects, and keep track of
timestamps for each object, allows you to handle these two cases.  In
the multiple-CA-list example above, the server might have USER and
ADMIN lists.  If it can't be sure when exactly those lists were
created, the timestamp can simply be when the server was started or
when it last read its configuration.

When the server forces the client to renegotiate when accessing a
protected resource as an ADMIN for example, the server's cached info
extension would contain:

     type=cert_req_ca_list,name=ADMIN,timestamp=20100519123456789

When requesting a less-sensitive, but not public resource, the server
would send:

     type=cert_req_ca_list,name=USER,timestamp=20100519123456789

If the client's cached-info extension contained an exact match, then
the server would omit that data from the handshake.

This is sort of like cipher suite selection.  The client sends a list
of possible matches and the server selects one from the list.  It
differs in that there might be no match, in which case the server just
sends the info for the object it decided to send in the handshake.

I'm sure there are more details to be worked out, but I think it would
be a good idea to entertain this approach.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Wed, 19 May 2010 11:01:18 -0500

> Then by that logic everyone also agrees with me to use http caching

Then by that logic, everyone agrees with everyone. Problem solved!

HTTP caching:
http://tools.ietf.org/html/rfc2616#section-13

> Seriously, I think that the current draft might be too simple.

I am more concerned that it will become too complex!

> For
> is and who is trying to access it.

Web servers can certainly be configured that way.

> If cached-info can only cache one

Can we agree on the explicit non-requirement that the solution must work
for everything?

> also contains a unique Ys which changes frequently if not every

Should we even try?

> timestamps for each object, allows you to handle these two cases.

Go read the specs and mailing lists for HTTP caching. (I bet you have
already :-)

Having names, timestamps, invalidation rules, etc can introduce a little
bit of complexity.

http://www.google.com/search?q=squid+cache+weird+problem
http://www.google.com/search?q=squid+cache+strange+problem

> In

Does this introduce a new requirement for clients and/or servers to
maintain an accurate clock?

What failure modes are possible when a clock is not accurate?

- Marsh

>> used to
>>>> cached data
>>>> hashes of the
>>>> hashes of the
>>>> always use
>>>> hash used
>>>>>> extension, but

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 19 May 2010 09:17:43 -0700

If there was a short discussion of this in the document, I'd be happy
with this approach.  

Joe

> Sent: Wednesday, May 19, 2010 7:32 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> Cc: [email-masked]
> >> 2) On repeated connections, the client indicate cached info by
sending
> > a
> >> hash of the cached object using the cached hash algorithm. (No use
of
> > FNV
> >> 5) The client MUST NOT send more than one hash per cached object,
and
> > MUST
> >> Syntactically it just requires adding a hash identifier and
adjusting
> >> - Who think it is worth the effort to agree on a better solution,
and
> > why?
> >>>> And to me this proposal to change the finished calculation is
just
> >> that.
> >>>> Alternative 2 requires at most a hash algorithm identifier added
to
> >>>>>> I agree with Uri, that if you determine you need SHA-256 then
you
> >> should

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 19 May 2010 09:21:25 -0700

This approach seems equivalent to the server assigns name approach that
has been brought up several times previously and not received enough
support to replace the current mechanism.  In addition, it doesn't seem
to solve the issue of how to hash the objects that the working group is
currently struggling with.  

Joe

> Michael D'Errico
> Sent: Wednesday, May 19, 2010 8:03 AM
> To: Stefan Santesson
> Cc: [email-masked]
sending a
of
and
adjusting
and
function
the
cached
hashes
hashes
the
to
always
identifier
hash
you
extension,

---

From: Marsh Ray <[email-masked]>
Date: Wed, 19 May 2010 11:48:30 -0500

> currently struggling with.  

One option is to put off this proposal pending the results of the NIST
SHA-3 selection process.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 May 2010 11:52:27 -0500

> whether the hash chosen is dependent upon the cipher suite used below.

I agree, this works for me, provided the hashes are not truncated.
("This" == the client caches the choice of hash function and uses that
in its hello; if the hash function changes then the client cannot cache
that one time, but can cache subsequently.)

Nico
--

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 19 May 2010 19:23:01 +0200

I agree. I would rather not truncate the hash.

I will, provided that this seems acceptable still in a few days from now,
write up a new draft that captures the changes which then hopefully can be
ready for a WGLC.

/Stefan

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 19 May 2010 10:26:01 -0700

It is better than server-assigns-name because a server doesn't
need to keep track of names in stable storage if that's not
convenient for it.  It can instead create a convenient name (which
doesn't even need to be a hash of the object) and use the time at
which the server was launched as the timestamp.

The combination of name and timestamp provides a lot of flexibility
for the server since it could use a unique name for something, e.g.
MODP-1536 for the 1536-bit IKE DH parameters, or a combination of a
name and a timestamp.  The timestamp could be based off of the file
modification time of a certificate for instance.  Or the server can
just use the time it last loaded its configuration as the timestamp
to avoid any possible clashes with previous names.

Also there is no need for hashing at all and thus no hash agility.
I think that alone makes this worth considering.

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 19 May 2010 10:34:29 -0700

Marsh Ray wrote:
>> I think that the current draft might be too simple.
> 

I think avoiding any need for hashing and hash agility is worth it.

> Can we agree on the explicit non-requirement that the solution must work

Sure, but if we end up with something that works for everything,
that's not a bad thing.

>> also contains a unique Ys which changes frequently if not every

We might get it for free.

> maintain an accurate clock?

Not a new requirement.  Think certificate validity periods.

> What failure modes are possible when a clock is not accurate?

You might consider an expired certificate as valid?

With the timestamp approach, it would require an exact-match,
otherwise the items would be considered different.  An attacker
would have to be able to stop a server, change the time, and
restart it, all to get a cached datum to collide.  Wouldn't you
have much bigger problems than that?

Mike

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 19 May 2010 13:43:52 -0400

This will work as long as there is high "cache reuse ratio", i.e.,
repeated handshakes with a server will not result in many cached objects
of any type.

If multiple handshakes with a server could cache different objects of a
given type, then the list in step 2 (client sends hash value of every
object it has collected) could get very large and a more traditional
cache miss approach would be needed.

The FNV collision discussion brought up cases where more than one cached
object could be valid.  The same cases should be considered in
estimating how long the list of cached objects might become.  If
collisions in a 64 bit checksum are a real concern, that list could
potentially be enormous.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicolas Williams
Sent: Wednesday, May 19, 2010 12:52 PM
To: Joseph Salowey (jsalowey)
Cc: [email-masked]
Subject: Re: [TLS] Wrapping up cached info

On Wed, May 19, 2010 at 07:19:00AM -0700, Joseph Salowey (jsalowey)

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 May 2010 12:58:25 -0500

> repeated handshakes with a server will not result in many cached objects

I think this is very likely.

> cache miss approach would be needed.

I think this is unlikely.  I'm not sure how one might design an
extension to provide for caching that can handle this possibility
without adding round-trips to the handshake and without using HTTP (or
some such protocol) to fetch cacheable items.  The no-extra-round-trips
constraint is almost certainly non-negotiable.  Downloading cacheable
items out of band would greatly complicate implementations and would
introduce more failure points.

You might demand real-world data on cacheability and predictability of
caching opportunities.  But I think it should be fairly obvious that: a)
the items in question change infrequently, b) the handshakes between any
one {client, server} pair will generally all look the same, with very
few variations (initial vs. session resumption, outer handshake vs.
inner re-negotiation).  Moreover, clients could observe that use of this
extension provides no benefit and cache that to avoid using it
subsequently (much like rsync, the client could compute a "speedup"
ratio of data that would have been transfered to data actually
transfered).

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 20 May 2010 07:42:03 +0300

In my case the silence means a national holiday.

I still don't see why we need a secure cryptographic hash there as well. There has still not been any outline of an attack even in the presence of collisions.

Given this, I don't see any reason to move away from FNV-1a.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Wednesday, May 19, 2010 4:43 PM
To: Stefan Santesson; [email-masked]; Joseph Salowey
Cc: [email-masked]
Subject: Re: [TLS] Wrapping up cached info

So I basically wander:

Regards

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 May 2010 11:21:32 -0500

On Thu, May 20, 2010 at 07:42:03AM +0300, Yoav Nir wrote:
> I still don't see why we need a secure cryptographic hash there as
> well. There has still not been any outline of an attack even in the
> presence of collisions.

I'd rather use a more conservative procedure.  Given a lack of
cryptographic protection of relevant protocol elements, it should be the
proponents' job to provide the analysis showing that the missing
protection does not create security problems.  Such an approach will
result in more conservative protocol designs, but also it will result in
lower review burden for reviewers.  Reviewer resources are finite;
making efficient use of them is important.

Providing unnecessary protection to such protocol elements is generally
harmless from a security point of view (always, if we ignore traffic
analysis issues, which we do in this context).  While not providing
necessary protection to such protocol elements is a sure way to get into
trouble.

The burden of analysis may shift onto reviewers when a conservative
protocol design presents significant performance or complexity
trade-offs.  In this case we seem to have settled on a design (proposed
by Stefan) that does not impose significant performance nor complexity
costs and which does provide the cryptographic protection that some
reviewers (yours truly included) have requested.  Sounds like a win-win
to me.

Nico
--

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 May 2010 17:39:55 +0100

> reviewers (yours truly included) have requested.  Sounds like a win-win

+1.

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 23 May 2010 16:40:41 -0500

> write up a new draft that captures the changes which then hopefully can be

There's another issue still. If the server sends the client an information
item X after the change cipher suite message, then the client must not send
a hash of that information item in its client hello message on another
connection, until it has verified the identity of the server on that second
connection. In other words, the client must ensure that it doesn't leak
information that would otherwise be confidential--including even certificate
messages and client certificate cipher suite messages that were received
over an encrypted connection.

Regards,
Brian

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 24 May 2010 07:22:56 +0200

Could you explain why?
What is the attack scenario?

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Tue, 25 May 2010 15:46:57 +0200 (MEST)

> over an encrypted connection.

I think that should be described in the Security Considerations that
a client or client&server that perform renegotiation for the purpose
of client identity protection may want to tag their cached values
so that when that value was established on an encrypted handshake,
it is not going to be proposed by the client on a successor
plaintext handshake.

-Martin

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 27 May 2010 10:38:09 -0500

> it is not going to be proposed by the client on a successor

How would the server indicate this to the client?

Regards,
Brian

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 27 May 2010 10:47:17 -0500

Yes.

> How would the server indicate this to the client?

There's no need for the server to indicate anything to the client here.

If a client wouldn't attempt user authentication w/o re-negotiation then
it shouldn't send a hash of its user cert / cert chain in the initial
handshake.  If a server considers user cert TAs to be confidential
(highly unlikely, but let's suppose) then the server shouldn't list
their hashes in initial handshakes.  It's that simple.

Nico
--

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 27 May 2010 17:59:57 +0200

I will try to provide a revised draft next week, incorporating the "agreed"
changes.

/Stefan

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 27 May 2010 11:02:29 -0500

> What is the attack scenario?

Here are some issues I have come up with regarding this extension:

1. If the server went through the trouble of establishing a secure channel
before sending an information item, then doesn't that mean that the server
wants that information item to be kept confidential? If the client sends an
unencrypted hash of a confidential information item to the server, then it
creates an opportunity for known-plaintext attacks on that information item.
In particular, this would negatively affect any server that authenticates
the client and then renegotiates with its "real" certificate and/or other
handshake information.

2. Let's say you go to site A and cache site A's cert list. Then you send a
hash of that to site B. Then, site B can use that hash to recognize that the
user has previously been to site A. This if an information leak very similar
to the HTTP referrer header. For this reason, clients must be careful not to
send a hash of an information item to any site other than the one that sent
it to them. But this creates a problem, since the client hello happens
before authentication. This is worse than TLS session IDs and TLS session
tickets because both of the TLS session resumption mechanisms can be done in
such a way that it is impossible to map a session ID/ticket to the source
server.
 
3. Let's say that a server generates a unique trusted CA list record for
every new session. Then the client's hash of the trusted CA list will act
like a HTTP cookie, much like TLS session IDs and tickets. Clients will have
to ensure that they clear their cached info cache similarly to the way they
clear HTTP cookie caches and TLS session caches.

Regards,
Brian

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 27 May 2010 11:10:21 -0500

> their hashes in initial handshakes.  It's that simple.

AFAICT, that wouldn't stop a compliant (to the current draft) client from
sending the hashes. Even if the server previously indicated that it didn't
support the extension and/or didn't support caching certain information
items, a complaint (to the current draft) client is still allowed to send
those hashes:

     A cached_information extension provided in the server hello has the
     following semantics:

     o An empty cached_information extension indicates that the server
       supports information caching but provides no information about
       what information types it supports.

     o A non-empty cached information extension indicates that the
       server supports only those CachedInformationType types that are
       identified by each present CachedObject.

     o A CachedObject with an empty digest_value indicates that the
       server supports caching of the specified object type
       (CachedInformationType), but does not specify any digest values
       it will accept.

Regards,
Brian

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 27 May 2010 11:16:45 -0500

> items, a complaint (to the current draft) client is still allowed to send

The client can do stupid things, of course.  The point is to have text
that says "the client MUST NOT" do stupid things.

Neither the client nor the server should send all their cached hashes on
initial handshakes.  For one, that could be an enormous amount of
useless data.  Only possibly-relevant cached object hashes should be
exchanged.  The "possibly-relevant" part includes the consideration of
whether a cached object is relevant to initial vs. re-negotiation
handshakes.  I don't think we need to change the protocol to get this
right; at most we'll need to add text about this.

Nico
--