Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt
Eric Rescorla <ekr@networkresonance.com> Sat, 01 July 2006 15:13 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwhAJ-0004K4-9s; Sat, 01 Jul 2006 11:13:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwhAI-0004Jz-9u for tls@ietf.org; Sat, 01 Jul 2006 11:13:46 -0400
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwhAH-00080z-Kz for tls@ietf.org; Sat, 01 Jul 2006 11:13:46 -0400
Received: by raman.networkresonance.com (Postfix, from userid 1001) id 42E7C1E8C1C; Sat, 1 Jul 2006 08:13:44 -0700 (PDT)
To: Kyle Hamilton <aerowolf@gmail.com>
Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt
References: <20060626203923.59F81222426@laser.networkresonance.com> <200606290020.10111.nmav@gnutls.org> <p06230904c0c9842d3069@128.89.89.106> <200607010918.21080.nmav@gnutls.org> <6b9359640607010436l4728792qdfd988762d804fe2@mail.gmail.com>
From: Eric Rescorla <ekr@networkresonance.com>
Date: Sat, 01 Jul 2006 08:13:44 -0700
In-Reply-To: <6b9359640607010436l4728792qdfd988762d804fe2@mail.gmail.com> (Kyle Hamilton's message of "Sat, 1 Jul 2006 04:36:38 -0700")
Message-ID: <86wtaxmk7r.fsf@raman.networkresonance.com>
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
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
"Kyle Hamilton" <aerowolf@gmail.com> writes: > On 7/1/06, Nikos Mavrogiannopoulos <nmav@gnutls.org> 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 protocol > 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. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Re: Russ Housley: Fwd: problems with draft-… Nikos Mavrogiannopoulos
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Anyang Ren
- [TLS] Re: Russ Housley: Fwd: problems with draft-… Nikos Mavrogiannopoulos
- Re: [TLS] Re: Russ Housley: Fwd: problems with Martin Rex
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Eric Rescorla
- [TLS] Re: Russ Housley: Fwd: problems with draft-… Nikos Mavrogiannopoulos
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Kyle Hamilton
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Eric Rescorla
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Kyle Hamilton
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Eric Rescorla
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Steven M. Bellovin
- Re: [TLS] Re: Russ Housley: Fwd: problems with Eric Rescorla
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Nelson B Bolyard