Re: [TLS] [pkix] Possible revocation delay issue with TLS stapling

["Santosh Chokhani" <[e-mail]>]

Tim,

In TLS model, the client's authorization check is basically checking the
server certificate DNS name against the expected DNS name.  I doubt
browser model will go beyond that.

Basically, the revocation freshness issue discussed in this thread is
not unique to TLS Server going rogue, except that a rogue server no
longer requires DNS poisoning assistance.

I do not think there is any change needed to the OCSP Specs either,
albeit 2560 could stand some clarification in the area of client side
processing.

The TLS folks may want to provide some guidance on CAs issuing server
certificates in terms of CRL next update field values and recommend to
the browsers to warn the user or deny the session if the revocation
information is past the next update field.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Miller, Timothy J.
> Sent: Monday, March 29, 2010 9:03 AM
> To: 'Nicolas Williams'; Yngve N. Pettersen
> Cc: [e-mail]; [e-mail]
> Subject: Re: [pkix] [TLS] Possible revocation delay issue 
> with TLS stapling
> 
> A possible 'fix' to the revocation window problem has always 
> been shorter certificate validity periods.  This has its own costs.
> 
> IMHO, however, timeliness revocation isn't the problem.  
> Experience with real world PKIs shows that sometimes 
> revocation simply doesn't happen.  The CA may not be 
> available, the incident may never get reported, or the system 
> may simply fail in any of a dozen different ways up to and 
> including lost database transactions.  Don't think it doesn't happen.
> 
> In short, relying on revocation to deny access may not be a 
> good idea, at least for some systems.  Since the usual goal 
> of authentication is to enable authorization, it can be safer 
> to rely on the authorization system--i.e., revoke the 
> account, remove the account's privileges, or invalidate the 
> mapping between the shouldn't-be-used-any-more key and the 
> account.  This is where X.509 gets in trouble; X.509 binds 
> keys to names, and names are strongly (and naturally) mapped 
> to accounts, so under X.509 the ways in which an 
> authorization system can break the key-to-account mapping are 
> very limited.  (The alternative--binding names to keys--has 
> it's own set of problems, naturally.  They're different from 
> X.509's, though.)
> 
> Either way, PKI authentication isn't enough by itself.  You 
> need an equivalent authorization infrastructure to really 
> make things work.
> 
> -- Tim
> 
> 
> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of 
> >Nicolas Williams
> >Sent: Friday, March 26, 2010 1:17 PM
> >To: Yngve N. Pettersen
> >Cc: [e-mail]; [e-mail]
> >Subject: Re: [pkix] [TLS] Possible revocation delay issue with TLS 
> >stapling
> >
> >[Why not pile on?  I think there's an angle not covered.]
> >
> >As others have pointed out this is nothing new, nor special 
> about OCSP 
> >versus CRLs, and they have pointed out the workaround for 
> RPs that care.
> >
> >The more interesting point, I think, is that instantaneous 
> revocation 
> >is like password synchronization: hard.  You can get down to 
> a window 
> >of minutes.  But instantaneous revocation?  I don't believe that's 
> >feasible in real world deployments.  Also, revoking certs is 
> not enough 
> >if you want instantaneous revocation!  You'd also want to 
> slam existing 
> >connections, and yet we have no protocol for doing that.
> >
> >However, quick revocation has much higher costs than quick password 
> >synchronization.  That's because making it possible to revoke certs 
> >quickly means making more frequent use of online infrastructure, and 
> >more frequent validation of signatures, whereas with 
> password synch you 
> >need only push changes as quickly as possible to a relatively few 
> >servers.  Nowadays that extra cost may be in the noise, but it's not 
> >nothing, and it's the reason that we have the ability to have OCSP 
> >responses without nonces.
> >
> >Think of OCSP as a Kerberos-like ticketing facility, with certs+OCSP 
> >being like TGTs with long renewable lifetimes (corresponding to the 
> >certs' notAfter) but short lifetimes (corresponding to OCSP response 
> >freshness requirements / nextUpdate).  If you care about quick 
> >revocation then you can just tune down the OCSP response freshness 
> >requirements such that they fall within a time window whose size is 
> >comparable to the time needed for revocation notices to 
> reach all the 
> >relevant OCSP responders.  The trick is to find just the 
> right setting.
> >
> >Nico
> >--
> >_______________________________________________
> >pkix mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/pkix
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
>