Re: Clarifying controversial criteria

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Previous message: Raph Levien: "Re: Clarifying controversial criteria"

On Mar 14,  3:37am, Blake Ramsdell wrote:

> That's kind of like saying "since Word can save text files which don't
> retain any of the formatting, then I can't exchange documents that retain
> the formatting with other people that use Word", which is, of course,
> incorrect.  You simply select Word format as your output format.  Likewise,
> you simply pick the algorithm type that matches your recipient, and if that
> recipient can't take more than 40-bit encryption, then that's it.

    But if Word 5.1 can create text files, as can Word 4.3 for the
Mac, and Word 6.0, and they don't have any level of interoperability
more than that, guess what -- people that need to send Word files to
each other will end up sending a lot of text files.  You really,
really, want a minimum level of interoperability that is considerably
higher than just plain text files.


    From an implementation perspective, it is very important to know
what the minimum level of interoperability is required by the
standard.  And in many cases, you'll find that no one ever goes beyond
that minimum required, which is why I think it's very important to set
that bar as high as we can, within certain restrictions.

    One restriction is what is feasible beyond the point where you get
things secure enough that, by the best currently available practices,
we believe that the encrypted message(s) will still be secure up to
and including the limit imposed by the Statute of Limitations.  In
other words, if a 512 bit key length with algorithm Q is considered to
be likely to remain secure for at least seven years, then how much
sense does it really make to require that all implementations support
a minimum key length of 64K bits?

    Like it or not, another restriction is exportability.

> >>    This is part of why I said "The *HELL* with ITAR" at the workshop.
> 
> Preach on, brother Brad!  I have one of those fist and lightning bolt
> pictures on my home page also...
> 
> We can bitch about ITAR all we want, but if I want to ship a product with
> encryption for export, then I have to follow the rules.

    We're in the same boat on that.  When it comes to what we can
ship, we have to focus on what we can export.

    However, I don't consider what can be exported to be a limitation
that should affect how high we can set the standard, but instead is a
bar itself that needs to be raised at least to the level of where I
think the standard should be.


    The question could be re-phrased as "Is the glass 1/8 full or 7/8
empty?"  I prefer to think of it as 7/8 empty, and prefer to work on
getting those other eighths that I think are critical to making this
thing work well enough and be secure enough that I'll actually be
willing to use it myself, and be able to sleep at night when I
recommend that others use it.

    And remember -- the average user can't program their own VCR, and
it is our responsibility to make this thing idiot-resistant enough
that they can't easily manage to make their mail insecure.

> Certainly someone in another country can implement S/MIME using DES
> EDE3-CBC, so it's just a matter of if/when critical mass is achieved.  I'm
> not even sure that we can say PGP has any true foreign implementations,
> since the foreign implementation that I'm aware of is 1. For non-commercial
> use only, and 2. Based on source code that shouldn't have left the country
> to begin with.  Has there been a foreign company that has done a cleanroom
> version of PGP for commercial use?

    Whatever it's origin, it is now a foreign version and therefore
qualifies (in my book).

    Whatever standard we propose will have to deal with the fact that
it is available and further development will continue on it, and if we
can't come up with something that is capable of being as secure as PGP
is, then we're going to have a hard time convincing people to user our
standard.  And to be successful, we have to make people *want* to use
our standard.


    I could make the analogy to CDMA vs. TDMA encoding for digital
cellular phones.  When only one is available, then on one has a
choice.  When one is already available and you want to introduce the
other, you have to have a pretty convincing argument to make people
want to use yours instead.


    Well, PGP is currently available and has strong crypto.  We're
going to have to come up with some pretty convincing arguments to use
whatever we come up with over PGP, and just being exportable and easy
to use won't cut it -- we also have to be at least as strong,
cryptographically speaking.

    Otherwise, we just won't convince people to switch.  Otherwise,
you won't convince me to switch.  And you're going to have a hard time
getting everyone to follow suit if you can't get some consensus out of
the people setting the standards.

-- 
Brad Knowles                           MIME/PGP: BKnowles@aol.net
    Mail Systems Administrator        <http://www.his.com/~brad/>
    for America Online, Inc.                   Ph: (703) 453-4148

	PGP keys available from pgp-public-keys@pgp.ai.mit.edu

• Previous message: Raph Levien: "Re: Clarifying controversial criteria"