Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt
"Kyle Hamilton" <aerowolf@gmail.com> Sat, 01 July 2006 11:49 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwdym-0000lh-3H; Sat, 01 Jul 2006 07:49:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwdyl-0000lP-Ff for tls@ietf.org; Sat, 01 Jul 2006 07:49:39 -0400
Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwdmB-00089H-Nv for tls@ietf.org; Sat, 01 Jul 2006 07:36:42 -0400
Received: by nf-out-0910.google.com with SMTP id g2so425477nfe for <tls@ietf.org>; Sat, 01 Jul 2006 04:36:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PX7G3MRVfbbCNSkCSwlzIPI5IXuMGNQyJ2q+YG7Lc2ZAQ6QY/S5BLjgEUCznEU9LJoaI32MvQ5SMMCV/U8HJWukD2pBcdq7EiGlehOzFnfgzYlcKpsbxtJqnIZzu45K6w8idf2Yepeg8EXDrrJBjxOxJwPOF3P2eTW1TNa7EcR4=
Received: by 10.48.43.11 with SMTP id q11mr943008nfq; Sat, 01 Jul 2006 04:36:38 -0700 (PDT)
Received: by 10.48.164.3 with HTTP; Sat, 1 Jul 2006 04:36:38 -0700 (PDT)
Message-ID: <6b9359640607010436l4728792qdfd988762d804fe2@mail.gmail.com>
Date: Sat, 01 Jul 2006 04:36:38 -0700
From: Kyle Hamilton <aerowolf@gmail.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>, tls@ietf.org
Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt
In-Reply-To: <200607010918.21080.nmav@gnutls.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20060626203923.59F81222426@laser.networkresonance.com> <200606290020.10111.nmav@gnutls.org> <p06230904c0c9842d3069@128.89.89.106> <200607010918.21080.nmav@gnutls.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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
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. 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. Certain algorithms have "weak keys", and implementations of those algorithms should check generated keys against them and reject them as candidates for usage. 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. Certain jurisdictions require the use of a limited set of algorithms (for example, the US Federal Government requires the use of AES for symmetric key operations, and a specific PNRG for random number generation). Implementations should allow the application administrator to remove supported cipher suites or to add only a specific list of known-good cipher suites for use, and to specify how entropy is generated for the algorithms used. ... Any thoughts on anything to add? -Kyle H _______________________________________________ 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