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

________________________________
From: Eric Rescorla <ekr@networkresonance.com>
To: Min Huang <huangmin@huaweisymantec.com>
Cc: tls@ietf.org
Sent: Friday, July 24, 2009 7:07:21 PM
Subject: Re: [TLS] Review of draft-huang-tls-ibe-00

At Fri, 24 Jul 2009 15:49:47 +0800,
Min Huang wrote:
> 
> 
> hi,
> 
> Eric Rescorla <ekr at networkresonance.com> wrote:
> 
> >But Mechanism 2 has the same issues as certificates in terms 
> >of the user being able to override invalid credentials.
> 
> Mechanism 1 is intended to solve this problem, if the client 
> sends the public parameter sets list which it trusts to server, 
> and the server only can choose one from the parameter sets list, 
> there will be no override invalid credentials problems. But as 
> you metioned before, it brings some other problems to be solved.
> So mechanism 2 is provided, it seems more similar to the traditional 
> PKI mechanism, but it also has the override invalid credentials problem.

Yes, my point is that mechanism 1 is unworkable except in
very limited applicatione where you could just as well
have the client configured not to allow override by the
user, and that mechanism 2 does not have what this draft
claims is the primary benefit of IBE for TLS.

This isn't to say that IBE for TLS doesn't work, but as
far as I can tell it doesn't have any real advantages.

> >I agree that this benefit is not applicable to TLS. But since
> >that's the main technical benefit of IBE...
> 
> It’s true. But in some cases, it can work well. For example, 
> (1)The server obtains its private key in advance and tells the client 
> the corresponding public parameter set and ID to be used in keyexchange. 
> There is no relationship with the main benefit of IBE. 

Right, and no benefit over the current PKI-based mechanisms.

> (2)The client tells the public parameter sets and ID to the server 
> in handshake process. If there is a real time authentication method 
> used by the PKG to authenticate the server effectively, then the 
> server can obtain its private key in the TLS handshake process 
> immediately.

This seems distinctly implausible.

> >I don't understand what you're suggesting here.
> 
> I meant that in one specific domain the number of PKGs is not large. 
> You said "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." I am not sure 
> do you mean that there must be many PKGs that undertake the 
> responsibility of generating a user’s private key together? 
> for example, each PKG just shares just one piece of private key, 
> and a private key can be computed after putting all piece together.

No, I mean that sites are currently willing to trust VeriSign
to issue their certificates because even a total compromise of
VeriSign's infrastructure doesn't retroactively destroy the
security of their communications. But this isn't so with IBE,
which motivates more local PKGs.

> >But this makes the real time problem worse, since the client needs
> >to know in advance what keys the server might potentially have,
> >otherwise the server will need to get a new key for each client.
> 
> In mechanism 1, the server IDs list is provided by the client and 
> there must be a problem if the ID contains a data string. There 
> what they negotiate is the identity information, e.g., email address, 
> IP address, domain name or other identities which can be used to 
> indicate the identity of the server. This information does not include 
> a date string. The actual ID used to compute the public key is provided 
> by the server after the negotiation.

But the consequence of this is that there's no meaningful way to
do revocation.

> In mechanism 2, it is not a problem. 
> Because the server ID used in encryption is sent by the server. So it 
> can directly provide a valid ID containing a valid date string.

Sure, but again this has no real benefits over PKI.

-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls