ietf-openpgp
[Top] [All Lists]

Re: armour pierced with PGP 8 arrow

2003-12-12 08:46:38

karlsson(_at_)hal-pc(_dot_)org wrote:

On Thu, Dec 11, 2003 at 02:01:29PM -0500, Ian Grigg wrote:

Such as:

Version: 1.0.0 non-commercial, upgrade to
Version: 2.0.0-commercial

When the line slicing behaviour is set to (about) column 42.

If I have to set my line width to 42, your mail system is so broken
that I don't need to talk to it. 72 is reasonable, and and one should
expect lines exceeding 80 characters to be wrapped. Anything under 68 is
unreasonably small. I, for example, am using 72 character lines in my
editor (vim).


It does appear to be the consensus that there
is no need or desire to change the ID on this
issue.  However, I'm not seeing a lot of real
consideration of the real points here.  So  I'm
unclear here whether to keep kicking this dying
horse, or perhaps Derik could rule on closing
it?

?  I disagree with the above logic on the
following grounds:

   OpenPGP is not only used for mail, and in
   fact takes great care to be more universally
   useful (scan the ID for the word "mail", I
   just did!).  We here should also strive to
   move from the particular to the general, when
   looking at examples, and back again.

   Security standards are not built on such
   considerations of "yours is broken because
   I don't like your numbers."  Bad software
   is certainly built with those sorts of
   criteria, but bad software is not what we
   are about here.  This is about security,
   so detail is important.

   The offending number chosen was related to
   the example;  the point remains with an
   example of a different number.  You pick.

   Notwithstanding many peoples' desires to
   impose their views of how mail works on
   the rest of the world, there are other
   mail considerations in the future:  PDAs
   and phones have smaller screens, for example.
   Web mailers and hush-style mailers can be
   very unkind to formatters.  Chat is replacing
   email....  the list goes on - if OpenPGP is
   to be based on the email view of the past,
   then, we should all stop work on it right
   now.

The greatest success comes when multiple
competing implementations communicate with
ease, and without games.  Here we have a case
where it is apparently easy to legally create
a correct message that gets turned into a
recipient message of indeterminate legality
by transport.

Fixing this costs nobody much at all [1].


if (!(ptr=(uint8_t *)memchr(line, ':', sizeof(line))) || ptr[1]!=' ')
        exit(1);


Please make sure you read the entire example.

That doesn't decide which line of the two lines
in the previous text, post-slicing, goes on to
become the dominating one.

The game to play in security programming is to see
if a) we can confuse the other party, and b) we can
create a security breach out of a confusion.

We've shown a).  I grant b) is a little harder, as
optional headers aren't supposed to be "used" for
such things.  But, who knows what adventurous souls
have in their minds for the future... [2]


iang


[1] I just thought late last night how to breach
b)...  Imagine you are a company selling a device
that filters on the headers.  Imagine that you
make commercial decisions on the basis of those
headers.  (Because that's all you can read.)  Then,
an enterprising young chap realises that all he
has to do is to slice the headers, and they are
still human-readable, but they bypass the filtering
of the proxy that handles incoming messages.

marketing reference: NY AG v. WS == 1.3 bn.

[2]  the guys
over at PGP Inc might want to rewrite their
comment to be a bit shorter than the ASCII-
Armoured data lines - rule of thumb - and to
change the extra ": " to some other symbol.

If they haven't already done these steps,
I'd be very surprised!  Also, they should
reject sliced headers, or suggest we change
the ID on that point.  But, no real cost.

GPG might want to detect and warn that the
headers appear corrupted and can be fixed
easily with an editor, rather than silently
bailing on ID strictness.