Re: [TLS] Summarizing identity change discussion so far

> -----Original Message-----
> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] 
> Sent: Tuesday, December 22, 2009 11:35 PM
> To: Joseph Salowey (jsalowey); tls@ietf.org
> Subject: RE: [TLS] Summarizing identity change discussion so far
> 
> Based on earlier discussions, I don't think we have consensus 
> for this strong change ("SHOULD disable renegotiation by 
> default"). If you ship an updated TLS library with that 
> change, it will break all existing applications that use 
> renegotiation (since they are not aware of the API call to 
> re-enable it, which was probably added in the same update).
> 
[Joe] I agree. 

> I think we have rough consensus for "SHOULD have an API to 
> disable/enable renegotiation (depending on which is the 
> default setting)", but not for what the default setting should be.
> 
[Joe] I'm OK with text along those lines.  How about replacing the 3rd
paragraph with:

"TLS implementations SHOULD provide a mechanism to disable and enable
renegotiation. "

I would also favor adding something like the following to the 5th
paragraph, but I could live without it:

"To make life simpler for applications that do not expect the
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.  TLS implementations may alternatively offer the
option to disable renegotiation once the client certificate has be
authenticated.  However, enabling these options 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
> (wearing AD hat)
> 
> > -----Original Message-----
> > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On 
> Behalf Of 
> > ext Joseph Salowey (jsalowey)
> > Sent: 19 December, 2009 08:03
> > To: Nelson B Bolyard; IETF TLS Working Group
> > Subject: Re: [TLS] Summarizing identity change discussion so far
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] 
> On Behalf 
> > > Of Nelson B Bolyard
> > > Sent: Friday, December 18, 2009 11:49 AM
> > > To: IETF TLS Working Group
> > > Subject: Re: [TLS] Summarizing identity change discussion so far
> > >
> > > On 2009-12-17 23:27 PST, Joseph Salowey (jsalowey) wrote:
> > > > 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."
> > >
> > > With my Idealist hat on, I agree with that 100%.  But after
> > > 13.25 years of working on SSL/TLS libraries, I know that 
> 98+% of the 
> > > app developers who use TLS have no idea what that means 
> or how to do 
> > > it.  IMO, they are likely to just call a function for 
> each handshake 
> > > that does the same thing as for the first handshake, 
> validating the 
> > > cert chain and (if we're
> > > lucky) checking that some aspect of the cert contains 
> some expected 
> > > name, without any regard to what prior certificates may have 
> > > contained.
> > >
> > >
> > > So, IMO, it makes sense of TLS implementations to offer 
> some sort of 
> > > "default" handling of certs to attempt to ensure continuity of 
> > > identity in the absence of something much better from the 
> > > application.  I'd suggest that, unless the applications 
> direct them 
> > > to do otherwise, perhaps by registering some callback, TLS 
> > > implementations should check that the cert in a 
> renegotiation is the 
> > > same one as in the previous full handshake, either by 
> memcmp of the 
> > > entire cert, or by memcmp of the subject name and
> > > subjectAltName (if any).   Anything less will ensure that
> > > most apps continue
> > > to get this wrong, IMO.
> > 
> > [Joe] So ideally renegotiation would be disabled (perhaps after the 
> > client is authenticated in a TLS handshake) unless 
> application enables
> > it.   The TLS implementation can implement some policy on 
> how to match
> > identity from on handshake to the next, but I'm not 
> confident that any 
> > single specific policy  will be the right policy for different 
> > applications and deployments.
> > 
> > > _______________________________________________
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
> > >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> 