Re: [TLS] FWD: First TLS cached information draft posted

[Sean Shen <sshen at huawei.com>]

> > 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.
> 
> Good point.  I don't see how that could work -- how would the 
> server know whether the client supported C?  The client needs 
> to understand C in order to parse the handshake properly.

Right, this is another reason that replying extra items beyond client's
proposal is not a good idea.
So I suggest that server should only reply with items chosen from client's
proposal, the current wording in the draft does allow that happens.

Sean