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

[Eric Rescorla <[e-mail]>]

"Kyle Hamilton" <[e-mail]> writes:

> On 7/1/06, Nikos Mavrogiannopoulos <[e-mail]> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls