Opened 13 years ago

#113 new clarification

Nelson's Clarifications

Reported by: jsalowey@… Owned by:
Priority: major Milestone: DISCUSS
Component: draft-ietf-tls-renegotiation-00 Version: 00
Severity: Active WG Document Keywords:
Cc:

Description

Nelson B Bolyard

I support this draft, and request modifications similar to the following, which (I believe) are merely clarifying in nature, and do not change the over-the-wire specification any. I do not require these exact modifications, but something like them would help a lot.

Page 6 section 3:

  • Upon receipt of the "renegotiation_info" extension, implementations

+ Upon receipt of the "renegotiation_info" extension, both client and + server implementations

which support the extension MUST verify that it contains the correct contents as specified above.

Page 6, section 4.1:

  • If a client offers the "renegotiation_info" extension and the server
  • does not respond, then this indicates that the server either does not

+ If a client hello offers the "renegotiation_info" extension + (hereinafter abbreviated RI) and the server does not offer an RI + extension in the server hello response, then this indicates that the + server either does not

Page 7, section 4.2:

  • If the client does not offer the "renegotiation_info" extension, then

+ If the client hello does not offer the "renegotiation_info" + extension, and does not contain the "RENEGOTIATE_WITH_RI" cipher + suite, then

(Note, this resolves an ambiguity. Otherwise, the requirements of section 4.2 seem to apply also when "RENEGOTIATE_WITH_RI is present, which section 4.1.1 requires to be dealt with in a different manner. The suggested change keeps these requirements of the two sections from overlapping.)

Page 7, section 4.3:

  • SSLv3 does not support extensions and thus it is not possible to Both

+ Both

SSLv3 (at least later drafts) and TLS 1.0/1.1 require implementations

Page 8, section 4.3 (top of page):

  • extensions since the ordinarily TLS Finished messages protect that

+ extensions since the ordinary TLS Finished messages protect that

negotiation.

Page 8, section 4.3:

best practice is not to continue the connection. Even servers which

  • refuse to renegotiate SHOULD reply with an empty RI extension because

+ refuse to renegotiate SHOULD reply with an empty RI extension in the + server hello of the connection's initial handshake because

this signals that they have been upgraded.

(This clarifies where and when they should reply with that empty RI extension, since they CANNOT do it in the refused renegotiation.)

Page 8, section 5:

By default, TLS implementations conforming to this document MUST

  • verify that once an identity has been authenticated within the TLS
  • handshake, it does not change on subsequent renegotiations.

+ verify that once the peer has been identified and authenticated + within the TLS handshake, the identity does not change on subsequent + renegotiations.

Change History (0)

Note: See TracTickets for help on using tickets.