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

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 1 Jul 2006 09:18:20 +0200

On Thu 29 Jun 2006 15:43, Stephen Kent wrote:

> >>  Each relying party is allowed to select the CAs that it views as
> >>  trust anchors. As a result, different RPs may have differing
> >> views of the same PKI.  Because a CA may have its key cross
> >> certified by multiple other CAs, it is possible to create cert
> >> paths that terminate at different trust anchors, depending on what
> >> TAs a given relying party selects. All of these observations say
> >> that X.509 and PKIX are NOT strictly hierarchic.
> >Ok I see your point. I also noticed that hierarchical is used in
> > several RFCs, to specify a specific form of hierarchy. So since
> > this term is already common for this, would something like the
> > following change address your concerns?
> >    At the time of writing, TLS [TLS] uses the PKIX [PKIX]
> >    infrastructure, to provide certificate services.  Currently the
> > PKIX protocols are limited to a structured certification model
> > where only specific participants, the Certificate Authorities, are
> > allowed to express trust. As a result, applications which follow
> > more complex trust models, such as the web of trust, could not be
> > benefited by TLS.
>
> That's better, but it still is pejorative and technically inaccurate
> in its characterization of X.509/PKIX.  Let me say why.
> 	- a CA is a Certification Authority, not a Certificate
> Authority, as per all the X.509 and PKIX standards.

Corrected, thanks .

> 	- anyone can be a CA, as my Windows XP example shows, so it
> is unfair to suggest that the ability to ba a CA is somehow limited.
> Thus the situation in X.509/PKIX is more or less the same as in OPGP,
> i.e., if you can get other folks to "trust" you as a signer of certs,
> then you can be a CA, period.  The fact that the major, highly
> visible, commercial CAs have established themselves as
> widely-accepted trust anchors is not an intrinsic feature of
> X.509/PKIX PKI standards. Anyone is free to configure any set of TAs
> they want, as a purely local decision, just as OPGP users are free to
> decide who they trust and to what extent.

There a lots of practical issues that make the PKIX certificates 
unusable in "web of trust" implementations, and this is my point.
Some of them are:
* there is only one issuer per certificate
* revocation is a capability of the issuer only
and could be even more (given that X.509 was designed to support
a hierarchically structured directory).

Thus even if could be possible to implement web of trust with X.509 
certificates, I'd need to send everytime n certificates (the number of 
the signers of my key), and I would not be able to revoke my key unless 
all of my signers agreed (discarding the fact that they'd need to 
publish a crl periodically :)

This I believe makes the scheme impractical to use as a basis for a 
decentralized system such as the web of trust. (and I would consider it  
an abuse rather than a normal use of PKIX)

Maybe in the future there are extensions to the PKIX to allow for the 
web of trust. But I'm describing the current situation.

> considerations section. In particular, you should note that use of
> PGP certs with an application will require a document analogous to
> 2818 to explain how to use the certs being transported.

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.

regards,
Nikos

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Kyle Hamilton" <[email-masked]>
Date: Sat, 1 Jul 2006 04:36:38 -0700

>          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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 01 Jul 2006 08:13:44 -0700

> 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

> least as difficult as the number of bits held within the key.

This is duplicative of RFC 1984.

> algorithms should check generated keys against them and reject them as

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

> recommended that implementations move away from RSA for identity keys.

I don't agree with this recommendation.

-Ekr

---

From: "Kyle Hamilton" <[email-masked]>
Date: Sat, 1 Jul 2006 17:17:01 -0700

On 7/1/06, Eric Rescorla <[email-masked]> wrote:
> [...snip...]

Then reference RFC 1984 in the Security Considerations section.  I
don't particularly care where they're written, but these are
considerations which need to be taken into account by every TLS
implementor and administrator -- and just because you already know
about it does not mean that everyone else does.  If someone decides to
read up on how the TLS protocol works by reading the document (even if
they're not implementing the protocol per se but even using it) it
would be a good idea to put it in.

> which is NOT to check for weak keys.

It is a security consideration, and I present it for consideration as
such.  Let's consider the (admittedly unlikely, but also admittedly
possible) case of DES with an all-zero key, or 3DES with an all-zero
key.  Surprise!  Identity operation!  Would you want /your/ medical or
financial data protected over a network that had implementations that
could possibly not encrypt it at all?

Regardless of whether it meshes with current TLS practice, these are
issues that need to be pointed out. I think it's absolutely barbaric
that TLS is a security protocol, yet legitimate security concerns are
being whitewashed because it doesn't mesh with "current practice".

> I don't agree with this recommendation.

Would you care to express why?  I've been looking at the research
that's been put into the GNFS up to now, and measured its progress
against Moore's Law.  The results are... scary.  If advancements in
mathematics continue apace, we'll have problems very soon.

Quoting from the abstract of
http://scholar.lib.vt.edu/theses/available/etd-32298-93111/unrestricted/etd.pdf
:
[...]One of the most prominent systems for securing electronic
information, known as RSA, relies upon the fact that it is
computationally difficult to factor a "large" integer into its
component prime integers. If an efficient algorithm is developed that
can factor any arbitrarily large integer in a "reasonable" amount of
time, the security value of the RSA system would be nullified.

The General Number Field Sieve algorithm is the fastest known method
for factoring large integers. Research and development of this
algorithm within the past five years has facilitated factorizations of
integers that were once speculated to require thousands of years of
supercomputer time to accomplish. While this method has many
unexplored features that merit further research, the complexity of the
algorithm prevents almost anyone but an expert from investigating its
behavior. We address this concern by first pulling together much of
the background information necessary to understand the concepts that
are central in the General Number Field Sieve. These concepts are
woven together into a cohesive presentation that details each theory
while clearly describing how a particular theory fits into the
algorithm. Formal proofs from existing literature are recast and
illuminated to clarify their inner-workings and the role they play in
the whole process. We also present a complete, detailed example of a
factorization achieved with the General Number Field Sieve in order to
concretize the concepts that are outlined.
[end quote]

Let's figure out the number of digits in any given keysize:

8 bit = 3 (max value "256")
16 bit = 5 (max value "16535")
32 bit = 10 (max value = "4294967296")
64 bit = 20 (max value = "18446744073709551616")
128 bit = 39
256 bit = 78
384 bit = 116
512 bit = 155
768 bit = 232
1024 bit = 309
2048 bit = 617
4096 bit = 1234

The largest RSA composite number ever known to be factored was 200
digits long.  (Source:
http://www.crypto-world.com/FactorAnnouncements.html )  This was
announced in May 2005, and took from "shortly before Christmas 2003"
to October 2004 (about 10 months), plus December 2004 to May 2005
(about 6 months).  This took about 170 Pentium 1GHz CPU-years, and
approximately (with their clusters) 80 machines working for those 16
months.  This means that 768 bit general RSA is in sight (if Moore's
Law continues to hold and advances in factoring mathematics continue
unabated, it should be less than 3 years from now before a 768-bit RSA
composite is factored).

The largest number ever factored by the special number sieve was 274
digits long.  This is larger than 768-bit RSA, and suggests that
1024-bit RSA composites that are of the special form could be
factorable at this point or in the fairly near future.

This is why I recommend exploring options other than RSA for identity
keys.  Why do you disagree with this recommendation?

-Kyle H

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 01 Jul 2006 17:50:13 -0700

> would be a good idea to put it in.

No.

RFC 4346 already has a reference to RFC 4096 (the current randomness
requirements RFC). Implementors of this document would clearly
need to read RFC 4346 and the security considerations section 
of that document is included by reference. The security considerations
section of this document only needs to cover issues which are different
from those in 4346.

> could possibly not encrypt it at all?

Yes, I'm quite familiar with the issue. And yes, I'm quite comfortable
with the current situation.

> being whitewashed because it doesn't mesh with "current practice".

The concerns aren't being "whitewashed". 

The debate over whether one should do weak key detection in protocols
has a very long history which I don't intend to reprise here other
than to note that the discussion usually focuses on the extremely
low probability of a random key being weak balanced against the
complexity of weak key checks. See this message on IPsec if you're
interested in the flavor of the debate:
http://www.sandelman.ca/ipsec/2000/01/msg00113.html

TLS embodies a deliberate design choice not to check for weak
keys. You may not happen to agree with that, but it's not something
that's likely to change and certainly not appropriate to change it in
the security considerations of a new TLS ciphersuite advancing outside
the standards track. I'd certainly be happy to include some text
explaining the weak key issue and TLS's choice not to check for
them in 4346bis, however.

>> I don't agree with this recommendation.
        
[comments about GNFS deleted]

> keys.  Why do you disagree with this recommendation?

You didn't recommend "exploring" it. You recommended that
implementations move away from it, which isn't the same thing 
at all.

Yes, 768 bit keys are almost certainly not safe for long-term use, but
that doesn't mean that RSA isn't safe, just that you need longer key
sizes (the Lenstra recommendation [0] is 1568 bits for security
through 2020). I'd have no problem with a recommendation that people
study the Lenstra recommendations (or other well-sourced
recommendations and choose key lengths appropriately, but a blanket
statment that they should move away from RSA is not appropriate.

That said, I consider the focus on key length to be generally
misguided, as it's far from the easiest way to recover the private
key. Remotely compromising the server in question and recovering the
private key directly is generally easier, and given the amounts of
money involved in mounting a credible attack on even a modest-length
key (e.g., 1024 bits), it would generally be far more cost effective
to simply mount a social engineering or physical attack on the server
in question. Yes, it's important to have a strong key, but for nearly
all commercial uses it's not plausible that an NSA-scale attacker is
going to spend 2 years trying to factor your RSA modulus.
 
-Ekr

[0] http://www.keylength.com/

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 1 Jul 2006 21:09:48 -0400

> keys.  Why do you disagree with this recommendation?
The effort with GNFS is not linear in modulus length; furthermore, a lot
of memory is needed for the row reduction.  Have a look at sections 2.4
and 2.5 of RFC 3766.  Also see table 5, and note that an 8719-bit modulus
is roughly equivalent to a 200-bit symmetric key, which NSA rates as
suitable for Top Secret data.

That said, I agree that 1024-bit RSA is not suitable for protecting
long-lived secrets.  2048-bit or 3072-bit RSA seems *way* out of reach,
barring a major theoretical breakthrough in factoring algorithsm.  I won't
even engage in guessing games about when Moore's Law will break down, but
I think we can agree that transistors smaller than a single atom are,
shall we say, unlikely, and that puts an upper bound on density no matter
what we do.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Martin Rex <[email-masked]>
Date: Mon, 3 Jul 2006 16:20:21 +0200 (MET DST)

> with the current situation.

Although the existing SSL/TLS specs do not define how to synchronously
skip/drop weak keys during key generation upfront and synchronously,
wouldn't it be possible for either side (when the particular implementations
feels such a need) to detect a weak key and force the peer directly
through a renegotiate -- even old peers?

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Jul 2006 07:33:26 -0700

> through a renegotiate -- even old peers?

Sure. Except that the other side can refuse to renegotiate and
that there are deadlock conditions if you try to renegotiate
at the wrong time....

-Ekr