Re: [TLS] Summarizing identity change discussion so far

[Stephen Farrell <[e-mail]>]

Text like this is much better and would remove the
concern I expressed before (that this spec is not
the place to do more than just fix the renegotiation
bug).

Adding positive examples (games/XMPP) as Martin
suggested would be a fine addition to this.

Delving into details of PKIX or other identity
matching would not be fine IMO.

S.

[e-mail] wrote:
> Here's proposed text for the Security Considerations section about the
> identity changes. The discussion on the list seemed to favor keeping
> the normative parts quite mild, so much of this is worded as advice
> for people to consider (or ignore, if they so choose), not as strict 
> requirements:
> 
>    While this extension mitigates the man-in-the-middle attack
>    described in the overview, it does not resolve all possible
>    problems an application may face if it is unaware of renegotiation.
>    In particular, either the client or the server can during
>    renegotiation present a different certificate than was used
>    earlier, and this may become as a surprise to application
>    developers (who might have expected, for example, that a
>    "getPeerCertificates()" API call returns the same value if called
>    twice), and might be handled in an insecure way.
>    
>    TLS implementers are encouraged to clearly document how
>    renegotiation interacts with the APIs offered to applications (for
>    example, which API calls might return different values on different
>    calls, or which callbacks might get called multiple times).
> 
>    To make life simpler for applications that do not expect the peer's
>    certificate to change once it's been authentication, TLS
>    implementations MAY offer the applications the option abort the
>    renegotiation if the peer tries to authenticate with a different
>    certificate and/or different server name (in the server_name
>    extension) than was used earlier. However, enabling this option by
>    default for all applications could break existing applications that
>    depend on using renegotiation to present multiple certificates.
>    TLS implementations SHOULD also offer the applications the option
>    to disable renegotiation completely.
> 
>    Finally, designers of applications that depend on renegotiation are
>    reminded that many TLS APIs represent application data as a simple
>    octet stream; applications may not be able to determine exactly
>    which application data octets were received before, during, or
>    after renegotiation. Especially if the peer presents a different 
>    certificate during renegotiation, care is needed when specifying
>    how the application should handle the data.
> 
> Comments (and especially concrete proposals for improving the text)
> are welcome.
> 
> Best regards,
> Pasi
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Eronen Pasi (Nokia-NRC/Helsinki)
>> Sent: 08 December, 2009 11:13
>> To: [e-mail]
>> Subject: [TLS] Summarizing identity change discussion so far
>>
>> (wearing Area Director hat)
>>
>> Although the IETF Last Call is still underway, here's a short attempt
>> to summarize the discussion regarding identity changes (Section 7) so
>> far:
>>
>> - We seem to agree that changing the certificate/identity
>> during secure renegotiation (so there's no man-in-the-middle, just two
>> parties) could confuse some applications.  James Manger's email
>> provides
>> IMHO a good example of what that confusion could be (in this particular
>> example, the confusion has security implications, too):
>>
>> http://www.ietf.org/mail-archive/web/tls/current/msg05122.html
>>
>> - We mostly seem to agree that some applications could not just handle
>> certificate/identity changes correctly, but would actually benefit
>> from them.
>>
>> - We seem to agree that it would be a reasonable idea for the TLS
>> library to offer the applications an option where the TLS library
>> checks that the certificate doesn't change during renegotiation.
>> This is an *option* -- an application could decide not to use it,
>> and e.g. do more complex comparisons.
>>
>> - We have much less support for requiring that every TLS library
>> MUST implement this functionality and/or MUST enable it by default
>> (whatever "by default" means in your API), at least in this draft.
>>
>> Unless I'm badly misreading the situation, or it significantly changes
>> during the rest of the IETF Last Call, my proposal here would be as
>> follows:
>>
>> - We do NOT require (with "MUST") any changes to TLS libraries in this
>> regard.
>>
>> - We describe the situation a bit more clearly than the current text
>> does (it seems many people found the current text somewhat unclear).
>>
>> - We recommend that TLS libraries SHOULD provide identity matching
>> (with memcmp, abort handshake if changed) functionality to
>> applications, and SHOULD allow applications to enable/disable this
>> functionality.
>>
>> - We include a sentence or two describing the pros and cons of
>> enabling/not enabling this feature by default, but don't require or
>> recommend any particular default value.
>>
>> - The text probably needs to note that if the applications wants to
>> deal with identity changes, it may need to consider the "which
>> application_data byte(s) correspond to which identity" question (or it
>> may not -- the answer may depend a lot on the application protocol).
>>
>> Does this sound like a reasonable approach?
>>
>> Best regards,
>> Pasi
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>