Re: [TLS] Summarizing identity change discussion so far

I share the opinion that identity checking belongs in the application,
performed according to whatever mechanism is appropriate.  We should not
be mandating any particular PKIX processing in the TLS specs. 

I also think if an application is not prepared to be aware of
renegotiation and handle any identity change associated with it then
renegotiation should be disabled.  This implies that renegotiation
should be disabled by default and specifically enabled by an
application.  So I would say

"TLS implementations SHOULD disable renegotiation by default and offer
the applications the option to enable renegotiation.  When an
application enables renegotiation it must handle identity processing for
each handshake."

I don't think binary certificate comparison is necessarily the most
valid comparison for applications to use.  I'm not convinced it will
make life simpler for applications.  

Joe

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On 
> Behalf Of Pasi.Eronen@nokia.com
> Sent: Thursday, December 17, 2009 2:06 PM
> To: aerowolf@gmail.com
> Cc: tls@ietf.org
> Subject: Re: [TLS] Summarizing identity change discussion so far
> 
> Kyle Hamilton wrote:
> 
> > No, identity matching SHOULD be done in accordance with 
> PKIX.  memcmp 
> > is not at all sufficient.
> > 
> > However, I would support the following:
> > 
> > - TLS libraries SHOULD provide identity matching services 
> between and 
> > throughout renegotiation handshakes.  Libraries SHOULD 
> implement this 
> > in accordance with PKIX [PKIX], but MAY do so with a direct memory 
> > comparison.  Implementors are cautioned that this latter 
> approach does 
> > not provide for changing the cipher parameters -- such as a 
> > renegotiation with an EC or DH certificate after 
> identification with 
> > an RSA certificate.  If the identity matching service fails 
> to match 
> > the identity, implementations MUST abort the handshake with a fatal 
> > bad_certificate alert.
> 
> Well, the text I proposed just said "different certificate", 
> not "memcmp". I know that's a bit vague, but "in accordance 
> with PKIX [PKIX]" is not very precise either, and would need 
> a more specific reference to where exactly the details are 
> (for example, it can't mean comparing the Subject field, 
> since PKIX allows leaving it empty).
> 
> And the certificate might have extensions (certificate 
> policies, subject directory attributes, extended key usage, 
> etc.) where changes between API calls could surprise the application.
> 
> Here's another shot at that paragraph (also including 
> suggestions from Marsh's email):
> 
>    TLS implementations SHOULD offer the applications the option to
>    disable renegotiation completely.
> 
>    To make life simpler for applications that do not expect the peer's
>    certificate to change once it's been authenticated, TLS
>    implementations may also wish to 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 change from one
>    certificate to another. (For example, long-lived TLS connections
>    could change to a renewed certificate; or renegotiation could
>    select a different cipher suite that requires using a different
>    certificate.)
> 
> Best regards,
> Pasi
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 