Bodo Moeller wrote: >On Nov 30, 2009, at 4:37 PM, 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 >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to >> the ietf@xxxxxxxx mailing lists by 2009-12-14. > >I support the move, contingent to two clean-ups to specified behavior: I support the 01 version of the draft, assuming we address this point: >2. The Security Considerations section of draft-ietf-tls- >renegotiation-01.txt (section 7) includes language that unnecessarily >restricts the flexibility that the TLS protocol specifically provides for, >regulating areas that the TLS standard intentionally does not specify (RFC >5246 section 1) -- the current Internet Draft says: > >"By default, TLS implementations conforming to this document MUST verify >that once the peer has been identified and authenticated within the TLS >handshake, the identity does not change on subsequent renegotiations. For >certificate based cipher suites, this means bitwise equality of the >end-entity certificate. If the other end attempts to authenticate with a >different identity, the renegotiation MUST fail. If the server_name >extension is used, it MUST NOT change when doing renegotiation." > >There is no security reason for this restriction. This sounds like a bad >and incomplete workaround for certain problems with TLS that the updated >protocol does not need a workaround for at all, because the protocol update >is all about properly *solving* those problems. I agree that this restriction is not necessary for solving the current problem. If the section should stay, I would vote for making it a SHOULD and definitely not a MUST. >Keeping this language in the specification would have the weird implication >that applications that *need* the flexibility provided by the TLS protocol >(e.g., to allow renegotiation handshakes to switch to a different >ciphersuite, which may require a different certificate) would have to to >*skip* implementing the protocol update, and thus stay vulnerable. What about certificate renewal? Once a cert is renewed, it is different when it comes to bitwise comparison, yet it is the same identity. I do not think doing bitwise comparisons and dealing with identity at the TLS layer should be part of this draft. Nasko _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf