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(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf