Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt

Eric Rescorla <> Sat, 01 July 2006 15:13 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FwhAJ-0004K4-9s; Sat, 01 Jul 2006 11:13:47 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1FwhAI-0004Jz-9u for; Sat, 01 Jul 2006 11:13:46 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1FwhAH-00080z-Kz for; Sat, 01 Jul 2006 11:13:46 -0400
Received: by (Postfix, from userid 1001) id 42E7C1E8C1C; Sat, 1 Jul 2006 08:13:44 -0700 (PDT)
To: "Kyle Hamilton" <>
Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt
References: <> <> <p06230904c0c9842d3069@> <> <>
From: Eric Rescorla <>
Date: Sat, 01 Jul 2006 08:13:44 -0700
In-Reply-To: <> (Kyle Hamilton's message of "Sat, 1 Jul 2006 04:36:38 -0700")
Message-ID: <>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

"Kyle Hamilton" <> writes:

> On 7/1/06, Nikos Mavrogiannopoulos <> wrote:
>> Maybe the wording wasn't clear. Would an update to the security
>> considerations text like the one below be more clear to you?
>>          Security considerations about the use of the web of trust or
>>          the key verification procedure are outside the scope of this
>>          document and are considered issues to be handled by the
>>          application layer protocols.
> Security considerations that have anything to do with identity key
> verification and entity mapping (pre-shared keys, PKIX, web-of-trust),
> and the corresponding authorization to use the application being
> protected, are outside the scope of this document.  These are
> considered issues to be handled by the application layer protocols, or
> at the very least by the TLS implementation in accordance with
> key-interpretation protocols that are separately described.

I don't think any of the below material is really relevant
here. It's just boilerplate that applies to any crypto

> The use of cryptographic keys, and the cryptographic keys so used, can
> be exposed through a kernel or process memory dump or process
> debugging feature of many operating systems. This means that any
> entity who has access to kernel memory, process debugging, or perhaps
> even process-listing facilities may be able to subvert the entity
> identification procedures, and may be able to decrypt the data within
> any TLS session identified and authenticated with that private key if
> it is captured through such mechanisms.  In addition, identity key
> processing and storage may be compromised through insecure backup
> procedures, insecure passing of identity key decryption information to
> processes, non-reset (i.e., non-zeroed) contents of memory blocks
> being allocated to other processes, privileged or physical access to
> the machine that the TLS implementation is running on, and other ways.
>  These are issues which are implementation-specific, and only very
> basic suggestions can be given.
> For example, not all operating systems properly clear memory (or
> paging files) which is paged out or upon release of memory by a
> process back to the system.  This suggests that identity key and
> session information could be kept in memory or on disk indefinitely.
> Because of this, applications and implementations should take care to
> clear or completely randomize any memory which contains key
> information when it is no longer needed, and to prevent paging of the
> key information if at all possible.  If session information is cached
> (for example, to a database of some kind which can be used by other
> processes), it may be cached in a place where the implementation
> cannot exert complete control over the storage used.  It is likely
> best in these situations to encrypt session data with a locally-known
> symmetric key [or perhaps a hybrid approach utilizing the public key
> corresponding to the private key used for identity] before writing it
> to the cache.  This is particularly important with network-based
> caching systems, as database implementations may not adequately
> encrypt the data for transport and the network should be viewed as
> "insecure" as practically possible.
> As well, once sessions expire their data should be removed from the
> cache as soon as possible, in a manner designed to overwrite that data
> as destructively as possible.  (For example, one could use an
> autocommited UPDATE command in SQL, and only then issue an
> autocommitted DELETE FROM command.  This will not work with databases
> that have recovery capabilities, though, and application
> administrators are encouraged to look for means of forcing full
> commission and data backup from such databases' log files to the main
> database so that those log files may be removed as soon as practical.)
> At any time, specific algorithms may be discovered to have flaws.  (At
> the time of this writing, the MD5 hash function is known to have
> serious weaknesses which permit an attacker to create hash collisions
> in a matter of seconds, and the same methods used to discover this
> attack are being utilized against other hashing algorithms.)
> Implementors and application administrators are encouraged to keep an
> eye on the cryptographic state of the art, and regularly review the
> security policies implemented within their software and on their
> hosts.
> Implementations with poor random number generation capabilities are
> known to have much more vulnerability, as the random numbers generated
> could have many fewer possible values than implementations with better
> random number generators.  It is generally recommended to use a
> physical source of entropy (geiger-counted emissions, aerodynamic and
> thermodynamic properties of devices which produce unpredictable
> results, ambient room noise, and many others) when at all possible.
> It is VITAL that implementations NEVER REUSE ANY GIVEN ENTROPY, to
> make symmetric key-guessing and asymmetric private key calculation at
> least as difficult as the number of bits held within the key.

This is duplicative of RFC 1984.

> Certain algorithms have "weak keys", and implementations of those
> algorithms should check generated keys against them and reject them as
> candidates for usage.

In particular, this advice does not match with current TLS practice,
which is NOT to check for weak keys.

> The RSA asymmetric encryption system is known to be vulnerable to
> advances in factoring large numbers.  In particular, the General
> Number Field Seive is being advanced slowly but inexorably.  It is
> recommended that implementations move away from RSA for identity keys.

I don't agree with this recommendation.


TLS mailing list