Bodo Moeller wrote:
There is no good reason for this asymmetry of having just the client's
verify_data in the client's message, but both the client's and the
server's verify_data in the server's message -- the latter is pure
overhead, both in the specification and in the on-the-wire protocol. To
remove the overhead from both, the second sentence should be saying,
"For ServerHellos which are renegotiating, this field contains the
verify_data sent by the server on the immediately previous handshake"
(according changes to dependent parts of the specification then should
For earlier Internet Drafts in the series preceding
(draft-rescorla-tls-renegotiation.00.txt, etc.), a reason to keep the
current text would have been to maintain compatibility with early
implementations of those Internet Drafts. However,
draft-ietf-tls-renegotiation-01 has a newer
TLS_RENEGO_PROTECTION_REQUEST cipher suite and thus breaks compatibility
with those early implementations anyway.
(This means that now, changing the ServerHello extension definition as
suggested above gives the beneficial side-effect of exposing premature
implementations, besides merely avoiding overhead. Those incomplete
implementations will be more obviously incompatible because they'd still
be using the protocol variant with overhead, instead of just differing
subtly in the behavior if faced with TLS_RENEGO_PROTECTION_REQUEST.)
I don't think any of those implementations have shipped, and I don't
think anyone has advertised that code as anything but experimental.
It might not hurt for the IANA to assign a different number to the
extension than what was used for testing.
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.
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
Although the sentence after the one you quoted seems to say that
implementations are allowed to do it anyway if they choose. Which raises
the question as to what this language actually means for the wire
The new restriction that draft-ietf-tls-renegotiation-01.txt tries to
sneak in thus seems harmful both for interoperability and for security.
I haven't seen any signs of working group consensus on including this
Details about which certificates endpoints should be allowed or
forbidden to negotiate is outside the scope of this bugfix.
We should remove it.
Ietf mailing list