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

From: Min Huang <[email-masked]>
Date: Wed, 22 Jul 2009 11:16:54 +0800

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.

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

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

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

The meaning I want to express is the same as yours. 
The server sends the whole chain of certificates. The 
client who receives this chain checks the CRL and 
verifies the signatures contained in these certificates.
In IBE, the client needs to check the public parameters, 
server's ID and associated private key is still valid.

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

>  Why not use standard unix times here?

Good suggestion, I will rewrite the definition of this structure.
And maybe ietf standard times format described in RFC3339 
will be better.

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

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

>   What if I dont want to do client auth?

If the server doesn't want to do client auth, 
it just ignores the client_id_list field and 
CertificateRequest message will not be 
sent by server. I will add appropriate description 
to the doc, is it right?

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

I will reword the security considerations section 
to describe the issues clearly and accurately.

regards,
Min Huang

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2009 21:24:26 -0700

At Wed, 22 Jul 2009 11:16:54 +0800,
> 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.

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

> degree of the private keys and the number of 

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

> and user authentication in some circumstances.

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

> are described in IBCS (RFC 5091).

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

> 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

---

From: Min Huang <[email-masked]>
Date: Fri, 24 Jul 2009 15:49:47 +0800

hi,

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

>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 

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

>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:[email-masked]] 
发送时间: 2009年7月22日 12:24
收件人: Min Huang
抄送: [email-masked]; [email-masked]
主题: Re: [TLS] Review of draft-huang-tls-ibe-00

Min Huang wrote:
> 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.

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

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

> 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 just want to provide an more option for key exchange and user 
> authentication in some circumstances.

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

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Jul 2009 19:07:21 -0700

At Fri, 24 Jul 2009 15:49:47 +0800,
> 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.

> There is no relationship with the main benefit of IBE. 

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

> server can obtain its private key in the TLS handshake process 
  
This seems distinctly implausible.

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

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

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

-Ekr