Re: [TLS] Summarizing identity change discussion so far

[Marsh Ray <[e-mail]>]

Looks great to me.

A few edit suggestions inline.

- Marsh

[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
     For example, during renegotiation either the client
     or the server can present...
>    renegotiation present a different certificate than was used
>    earlier, and this may become as a surprise to application
     earlier.     This may   come as a surprise
>    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
how about: "are encouraged to offer" ?
>    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.
Consider moving this sentence above the MAY, perhaps in its own paragraph.

>    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.

- Marsh