[email protected]
[Top] [All Lists]

RE: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Secur

Subject: RE: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard
From: Nasko Oskov
Date: Mon, 30 Nov 2009 21:58:05 +0000
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
[email protected]

<Prev in Thread] Current Thread [Next in Thread>