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

[Min Huang <[e-mail]>]

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.

>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. 
(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.

>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.

>OK, but you need to describe the actual encoding. Is it an 
>IBESysParams or what?

It is a BFPublicParameters or a BB1PublicParameters structure 
defined in RFC 5091. 

>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. 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.

regards,
Shirley



-----邮件原件-----
发件人: Eric Rescorla [mailto:[e-mail]] 
发送时间: 2009年7月22日 12:24
收件人: Min Huang
抄送: [e-mail]; [e-mail]
主题: Re: [TLS] Review of draft-huang-tls-ibe-00

At Wed, 22 Jul 2009 11:16:54 +0800,
Min Huang wrote:
> 
> 
> Hi,Eric
> 
> Thanks very much for your review.
> Reply  inline.
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 
> Eric Rescorla <ekr at networkresonance.com> writes:
> 
> > - 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 certificate (or public parameters) is sent from the server to the 
> client. There always is a mismatching problem, either a distrusted CA 
> or a distrusted PKG.
> So in this proposal I thought that the client provides the sets of 
> public parameters from PKGs it trusts before the server sends its 
> public parameters.
> The public parameters set sent by the server must be one of the sets 
> provided by the client. If there is no matched set, the server can not 
> choose IBE cipher suites or this connection is failed. This is also 
> one reason of putting public parameters sets in the ClientHello 
> message. However, as you mentioned, this mechanism is not so good. 
> There is another mechanism. I am considering how about putting the 
> public parameters set in the Server Certificate message. The client 
> only provides the IBE cipher suites. If the server chooses an IBE 
> cipher suite, it needs to provide the public parameters retrieved from 
> the PKG/PPS from which it acquired the private key. I will call the 
> original mechanism "mechanism 1" and this alternative mechanism 
> "mechanism 2" for convenience in the following description. Mechanism 
> 1 supports obtaining private keys in real time if there is no matching 
> PKG from which it has obtained the private key and in advance if there 
> is a matching PKG. In mechanism 2 the server can also acquire its 
> private key in real time or in advance depending on the policies 
> configured.
> It needs to consider which mechanism is better. 
> I wonder we can reach consensus in the wg.

But Mechanism 2 has the same issues as certificates in terms of the user
being able to override invalid credentials.


> >  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.
> 
> In TLS this benefit of IBE is not utilized because TLS involves real 
> time communication. If the time taken by obtaining private key is 
> within the tolerance of real time communication, then the server can 
> obtain its private key in the process of TLS handshake.

I agree that this benefit is not applicable to TLS. But since that's the
main technical benefit of IBE...


> >  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.
> 
> Here "list of PKGs" you mentioned above actually is a list of public 
> parameters sets from PPSs/PKGs trusted by client. What I considered 
> earlier is that the number of PKGs in one domain is not large, but in 
> the whole internet environment, this mechanism seems clumsy. I am 
> considering another mechanism described in front. The public 
> parameters and server ID used in key exchange are provided by the 
> server who has already acquired its private key from one PKG.
> "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."
> It means that if one PKG is compromised, all of the users' private 
> keys are compromised.
> So there must be many PKGs that undertake the responsibility of 
> generating private keys together.
> Then if one PKG is compromised, it only affects the parts of users' 
> private keys and the users'
> private keys are still secret. So the security degree of the private 
> keys and the number of PKGs are increased.

I don't understand what you're suggesting here.


> >  What's the value of this at all? Why not just use certificates.
> 
> I just want to provide an more option for key exchange and user 
> authentication in some circumstances.

I'm not convinced that adding new options is good here.
What does this bring to the party.

> >     The public_parameter_data contains the actual cryptographic
> >     parameters depending on the specific algorithm.
> >  Where is this specified.
> 
> The parameters contained in IBE public parameters are specified in RFC 
> 5408 and I consulted that specification.
> Boneh-Franklin (BF) and Boneh-Boyen (BB1) algorithms are described in 
> IBCS (RFC 5091).

OK, but you need to describe the actual encoding. Is it an IBESysParams or
what?


> >  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?
> 
> Agree.
> I will add a date string into the IDInfo structure in new version.

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.

-Ekr