[TLS] Review of draft-huang-tls-ibe-00

[Eric Rescorla <ekr at networkresonance.com>]

$Id: draft-huang-tls-ibe-00-rev.txt,v 1.1 2009/07/16 18:08:41 ekr Exp $

This draft describes how to use Identity Based Encryption
algorithms (BF and BB) to exchange keys for TLS. 

GENERAL COMMENTS
I don't find the motivation for this work particularly convincing.
The drawbacks that the authors attribute to the current PKI-based
authentication for TLS are not really ameliorated by IBE, and
in some respects the IBE system is worse

- The authors argue that the cost of CRL verification is high.
  This is probably true (although most current clients don't
  do CRL verification regularly), but it's not clear that 
  it's any better with IBE. The IBE revocation strategy is
  effectively to use very short lived credentials and then
  refuse to reissue if the identity is compromised. This is
  completely compatible with PKI, it's just that it's not
  widely done because certificate reissuance is inconvenient.
  IBE places a similar burden on the server operator.

- There definitely are UI issues with users accepting mismatched
  certificates, but it's not clear that IBE will really
  solve the problem here; if you're going to mount an attack
  it's about equally convenient to have a bogus CA as a 
  bogus domain name. Unless you're going to prohibit users
  from accepting PKGs that their clients don't know about
  (we tried this with CAs and it didn't work out), it seems
  to me that we're going to still have the user override
  problem.

- The argument offered in S 1 about P2P environments is
  simply false. There is no respect in which it is easier
  for a user to get an IBE key than it is to get a PKI 
  certificate. 

Moreover, the main benefit of IBE, namely that Alice can send an
encrypted message to Bob without communicating with Bob and before Bob
has enrolled doesn't pay off here because TLS involves direct
communication and expects the server to be able to decrypt the PMS in
real time.


The mechanism described here is extremely clumsy: I find
it highly implausible that the client is going to send its
entire list of PKGs (if X.509 is any guide, this would run
to a hundred or so) in every ClientHello. Actually, due
to the unique security properties of IBE, I would imagine
there would be more PKGs because the amount of trust placed
in a PKG is much higher than a CA.


DETAILED COMMENTS
S 1.
   user.  In this procedure, user must get all certificates of CAs
   involved in this authority chain and make requests for Certificate
   Revocation Lists (CRLs) to check if the certificates are still valid.

In TLS, it's standard practice to send the whole chain.

   CAs.  Users may consume significant time for this processing.
   Besides, it is an overburden to maintain and issue certificates and
   CRLs.

I'm not sure what resource you're talking about here. RSA verification
is much faster than IBE key exchange. 


   In current actual application of TLS, most users would like to ignore
   the failure alert of certificate verification that pop up from their
   browsers and continue to complete the connections to these HTTPS
   websites.  This neglect can be utilized by attackers to masquerade
   websites using the forged certificates.  In IBE-based system, there
   is no need to verify the receiver's public key for users.  Because
   the identity information used as the public key is well-known and
   user authentication relies on the authentication performed by PKG.
   Therefore, the risks brought by user's neglect will be eliminated.

I don't buy this. What happens when the server offers a PPS you've
never heard of.


   o  An authentication method allowing the users to compute digital
      signatures using their private keys from the PKG.  Each side can
      validate the signature with the public key of the other side.  It
      can support both server authentication and client authentication.

What's the value of this at all? Why not just use certificates.


S 3.
Unless I'm missing something, this is going to involve sending every
PPS you trust, which even if each of these record is only 100 bytes,
is something like 10k. Moreover, it basically rules out any use
of PKGs which aren't known to the client. As I said earlier, this
general concept failed badly when certificates were in play.


S 4.1.1.
      struct {
           opaque not_before[16];
           opaque not_after[16];
        }ValidityPeriod;

Why not use standard unix times here? 

   The public_parameter_data contains the actual cryptographic
   parameters depending on the specific algorithm.

Where is this specified.


   Items in server_id_list are strings that can be used as the public
   keys of server.  The server chooses one ID from this list contained
   in the ClientHello message or appoints a new ID which is not
   contained in this list.  The structure of IDInfo is defined as
   follows:

        struct {
             opaque id_info<1..2^8-1>;
          }IDInfo;

   It is RECOMMENDED that the client and the server use the well-known
   and unique in certain community identities as their public keys, e.g.
   the server's domain name.

This seems to me to be missing actual support for short-lived keys.
In order to avoid needing revocation, you need to include a date
string as part of the server's identity. Where is this stored,
how is it agreed upon, etc?



   The client_id_list field is a list of client identities that can be
   used as or be used to compute the public key of client.  The server
   can select one of the client IDs as the client's public key according
   to the configured policies.  The selected ID can then be used to
   verify the client's signature sent in the client's CertificateVerify
   message.  The value of the IDInfo can be an IP address, a domain
   name, an email address, a phone number or a host name, etc.

What if I dont want to do client auth?




S 6.
The security considerations really need to accurately describe
the consequences of compromise of the PKG, which are much
worse than that of a CA.