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 [email protected] 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.
Ietf mailing list