Tom Weinstein wrote:

> The economic view might be a reasonable view for an end-user to take,
> but it's not a good one for a protocol designer. The protocol designer
> doesn't have an economic model for how end-users will end up using the
> protocol, and it's dangerous to assume one. This is especially true for
> a protocol like TLS that is intended to be used as a general solution
> for a wide range of applications.

I agree with this.  Especially, I think we are
all coming to the view that TLS/SSL is in fact
a general purpose channel security protocol,
and should not be viewed as being designed to
protect credit cards or e-commerce especially.

Given this, it is unreasonable to talk about
threat models at all, when discussing just the
protocol.  I'm coming to the view that protocols
don't have threat models, they only have
characteristics.  They meet requirements, and
they get deployed according to the demands of
higher layers.

Applications have threat models, and in this is
seen the mistake that was made with the ITM.
Each application has to develop its own threat
model, and from there, its security model.

Once so developed, a set of requirements can
be passed on to the protocol.  Does SSL/TLS
meet the requirements passed on from on high?
That of course depends on the application and
what requirements are set.

So, yes, it is not really fair for a protocol
designer to have to undertake an economic
analysis, as much as they don't get involved
in threat models and security models.  It's
up to the application team to do that.

Where we get into trouble a lot in the crypto
world is that crypto has an exaggerated
importance, an almost magical property of
appearing to make everything safe.  Designers
expect a lot from cryptographers for these
reasons.  Too much, really.  Managers demand
some special sprinkling of crypto fairy dust
because it seems to make the brochure look

This will always be a problem.  Which is why
it's important for the crypto guy to ask the
question - what's *your* threat model?  Stick
to his scientific guys, as it were.

> In some ways, I think this is something that all standards face. For any
> particular application, the standard might be less cost effective than a
> custom solution. But it's much cheaper to design something once that
> works for everyone off the shelf than it would be to custom design a new
> one each and every time.

Right.  It is however the case that secure
browsing is facing a bit of a crisis in
security.  So, there may have to be some
changes, one way or another.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to