At Mon, 30 Nov 2009 10:31:35 -0600,
Marsh Ray wrote:
> 
> A few little suggestions, mostly wording.
> 
> The IESG wrote:
> > The IESG has received a request from the Transport Layer Security WG 
> > (tls) to consider the following document:
> > 
> > - 'Transport Layer Security (TLS) Renegotiation Indication Extension '
> >    <draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard
> 
> http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01
> 
> [Page 3]
> >    renegotiation handshakes to the enclosing TLS channel, thus allowing
> >    the server to differentiate renegotiation from initial negotiation,
> >    as well as preventing renegotiations from being spliced in between
> >    connections.  
> 
> "spliced in between sessions."

Hmm... I'm not sure that's quite what we want either. Maybe 
"between transport layer connections"?


> [Page 5]
> >    o  For ClientHellos which are renegotiating, this field contains the
> 
> "the renegotiated_connection field contains"

Agreed.


> >    Note that a minimal client which does not support renegotiation at
> >    all can simply use this cipher suite in all initial handshakes.  Any
> >    compliant server will reject any (apparent) attempt at renegotiation
> >    by such a client.  Clients which do support renegotiation MUST
> >    implement Section 3 as well.
> 
> I suggest we replace all uses of "cipher suite" in this section with the
> term "cipher suite value", and we add explicit wording "The
> TLS_RENEGO_PROTECTION_REQUEST cipher suite value is just a flag, it does
> not actually a refer to a set of cryptographic algorithms that could
> ever be used for data transmission."
> 
> This might seem obvious to all of us, but this wording change could
> conceivably speed review and fend off questions by some review board.

Works for me.


> >    TLS clients which support this draft MUST generate either the
> > 
> >    "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
> >    cipher suite with every ClientHello.
> 
> Can they generate both?
> 
> If not, what does the server do if he receives both?

I see several possibilities:

- One or the other and the server MUST abort if he receives both. 
- Either or both on initial handshakes, but RI only on rehandshakes
- RI MUST be present on rehandshakes. The MCSV MAY be present
  but MUST be ignored.

The last of these would obviously require slightly altering the
"exactly the same" rule, so seems less desirable, but really any
of these are easy to do. I think my preference would be for the
first.


> >    Existing implementations which do not support this extension are
> >    widely deployed and in general must interoperate with newer
> >    implementations which do support it.  This section describes
> 
> s/must/need to/ to avoid confusion with MUST.

Works for me.


> >    If a client offers the "renegotiation_info" extension or the
> >    TLS_RENEGO_PROTECTION_REQUEST cipher suite and the server does not
> >    reply with "renegotiation_info" in the ServerHello, then this
> >    indicates that the server either does not support secure
> >    renegotiation or is unwilling to use it.
> 
> Is it allowed for a patched server to be "unwilling"?
> 
> If not, drop the "or is unwilling to use it" lest it give the impression
> that such behavior is condoned.

Works for me.


> >    If the client does not offer the "renegotiation_info" extension or
> >    the TLS_RENEGO_PROTECTION_REQUEST cipher suite then this indicates
> >    that the client does not support secure renegotiation or is unwilling
> >    to use it.  However, because the above attack looks like two
> 
> Again, is it allowed for a client to be conformant to this spec and
> still not send either the extension or magic cipher suite value?

Works for me.

-Ekr