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

[Peter Gutmann <[e-mail]>]

Marsh Ray <[e-mail]> writes:

>This sounds like an endeavor of great merit.

Phew, that's better than "OK, you write it then" :-).

(This would also be useful for the rest of the big 5, IPsec, SSH, S/MIME, and
PGP, for which the threat model is mostly "here's what we defend against, if
that's what you want then use it").

>Is this the type of project that any other [TLS] members would be interested
>in collaborating on?

Count me in.

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

That's a good start, I was thinking of something vaguely similar but built
more around services that people require, so providing a shopping list like
confidentiality, integrity, dispute (what's incorrectly referred to as
"nonrepudiation" most of the time), availability, and so on, and then listing
under which conditions TLS does and doesn't provide this.  It depends on what
the target audience is, Ivan's attack tree is for people worried about how TLS
might fail while the services-provided categorisation is for people who need a
particular service from TLS and want to know whether they're getting it.

>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.?

I think for the services-provided approach it might be feasible, so you could
say, for example, that "basic TLS doesn't provide this, but with the XYZ
capability present it provides a subset of this", that sort of thing. Actually
this works for the attack-tree approach as well, a particular arc would be
"unmitigated by basic TLS, mitigated by XYZ".

(I'm not saying the services-provided view is the best one, it could quite
well be terrible, I'm just throwing it out there as a possibility).

>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.

Yup.  What I'd be aiming at is, cheating a bit and using some secure logging
text I have lying around as an example, that a user reading the document
wouldn't end up with a generic "audit data is stored in a secure manner"
(secure relative to what?) but more something like "audit data is stored in a
file only writeable by the system-audit user. It should be secure from
tampering provided that the operating system file protection mechanisms are
functioning as intended, that the system-audit user account hasn.t been
compromised, and that the security of the operating system itself hasn.t been
compromised, for example through a rootkit that can override the security
mechanisms of less-privileged system components".

Peter.