Subject: Protect your RegionsNet® against phishing scams by activate Anti-Theft Program

From: "Regions Bank"<[email-masked]>
Date: Wed, 31 Jan 2007 16:59:55 -0500

MEMBER NOTICE:

Currently we are trying to upgrade RegionsNet® Online Accounts for security measures.
Anti-Theft Program will allow us to verify your identity from your computer, at home, at work, anywhere. When you access your account we'll know it's you. With our new Anti-Theft Program you are helping not only yourself but also Regions bank. We apreciate your support and understanding our banking method authentications.

Businesses are continually concerned about the ever increasing sophistication in the types of frauds that are being committed today. Many of these frauds begin with the theft of private information. Business Authentication allows us to provide additional protection and enables you to have further control over the type of information or transactions accessed by your employees.

Please Note: Regions Bank will never ask for your Personal Identification Number via e-mail or phone.

Activate Anti-Theft Program and confirm the authentication procedure by following the link below.

https://secure.regionsnet.com/EBanking/logon/user?a=

2007 © Regions Bank - RegionsNet® Online Member FDIC. Equal Housing Lender
.
.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0I8psXv040135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 01:51:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0I8psH8040134; Thu, 18 Jan 2007 01:51:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0I8pmf3040125 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 18 Jan 2007 01:51:52 -0700 (MST) (envelope-from [email-masked])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1H7T80-0008Lv-Qd for ; Thu, 18 Jan 2007 10:00:12 +0100
Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1H7SxK-0006fO-Jt; Thu, 18 Jan 2007 09:49:11 +0100
From: Werner Koch
To:
Cc:
Subject: Re: Multiple encryption subkeys
References: <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Thu, 18 Jan 2007 09:49:10 +0100
In-Reply-To: <[email-masked]> ([email-masked]'s message of "Wed\, 17 Jan 2007 18\:22\:28 -0500")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110006 (No Gnus v0.6)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Thu, 18 Jan 2007 00:22, [email-masked] said:

> i couldn't find it in the manpage for 1.4.5 or 1.4.6
> (and did a search for all '!'
> and looked at all the instances of '!'
> and the quote you mentioned isn't there)

It changed to this:

When using gpg an exclamation mark may be appended to force
using the specified primary or secondary key and not to try and
calculate which primary or secondary key to use.

However this is a bit off-topic.

Salam-Shalom,

Werner

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HNMW2e001363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 16:22:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0HNMW5X001357; Wed, 17 Jan 2007 16:22:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HNMUD4001349 for ; Wed, 17 Jan 2007 16:22:30 -0700 (MST) (envelope-from [email-masked])
Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 9ADA0A3272 for ; Wed, 17 Jan 2007 15:22:29 -0800 (PST)
Received: from mailserver9.hushmail.com (mailserver9.hushmail.com [65.39.178.63]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Wed, 17 Jan 2007 15:22:29 -0800 (PST)
Received: by mailserver9.hushmail.com (Postfix, from userid 65534) id E9DE622840; Wed, 17 Jan 2007 15:22:28 -0800 (PST)
Date: Wed, 17 Jan 2007 18:22:28 -0500
To:
Cc:
Subject: Re: Multiple encryption subkeys
From:
Content-type: text/plain; charset="UTF-8"
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Wed, 17 Jan 2007 17:49:31 -0500 Ingo KlГ¶cker
wrote:

>> (iirc, it's still not in the gpg manpage ;-) ),
>
>Fresh from the gpg manpage (version 1.4.2):
>
>Note that you can append an exclamation mark (!) to key IDs or
>fingerprints. This flag tells GnuPG to use the specified primary
>or
>secondary key and not to try and calculate which primary or
>secondary
>key to use.

hmm,

i don't have the docs for 1.4.2 anymore ...

i couldn't find it in the manpage for 1.4.5 or 1.4.6
(and did a search for all '!'
and looked at all the instances of '!'
and the quote you mentioned isn't there)

is there a different manpage (gpg.man) for windows and for linux?

tia,

vedaal

Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HMnuQj099016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 15:49:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0HMnu44099015; Wed, 17 Jan 2007 15:49:56 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HMnqMr099001 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 17 Jan 2007 15:49:56 -0700 (MST) (envelope-from [email-masked])
Received: from r220-1 ([134.130.3.31]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <[email-masked]> for [email-masked]; Wed, 17 Jan 2007 23:49:37 +0100 (CET)
Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Wed, 17 Jan 2007 23:49:37 +0100 (MET)
Received: from localhost (demeter.matha.RWTH-Aachen.DE [134.130.160.142]) by relay.rwth-aachen.de (8.13.7/8.13.3/1) with ESMTP id l0HMnaCp005127 for ; Wed, 17 Jan 2007 23:49:36 +0100 (MET)
Date: Wed, 17 Jan 2007 23:49:31 +0100
From: Ingo =?utf-8?q?Kl=C3=B6cker?=
Subject: Re: Multiple encryption subkeys
In-reply-to: <[email-masked]>
To: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
Content-type: multipart/signed; boundary=nextPart3727048.X05QCuNodH; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-transfer-encoding: 7bit
References: <[email-masked]>
User-Agent: KMail/1.9.5
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--nextPart3727048.X05QCuNodH
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 17 January 2007 21:18, [email-masked] wrote:
> On Wed, 17 Jan 2007 12:34:15 -0500 Hal Finney
>
> wrote:
> >Hmmm, I don't see the interop question here. Choosing which keys
> >to
> >encrypt to is entirely between the user and his software.
>
> well,
> there is 'sort-of' more of an annoyance issue, rather than a
> 'problem'
> and purely an implementation one, not an issue with the rfc
>
> >Daniel Nagy writes:
> >> The standard, as it stands right now, says nothing about dealing
> >
> >with
> >
> >> multiple encryption subkeys. I think, this is something that
> >
> >affects
> >
> >> interoperability and thus merits a few sentences in the
> >
> >standard.
> >
> >> GPG assumes that the one with the latest valid subkey binding
> >
> >signature is
> >
> >> the one that should be used when encrypting to the given primary
> >
> >key. I
> >
> >> think, this is wrong, because it makes multiple subkeys useless
> >
> >and
> >
> >> confusing,
>
> gnupg allows encrypting to 'any' subkey, earlier or later,
> simply by adding a ! after the keyid (by number, not name) of the
> preferred subkey,
> e.g.:
>
> gpg -r 12345678! -e filename
>
> the issue is that gnupg, by default, will choose the 'latest'
> subkey,
> when the command is:
>
> gpg -r username -e filename
>
> (assuming, actually quite understandably, that if the key owner
> went through the trouble of making a new subkey, there was probably
> a good reason for it,)
>
> now, since not everyone has this new subkey yet,
> and when someone who doesn't have it yet, receives an e-mail self-
> encrypted by default, to the sender's new subkey,
> and if also, the sender has not yet uploaded this subkey,
> and also, didn't inform the receiver of the new key,
> then the receiver 'might' be confused as to why it is not encrypted
> to the encrypting subkeys he/she has for that sender
>
> other than that,
> i don't see any other problem with this
>
> the receiver has a choice to encrypt to any subkey,
> any the only implementation issue,
> is perhaps to make this '!' option
> more clearly documented
> (iirc, it's still not in the gpg manpage ;-) ),

=46resh from the gpg manpage (version 1.4.2):

Note that you can append an exclamation mark (!) to key IDs or=20
fingerprints. This flag tells GnuPG to use the specified primary or=20
secondary key and not to try and calculate which primary or secondary=20
key to use.

Regards,
Ingo

--nextPart3727048.X05QCuNodH
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBFrqf9GnR+RTDgudgRAuXUAJ4wUOrTenXBZR+CZOdNMy704tumcwCg3696
433gCJgmA7Dr6nmD0j+yTkw=
=/mdE
-----END PGP SIGNATURE-----

--nextPart3727048.X05QCuNodH--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HKIsR1089541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 13:18:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0HKIs1a089540; Wed, 17 Jan 2007 13:18:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HKIrGT089533 for ; Wed, 17 Jan 2007 13:18:53 -0700 (MST) (envelope-from [email-masked])
Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 34F01A327A for ; Wed, 17 Jan 2007 12:18:50 -0800 (PST)
Received: from mailserver9.hushmail.com (mailserver9.hushmail.com [65.39.178.63]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Wed, 17 Jan 2007 12:18:49 -0800 (PST)
Received: by mailserver9.hushmail.com (Postfix, from userid 65534) id C2D342283E; Wed, 17 Jan 2007 12:18:49 -0800 (PST)
Date: Wed, 17 Jan 2007 15:18:49 -0500
To:
Cc:
Subject: Re: Multiple encryption subkeys
From:
Content-type: text/plain; charset="UTF-8"
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Wed, 17 Jan 2007 12:34:15 -0500 Hal Finney
wrote:

>Hmmm, I don't see the interop question here. Choosing which keys
>to
>encrypt to is entirely between the user and his software.

well,
there is 'sort-of' more of an annoyance issue, rather than a
'problem'
and purely an implementation one, not an issue with the rfc

>Daniel Nagy writes:
>> The standard, as it stands right now, says nothing about dealing
>with
>> multiple encryption subkeys. I think, this is something that
>affects
>> interoperability and thus merits a few sentences in the
>standard.
>>
>> GPG assumes that the one with the latest valid subkey binding
>signature is
>> the one that should be used when encrypting to the given primary
>key. I
>> think, this is wrong, because it makes multiple subkeys useless
>and
>> confusing,

gnupg allows encrypting to 'any' subkey, earlier or later,
simply by adding a ! after the keyid (by number, not name) of the
preferred subkey,
e.g.:

gpg -r 12345678! -e filename

the issue is that gnupg, by default, will choose the 'latest'
subkey,
when the command is:

gpg -r username -e filename

(assuming, actually quite understandably, that if the key owner
went through the trouble of making a new subkey, there was probably
a good reason for it,)

now, since not everyone has this new subkey yet,
and when someone who doesn't have it yet, receives an e-mail self-
encrypted by default, to the sender's new subkey,
and if also, the sender has not yet uploaded this subkey,
and also, didn't inform the receiver of the new key,
then the receiver 'might' be confused as to why it is not encrypted
to the encrypting subkeys he/she has for that sender

other than that,
i don't see any other problem with this

the receiver has a choice to encrypt to any subkey,
any the only implementation issue,
is perhaps to make this '!' option
more clearly documented
(iirc, it's still not in the gpg manpage ;-) ),
or,
when encrypting by username,
for gnupg to prompt:
'select subkey' (and list the keys, sizes, and creation dates)

either way,
an 'implementation' issue.

vedaal

Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HHj6w6078568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 10:45:06 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0HHj60U078566; Wed, 17 Jan 2007 10:45:06 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HHj4gD078559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 17 Jan 2007 10:45:05 -0700 (MST) (envelope-from [email-masked])
Received: by finney.org (Postfix, from userid 500) id BF6DB14F6BC; Wed, 17 Jan 2007 09:34:15 -0800 (PST)
To: [email-masked], [email-masked]
Subject: Re: Multiple encryption subkeys
Message-Id: <[email-masked]>
Date: Wed, 17 Jan 2007 09:34:15 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hmmm, I don't see the interop question here. Choosing which keys to
encrypt to is entirely between the user and his software. The only
interop issue would be that someone should be able to decrypt when he
has a valid decryption key. Maybe there's something I'm missing though?

Hal Finney

Daniel Nagy writes:
> The standard, as it stands right now, says nothing about dealing with
> multiple encryption subkeys. I think, this is something that affects
> interoperability and thus merits a few sentences in the standard.
>
> GPG assumes that the one with the latest valid subkey binding signature is
> the one that should be used when encrypting to the given primary key. I
> think, this is wrong, because it makes multiple subkeys useless and
> confusing, while there would be better and more useful ways of interpreting
> multiple encryption subkeys.
>
> IMHO, the best way would be to encrypt with ALL the valid subkeys, because
> it allows for havind different decryption subkeys on different machines
> (just like with signature subkeys) that can be revoked/expired separately.
>
> Also, it would make it possible to create encrypted mailing lists with
> minimum effort: the list administrator has access to the main key of the
> mailing list and can add/revoke the encryption subkeys of the subscribers as
> they sign up and off. Those who wish to post to the list will only need to
> encrypt with to the list key, which is what their client will do
> automagically, if they turn encryption on. It is the users' responsibility
> to refresh the list key frequently, though the list itself is a good medium
> for distributing updates to the key as they happen.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HEwU29065708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 07:58:30 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0HEwU7w065707; Wed, 17 Jan 2007 07:58:30 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HEwStV065700 for ; Wed, 17 Jan 2007 07:58:29 -0700 (MST) (envelope-from [email-masked])
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 509B13C93; Wed, 17 Jan 2007 15:58:27 +0100 (CET)
Date: Wed, 17 Jan 2007 15:58:27 +0100
To: [email-masked]
Subject: Multiple encryption subkeys
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TiqCXmo5T1hvSQQg"
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--TiqCXmo5T1hvSQQg
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

The standard, as it stands right now, says nothing about dealing with
multiple encryption subkeys. I think, this is something that affects
interoperability and thus merits a few sentences in the standard.

GPG assumes that the one with the latest valid subkey binding signature is
the one that should be used when encrypting to the given primary key. I
think, this is wrong, because it makes multiple subkeys useless and
confusing, while there would be better and more useful ways of interpreting
multiple encryption subkeys.

IMHO, the best way would be to encrypt with ALL the valid subkeys, because
it allows for havind different decryption subkeys on different machines
(just like with signature subkeys) that can be revoked/expired separately.

Also, it would make it possible to create encrypted mailing lists with
minimum effort: the list administrator has access to the main key of the
mailing list and can add/revoke the encryption subkeys of the subscribers as
they sign up and off. Those who wish to post to the list will only need to
encrypt with to the list key, which is what their client will do
automagically, if they turn encryption on. It is the users' responsibility
to refresh the list key frequently, though the list itself is a good medium
for distributing updates to the key as they happen.

Just my =E2=82=AC0.02 ...
Cheers,

--=20
Daniel

--TiqCXmo5T1hvSQQg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iQDVAwUBRa45k66pEulQFnIMAQKNzgX/dKj5M/kCoqrglv5abhI8BOKhyWSNEkcl
g26fgamI31x4PPSiGgT2Cg4Kjy3mi+/eohzeKBRZSBfhermYn1A0p5macqdv1WCq
TE1R0FP59fDtcto3XqDgqC864V3Wlys+dWnHB5XFMVdxUrVF5L4M8KXof4BejLw+
SKEzZBSSwAjiMnCxJMb5aPYcEOzGiqCya0Ay1x06W7WBbUnNJLHE5DGvvtb1pDVQ
O9grYlbeWmq8I6fTdovxThvlZIoYy6oh
=s2X6
-----END PGP SIGNATURE-----

--TiqCXmo5T1hvSQQg--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l090Zkfs087351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jan 2007 17:35:46 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l090Zk9V087350; Mon, 8 Jan 2007 17:35:46 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from merrymeet.com (dsl093-068-160.sfo1.dsl.speakeasy.net [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l090ZiET087344 for ; Mon, 8 Jan 2007 17:35:45 -0700 (MST) (envelope-from [email-masked])
Received: from keys.merrymeet.com (dsl093-068-161.sfo1.dsl.speakeasy.net [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 714C246E8CD for ; Mon, 8 Jan 2007 16:35:44 -0800 (PST)
Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 08 Jan 2007 16:35:44 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 08 Jan 2007 16:35:44 -0800
In-Reply-To:
References:
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <[email-masked]>
Cc: OpenPGP
From: Jon Callas
Subject: Re: Packet length: header vs. context
Date: Mon, 8 Jan 2007 16:35:02 -0800
To: Peter Gutmann
X-Mailer: Apple Mail (2.752.3)
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7BIT
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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

On Jan 7, 2007, at 8:37 PM, Peter Gutmann wrote:

>
> 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.
>

I'll disagree just a bit, Peter, because one of the best ways to get
security is a lack of interoperability. Rip your network cable out of
the wall and you have great security.

Yes, if you maximize interoperability, it has effects on security.
Yes, you can come up with an interoperability hack that is cringe-
worthy from a security standpoint. Yes, the Internet as we know it is
riddled with them. But the Internet as we know it out-competed other,
more secure systems, and succeeded against them because it viewed
interoperability as the primary virtue (and had an attitude about
security that included lines like, "polite clients don't *do* that").

"Postel's Law" is a valuble rule of thumb. You *should* (maybe that
should be SHOULD) be conservative in what you generate and liberal in
what you accept. It just shouldn't override everything else. The more
that the rough consensus of implementors succeeds at the former, the
less it needs to do of the latter. Writing software is an art, not a
state machine. It needs wisdom.

The example we got here was a good one because there's no obvious
most right answer. My opinion is that the best answer is to fix up
the bad data and proceed. That has its own drawbacks. Just accepting
it is probably worst, but rejecting it isn't that much better.

Interoperability matters. Without it, we don't need security.

Jon

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

wj8DBQFFouNgsTedWZOD3gYRAuzyAJ9iqDne/UTQl+14S6X5muT0eNzlnACg4j4l
o3rr5YbHfS9vy52V3Rf35T8=
=TLKD
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l08ILX1H060650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jan 2007 11:21:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l08ILXhd060649; Mon, 8 Jan 2007 11:21:33 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l08ILVHs060643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jan 2007 11:21:32 -0700 (MST) (envelope-from [email-masked])
Received: by finney.org (Postfix, from userid 500) id B7C9A14F6BC; Mon, 8 Jan 2007 10:10:08 -0800 (PST)
To: [email-masked]
Subject: Re: Packet length: header vs. context
Message-Id: <[email-masked]>
Date: Mon, 8 Jan 2007 10:10:08 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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.

Hal

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l08Gteea053904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jan 2007 09:55:40 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l08Gtene053903; Mon, 8 Jan 2007 09:55:40 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from www2.futureware.at ([217.19.43.211]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l08GtdYV053897 for ; Mon, 8 Jan 2007 09:55:39 -0700 (MST) (envelope-from [email-masked])
Received: from [127.0.0.1] (localhost [127.0.0.1]) by www2.futureware.at (Postfix) with ESMTP id 49D4A2262E6 for ; Mon, 8 Jan 2007 17:55:42 +0100 (CET)
Message-ID: <[email-masked]>
Date: Mon, 08 Jan 2007 17:55:53 +0100
From: Ian G
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Packet length: header vs. context
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Peter Gutmann wrote:
> Jon Callas 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

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l08FMrA5047096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jan 2007 08:22:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l08FMrOJ047095; Mon, 8 Jan 2007 08:22:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from www2.futureware.at ([217.19.43.211]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l08FMqCq047087 for ; Mon, 8 Jan 2007 08:22:52 -0700 (MST) (envelope-from [email-masked])
Received: from [127.0.0.1] (localhost [127.0.0.1]) by www2.futureware.at (Postfix) with ESMTP id 4AF5F2262DE; Mon, 8 Jan 2007 16:22:54 +0100 (CET)
Message-ID: <[email-masked]>
Date: Mon, 08 Jan 2007 16:23:05 +0100
From: Ian G
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Levi Broderick
Cc: [email-masked]
Subject: Re: Packet length: header vs. context
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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
does not publish public keys ... because that might breach
privacy rules ... )

iang

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l084bROC000123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jan 2007 21:37:27 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l084bRUK000122; Sun, 7 Jan 2007 21:37:27 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from harpo.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l084bP19099976 for ; Sun, 7 Jan 2007 21:37:26 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 8C7E734544; Mon, 8 Jan 2007 17:37:24 +1300 (NZDT)
Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07276-09; Mon, 8 Jan 2007 17:37:24 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id BED1534528; Mon, 8 Jan 2007 17:37:22 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id E4CC01280AB; Mon, 8 Jan 2007 17:37:20 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1H3mGE-0006wa-00; Mon, 08 Jan 2007 17:37:26 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Packet length: header vs. context
Cc: [email-masked], [email-masked]
In-Reply-To:
Message-Id:
Date: Mon, 08 Jan 2007 17:37:26 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Jon Callas 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.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0807fRN084648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jan 2007 17:07:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0807fW1084647; Sun, 7 Jan 2007 17:07:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from merrymeet.com (dsl093-068-160.sfo1.dsl.speakeasy.net [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0807eT5084640 for ; Sun, 7 Jan 2007 17:07:41 -0700 (MST) (envelope-from [email-masked])
Received: from keys.merrymeet.com (dsl093-068-161.sfo1.dsl.speakeasy.net [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 5943F469170 for ; Sun, 7 Jan 2007 16:07:40 -0800 (PST)
Received: from [66.93.68.165] ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Sun, 07 Jan 2007 16:07:40 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 07 Jan 2007 16:07:40 -0800
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-Id: <[email-masked]>
From: Jon Callas
Subject: Re: Packet length: header vs. context
Date: Sun, 7 Jan 2007 16:07:39 -0800
To: OpenPGP
X-Mailer: Apple Mail (2.752.3)
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7BIT
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----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
(size) & 1. Whee.

Jon

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

wj8DBQFFoYtMsTedWZOD3gYRAjCiAJ42W7RYoN+KZ63mZUxypbiHcLrzvwCfXZgh
CMmAF1nfvL1k9zUQKkUIiJ8=
=G8Mw
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l07NuBh8084007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jan 2007 16:56:11 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l07NuBeC084006; Sun, 7 Jan 2007 16:56:11 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from merrymeet.com (dsl093-068-160.sfo1.dsl.speakeasy.net [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l07NuAgb084000 for ; Sun, 7 Jan 2007 16:56:10 -0700 (MST) (envelope-from [email-masked])
Received: from keys.merrymeet.com (dsl093-068-161.sfo1.dsl.speakeasy.net [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id DED474690D3 for ; Sun, 7 Jan 2007 15:56:09 -0800 (PST)
Received: from [66.93.68.165] ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Sun, 07 Jan 2007 15:56:09 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 07 Jan 2007 15:56:09 -0800
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id:
Cc: [email-masked]
From: Jon Callas
Subject: Re: Packet length: header vs. context
Date: Sun, 7 Jan 2007 15:56:08 -0800
To: Levi Broderick
X-Mailer: Apple Mail (2.752.3)
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7BIT
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----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
similar to this happened to PGP once, but I changed the name of the
country in my explanation.)

An alternative to just accepting that packet would be to lop off the
extra data (which will be ignored), and make the length correct.

When you implement a protocol, there are often more choices than
being anal or passing idiocy through. In the one you've given, it's
almost certainly true that you can tweak the packet to the right size
and not affect anything else. So why not do so?

It might also be a good thing to tell the people who are doing
something dumb that they're doing something dumb, but don't expect
them to fix it tomorrow, especially since there's a workaround. When
it's been a couple of years and no fix has arrived, you have earned
the right to be snarky, but by then you probably forgot the
workaround you put in your code, too.

As for your second question -- where partial lengths can be used --
what's your real question? Do you want to use them in places other
than data packets? Is someone subjecting you to them and it's a pain
in the neck to parse them?

It's Sunday afternoon and I need to run some errands, so I don't want
to go crawl through the spec. I *believe* that they can be used
anywhere. But I also believe they shouldn't be used everywhere. In
the case of a 400-byte packet header, whatever would possess someone
to do that? Yeah, I'm sure it's legal, but don't do it. If it's the
software I'm responsible for that's doing something cringe-worthy,
I'm sorry.

Partial lengths exist so that you can process arbitrarily large
chunks of data that don't fit in memory and might even be
inconvenient for you to know the size of a priori. That really means
data packets. However, as a software engineer, I think that even if
some idiot chopped up a 400-byte key packet into 2-byte partials,
your software ought to work. If it doesn't, you have to consider who
the idiot is. That brings us back to the original consideration.
Welcome to being a software engineer. Sometimes the things we have to
do because other people are idiots suck. A sense of humor helps deal
with it, but doesn't prevent it from sucking.

Jon

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

wj8DBQFFoYiZsTedWZOD3gYRAjbyAJwLiOgAYYHSjANqhkaPDpKZ9V1b8QCgpFr3
eLbCx4/y6vWM8hIeqYHNh9k=
=jbmi
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l07NKd6K081750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jan 2007 16:20:39 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l07NKd9W081749; Sun, 7 Jan 2007 16:20:39 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l07NKZ2H081741 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 7 Jan 2007 16:20:36 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.1.113] (user-24-214-137-62.knology.net [24.214.137.62]) (user=lpb mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id l07NKVKh021231 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 7 Jan 2007 18:20:34 -0500
Message-ID: <[email-masked]>
Date: Sun, 07 Jan 2007 17:19:58 -0600
From: Levi Broderick
Organization: Carnegie Mellon University
User-Agent: Thunderbird 2.0b1 (Windows/20061224)
MIME-Version: 1.0
To: Ian G
CC: [email-masked]
Subject: Re: Packet length: header vs. context
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.94.1.2.0
OpenPGP: id=3FE7C25A; url=http://www.contrib.andrew.cmu.edu/~lpb/pubkey.asc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 128.2.10.81
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l07N0nKW080837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jan 2007 16:00:49 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l07N0ncZ080836; Sun, 7 Jan 2007 16:00:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from merrymeet.com (dsl093-068-160.sfo1.dsl.speakeasy.net [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l07N0mrE080830 for ; Sun, 7 Jan 2007 16:00:48 -0700 (MST) (envelope-from [email-masked])
Received: from keys.merrymeet.com (dsl093-068-161.sfo1.dsl.speakeasy.net [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id B025D468E05 for ; Sun, 7 Jan 2007 15:00:47 -0800 (PST)
Received: from [66.93.68.165] ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Sun, 07 Jan 2007 15:00:47 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 07 Jan 2007 15:00:47 -0800
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id:
Cc: Levi Broderick , [email-masked]
From: Jon Callas
Subject: Re: Packet length: header vs. context
Date: Sun, 7 Jan 2007 15:00:44 -0800
To: Ian G
X-Mailer: Apple Mail (2.752.3)
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7BIT
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----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-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l06E9aeX082089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jan 2007 07:09:36 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l06E9adS082088; Sat, 6 Jan 2007 07:09:36 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from www2.futureware.at ([217.19.43.211]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l06E9YLX082079 for ; Sat, 6 Jan 2007 07:09:35 -0700 (MST) (envelope-from [email-masked])
Received: from [127.0.0.1] (localhost [127.0.0.1]) by www2.futureware.at (Postfix) with ESMTP id B85DC226222; Sat, 6 Jan 2007 15:09:36 +0100 (CET)
Message-ID: <[email-masked]>
Date: Sat, 06 Jan 2007 15:09:44 +0100
From: Ian G
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Levi Broderick
Cc: [email-masked]
Subject: Re: Packet length: header vs. context
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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
would be "reject the key."

I like the second answer for security work, but OpenPGP is
somewhat in between these worlds; there are several
implementations and they all have foibles, and the coding
history goes back a long time. It is a fact of life that
there have been "disagreements" on how to interpret certain
things, and differing implementations have had to deal with
it; we can't just "start again" with all the implementations.

How to deal with that world? I would say that (a) your
market will tell you, and (b) you might want a third mode of
"accept but warn" alongside "reject" and "accept."

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 ;)

iang

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l05M67qI032920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jan 2007 15:06:07 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l05M67pB032919; Fri, 5 Jan 2007 15:06:07 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.82]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l05M65ej032912 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 5 Jan 2007 15:06:07 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.1.113] (user-24-214-137-62.knology.net [24.214.137.62]) (user=lpb mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id l05M63uu004130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 5 Jan 2007 17:06:05 -0500
Message-ID: <[email-masked]>
Date: Fri, 05 Jan 2007 16:05:57 -0600
From: Levi Broderick
Organization: Carnegie Mellon University
User-Agent: Thunderbird 2.0b1 (Windows/20061224)
MIME-Version: 1.0
To: [email-masked]
Subject: Packet length: header vs. context
X-Enigmail-Version: 0.94.1.2.0
OpenPGP: id=3FE7C25A; url=http://www.contrib.andrew.cmu.edu/~lpb/pubkey.asc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 128.2.10.82
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

(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