headers
Levi Broderick | 5 Jan 2007 23:05
Picon
Favicon

Packet length: header vs. context


(resending, as the original message seems to be MIA)

Consider the following scenario:

An implementation is parsing a public-key packet.  The packet header
gives a body length of 600 bytes; this is then buffered into memory.
The software successfully parses all the data in the packet body -
everything from the packet version number to the final MPI that it was
expecting - and realizes that it has only read 400 bytes.

Even if the public key data was successfully parsed, should the
implementation consider the packet to be malformed and reject the key?
Or should the leftover data be considered optional and be ignored?  I
think it makes more sense to error out, but the RFC draft and mailing
list archives seem to be silent on this issue.

On a somewhat related note, are V3 partial-length headers limited to the
same context as V4 partial-length headers?  That is - are they allowed
only on data packets?

Thanks for your help!
~ Levi
Permalink | Reply | 10 comments |
headers
Ian G | 6 Jan 2007 15:09

Re: Packet length: header vs. context


Levi Broderick wrote:
> (resending, as the original message seems to be MIA)
> 
> Consider the following scenario:
> 
> An implementation is parsing a public-key packet.  The packet header
> gives a body length of 600 bytes; this is then buffered into memory.
> The software successfully parses all the data in the packet body -
> everything from the packet version number to the final MPI that it was
> expecting - and realizes that it has only read 400 bytes.
> 
> Even if the public key data was successfully parsed, should the
> implementation consider the packet to be malformed and reject the key?
> Or should the leftover data be considered optional and be ignored?  I
> think it makes more sense to error out, but the RFC draft and mailing
> list archives seem to be silent on this issue.

This sounds like one of those philosophical questions about 
coding, and it may be that the draft would be better off 
remaining silent on that question.

The GNU world characterised this as "be precise in what you 
send, be liberal in what you read."  That is, be 
accomodating when finding input.  In this context the answer 
to the above question is "accept the key."

I think it was Dan Bernstein (?) who said something 
different.  He said, "in security work, be precise in what 
you send, and precise in what you read."  So his answer
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jon Callas | 8 Jan 2007 00:00
Gravatar

Re: Packet length: header vs. context


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 6, 2007, at 6:09 AM, Ian G wrote:

>
> The GNU world characterised this as "be precise in what you send,  
> be liberal in what you read."  That is, be accomodating when  
> finding input.  In this context the answer to the above question is  
> "accept the key."
>

Postel said that, actually, long before there was any GNU except  
those one might find in a zoo.

	Jon

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.5.2
Charset: US-ASCII

wj8DBQFFoXufsTedWZOD3gYRArVjAJwOGc7rqz4tnrKfQ5m8g2ieXyHmpwCgjjWb
pvbDkcunuKDTEhMM4kHV4ug=
=YW3x
-----END PGP SIGNATURE-----
Permalink | Reply | 4 comments |
headers
Levi Broderick | 8 Jan 2007 00:19
Picon
Favicon

Re: Packet length: header vs. context


Ian G wrote:

> Finally, the ID has passed the point of minor tweaks.  We've been at
> this for a decade now.  No more changes please, seal the document and
> let's move on.  I vote NO to any changes, even without knowing what they
> are ;)

Of course!

The reason for my original question was that I was unsure if such a
packet could be used to undermine the security of any protocols in the
system.  Now that I think about it, though, I don't see how it could be
done.  It's unlike other attacks that use the software as an oracle
since public key information is - well - public. :)

~ Levi
Permalink | Reply | 2 comments |
headers
Jon Callas | 8 Jan 2007 00:56
Gravatar

Re: Packet length: header vs. context


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian touched on many of the salient points of this dilemma. The most  
correct answer to the problem you pose is "mu."

This is something that you have to make a personal decision on.

Let's suppose that the standard said something definitive on this.  
Many people have gotten into a lot of trouble by over-implementing  
standards. Let's suppose, for example, that you reject the key. Let's  
then suppose that someone finds that they can't import in keys that  
were created with software X on OS Y with a key size of a prime  
number of bits.

Well -- what do you do? There are people who want to use your code  
and can't, and it's not your fault. Screw 'em, they're the ones who  
got the standard wrong.

But when it turns out that the problem is that your software doesn't  
work with the new OpenPGP in Linux that runs underneath Windows  
Mobile Horizon that ships in the new Apple iTunesFone (when it  
creates keys 1987 bits long (selected because it's a prime number  
*and* the year programmer's GF was born -- cool, huh?)) and because  
of it, people can't download music from WalMart's GNU Music Share --  
well, the story on Slashdot is going to have *your* software's name  
on the headline, not theirs. You'll be changing your code to ignore  
that one extra byte because otherwise every phone in Korea has to be  
re-flashed, and it's faster for you to change than them. (Something
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jon Callas | 8 Jan 2007 01:07
Gravatar

Re: Packet length: header vs. context


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 7, 2007, at 3:19 PM, Levi Broderick wrote:

>
> The reason for my original question was that I was unsure if such a
> packet could be used to undermine the security of any protocols in the
> system.  Now that I think about it, though, I don't see how it  
> could be
> done.  It's unlike other attacks that use the software as an oracle
> since public key information is - well - public. :)

In the pre-OpenPGP protocols, there were "comment" packets. We  
removed them because people worried about them being a "covert"  
channel. I put "covert" in quotes because the specific case Jeff  
Schiller (then Security AD) gave was of an implementation that  
lowered the security to 40 bits by putting N-40 in a comment. This is  
also why the marker packet is defined the way it is.

I remember talking to Jeff and said that someone could stick anything  
in packet slack space. He said, "That's different. We shouldn't give  
a *defined* place for a covert channel." He was right.

A sufficiently devious person can put covert channels nearly  
anywhere. (This is why steganography isn't an interesting discipline.  
It's very easy to think of mats to leave keys under.) You could, for  
example, leak key bits or even code a secondary message in OpenPGP  
with partials. Imagine that each partial is a bit, denoted by log2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 8 Jan 2007 05:37
Picon
Picon
Picon
Favicon

Re: Packet length: header vs. context


Jon Callas <jon <at> callas.org> writes:
>On Jan 6, 2007, at 6:09 AM, Ian G wrote:
>> The GNU world characterised this as "be precise in what you send,
>> be liberal in what you read."  That is, be accomodating when
>> finding input.  In this context the answer to the above question is
>> "accept the key."
>
>Postel said that, actually, long before there was any GNU except those one
>might find in a zoo.

And before Jon Postel said that, the MIT hackers said "Look for anything that
says 'Don't to X', then try as many variations of X as possible.  "Postel's
Law" is great for interoperability, terrible for security.

Peter.
Permalink | Reply | 3 comments |
headers
Ian G | 8 Jan 2007 16:23

Re: Packet length: header vs. context


Levi Broderick wrote:
> Ian G wrote:
> 
>> Finally, the ID has passed the point of minor tweaks.  We've been at
>> this for a decade now.  No more changes please, seal the document and
>> let's move on.  I vote NO to any changes, even without knowing what they
>> are ;)
> 
> Of course!
> 
> The reason for my original question was that I was unsure if such a
> packet could be used to undermine the security of any protocols in the
> system.  Now that I think about it, though, I don't see how it could be
> done.

Always worth probing, as long as you don't mind the cringing 
of those fearful of yet more changes to the Doc :)

> It's unlike other attacks that use the software as an oracle
> since public key information is - well - public. :)

Just a minor quibble:  just because a key is named "public", 
it doesn't mean it is public.  The key marked as "public" is 
to be sent to your counterparty ... and we need to be 
careful to not confuse counterparty with "the whole world."

(I say this because I recently saw a discussion where a CA's 
criteria for audit specified that the public keys had to be 
published in public ... and the CA in question deliberately
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian G | 8 Jan 2007 17:55

Re: Packet length: header vs. context


Peter Gutmann wrote:
> Jon Callas <jon <at> callas.org> writes:
>> Postel said that, actually, long before there was any GNU except those one
>> might find in a zoo.
> 
> And before Jon Postel said that, the MIT hackers said "Look for anything that
> says 'Don't to X', then try as many variations of X as possible.  "Postel's
> Law" is great for interoperability, terrible for security.

Thanks guys, I stand corrected!  Perhaps it is better termed 
"Postel's Proposition" because of the rather large exception 
perhaps captured as "Bernstein's Anti-Corollary?"

I for one think that the Postel view is bad for 
interoperability as well because it leads to a loose and 
divergent community, which eventually leads to standards 
wars.  Oh joy...

iang
Permalink | Reply | 0 comments |
headers
Hal Finney | 8 Jan 2007 19:10

Re: Packet length: header vs. context


Levi Broderick wrote:
> (resending, as the original message seems to be MIA)
> 
> Consider the following scenario:
> 
> An implementation is parsing a public-key packet.  The packet header
> gives a body length of 600 bytes; this is then buffered into memory.
> The software successfully parses all the data in the packet body -
> everything from the packet version number to the final MPI that it was
> expecting - and realizes that it has only read 400 bytes.
> 
> Even if the public key data was successfully parsed, should the
> implementation consider the packet to be malformed and reject the key?
> Or should the leftover data be considered optional and be ignored?  I
> think it makes more sense to error out, but the RFC draft and mailing
> list archives seem to be silent on this issue.

I can tell you that the PGP parser does not check for excess data on
public key packets, but does check on secret key packets.  Secret key
packets have a checksum at the end and we make sure the checksum (i.e.
the remaining data after parsing all the MPIs) is the expected size.
We had some attacks involving weak checksums in the past, so we take
some care in this area.  But for public key packets we are not so careful.

However I think you could error out on public key packets with excess
data, without running into incompatibility problems.  I have never
noticed such public keys in my various debugging and dumping efforts
over the years.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane