Re: [TLS] TLS renegotiation issue

[Nicolas Williams <[e-mail]>]

On Fri, Nov 06, 2009 at 12:24:55AM +0100, Martin Rex wrote:
> Marsh Ray wrote:
> > 
> > I would add here that if the IETF had compared the way TLS looks on the
> > wire with how it is presented by SSL APIs in practice, this defect could
> > not have gone unnoticed.
> 
> I would like to put this differently.
> 
> There are several different APIs and API architectures for SSL/TLS
> protocol stacks.  If you really want to verify a spec, there is
> no better way than implementing it.  As an implementor, you get
> to see both, the TLS protocol engine as well as the API that
> you make available to application callers.
> 
> And when an implementer describes to its consumers how to use
> the implementation and how to architect the applications usage
> of TLS, this problem should really have been noticed.
> 
> 
> Finding problems when discussing things at an abstract level
> is MUCH MUCH harder.  You notice that when people define
> protocols with ASN.1 elements.  It's almost exclusively
> the implementors who find the problems. 

Implementors, on the other hand, may not have the experience necessary
to determine the consequences of a flaw like this, they may (and
probably did) just shrug.  More likely though, you can't really predict
who's going to find any given vulnerability.

Providing more information, more views, always helps.  In this case it
would have.  But then, too, we should keep in mind that there are many
possible TLS API designs -- Marsh is saying, I think, that the SSPI-/
GSS-API-like ones that would have made this flaw obvious, and I agree.