Subject: Re: armour pierced with PGP 8 arrow

From: Derek Atkins <[email-masked]>
Date: Mon, 01 Mar 2004 17:49:42 -0500

Sorry for the delay in responding to this thread.

It does appear that there is no consensus to make a change to the text
on this matter.  You are correct that PGP goes to some lengths to try
to protect itself from transmission errors or corruptions.  However it
still makes some assumptions about the transmission medium and what it
will do to its messages.

You are correct that OpenPGP is designed for more than just email.
However other transmission mediums tend to have even fewer restrictions
than email, so changes do not appear to be warranted.

Security programs are built with some basic assumptions.  For example,
you assume that TCP will actually deliver your packets (OpenPGP certainly
does not worry about TCP DoS attacks).  Following that logic, it is
reasonable to make some basic assumptions about lower-layer behavior.

Also I'll keep in point that the comment is also (generally)
user-settable, so users can always shoot themselves in the foot.

-derek

Ian Grigg <[email-masked]> writes:

> [email-masked] 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.
>
>

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant