Hi,
Stefan,
I support the
idea and like the benefit of not transporting Certs.
The drafts
looks good and clear to me, except that I get some questions
regarding the following part in section 4:
Servers that receive an extended
client hello containing a
"cached_information" extension, MAY
indicate that they support one or
more of the cached
information objects by including an extension of
type
"cached_information" in the (extended) server hello, which
SHALL
contain at least one CachedObject received from the
client. The
CachedObject's returned by the server MUST include
the types the
server supports and has accepted to replace with
a hash of the cached
data.
It gives me impression that server's reply can
include items that is beyond cached items which
clients provide. Is it possible (or leagal)
for clients to use those items which he did not
mentioned but were indicated usable by server?
For example clients provides items {A, B}, server replied {B, C}.
B
has been confirmed by both sides, C is confirmed only by Server. If B and C
are both acceptable,
but the two negotiation base are not quite
same, will there be a problem ? Not quite sure it would
cause trouble or not though, but wondering
whether it will.
For example, since hello message are not crypto protected
yet, is it possible for a man-in-middle to
let clients accept expired certs or fake
CAs?
Sean
I have finally incorporated the agreed changes to
what previously was called the cached certs extension, now changed to the
cached information extension, and submitted the first (00) TLS
draft.
The draft is available from the following staging URL until
it’s made available as a TLS draft.
http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-00.txt
I
hope I didn’t miss any agreed changes.
/Stefan
