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

From: Sean Shen <[email-masked]>
Date: Tue, 09 Jun 2009 08:58:13 +0800

It looks this message was not sent out successfully, have to try it again.

  _____  

发件人: Sean Shen [mailto:[email-masked]] 
发送时间: 2009年6月8日 12:08
收件人: 'Stefan Santesson'; 'TLS wg'
主题: 答复: [TLS] 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.
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

  _____  

发件人: [email-masked] [mailto:[email-masked]] 代表 Stefan
Santesson
发送时间: 2009年6月5日 1:41
收件人: TLS wg
主题: [TLS] First TLS cached information draft posted

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

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 09 Jun 2009 08:26:55 +0200

> 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.

/Simon

---

From: Sean Shen <[email-masked]>
Date: Tue, 09 Jun 2009 17:02:19 +0800

> > The drafts looks good and clear to me, except that I get some 
> > questions regarding the following part in section 4:
> >  
> > 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?
> > 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
> 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

---

From: Sean Shen <[email-masked]>
Date: Tue, 09 Jun 2009 17:17:49 +0800

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