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

sorry, made a mistake in previous message, I was trying to say:

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

Sean

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On 
> Behalf Of Sean Shen
> Sent: Tuesday, June 09, 2009 5:02 PM
> To: 'Simon Josefsson'
> Cc: TLS@ietf.org
> Subject: Re: [TLS] FWD: First TLS cached information draft posted
> 
> 
> > > 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
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls