Re: [TLS] TLS, PKI, and web security. Was: Eleven out of every ten SSL certs aren't valid

[Marsh Ray <[e-mail]>]

On 07/19/2010 07:44 AM, Peter Gutmann wrote:
> Marsh Ray<[e-mail]>  writes:
>
>> 1. Is TLS an effective and secure cryptographic protocol primitive? Does it
>> deliver on the stated and implied guarantees given by its RFCs?
>
> This is an interesting issue, I'm not sure if there actually is any document
> that covers the TLS threat model  [...]
>   What we'd need here is a clear
> statement of what TLS can, and can't, protect against, and under which
> circumstances, and in which configurations.  Until we have that baseline to
> build on, it's (unfortunately) not really possible to have a meaningful debate
> about whether it meets is goals because we don't know if aspect X is a flaw in
> TLS, a flaw in something other than TLS, not a flaw at all, or out of scope.

This sounds like an endeavor of great merit.

Is this the type of project that any other [TLS] members would be 
interested in collaborating on? The result could be submitted as an 
informational RFC or, at the very least, we might end up with a set of 
wiki pages somewhere. This could cut down on some of the repetitive 
debate that shows up on this list from time to time. It could also be a 
good student project.

Ivan Ristic started addressing it from a pretty high level:
http://blog.ivanristic.com/2009/09/ssl-threat-model.html

Firstly, we'd need agreement on which RFCs were in scope for the 
project. Is this already documented somewhere for the list charter?

Since TLS has so many negotiable parameters and extensions, it might be 
a little difficult to structure it as a flat document. Does anyone have 
suggestions on how to organize it considering all the cipher suites, 
authentication modes, extensions, etc.?

> As Bob Morris once said [0], "the behaviour of a program withot a
> specification can never be wrong, merely surprising".

And it tends to consume a lot of unnecessary discussion precisely at the 
time of the "surprise" when coordination is needed for incident response.

What would be really great is when the next big "reverse quadrangle 
padding interpolation attack" is published, we had something ready which 
could help enumerate all the design features which had built on the 
specific properties that had been violated.

- Marsh