Subject: [TLS] Certificate Authorities are not required anymore

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Tue, 12 Feb 2013 19:04:24 +0300

Hi All,

I have submitted a new internet draft that aims to build a secured tunnel
between the client and the server without the need to involve Certificate
Authorities or any other third party in this process. it is based on the
assumption that in most cases there is a registered profile for the user on
the server; a profile that includes among a lot of things the username and
the password that the user uses to authenticate to the server, the proposed
protocol will make use of the username and the password to create a key
pair for the user on the fly at the client side (inside the browser), and
it will use this key pair as the starting point for creating the secured
tunnel instead of taking the server certificate as the   starting point.
Additionally the proposed protocol has self-protection against phishing
attacks.
I will be appreciated if you had a look at the document and told me your
thoughts about the idea. You can find the document under the following link:

http://tools.ietf.org/html/draft-omar-tls-udkp-00

Thank You

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Feb 2013 14:01:55 -0500

Doesn't the use of DANE to authenticate the public key of the server make this a much stronger solution?

Russ

On Feb 12, 2013, at 11:04 AM, OMAR HASSAN (RIT Student) wrote:

> Hi All,
>  
> I have submitted a new internet draft that aims to build a secured tunnel between the client and the server without the need to involve Certificate Authorities or any other third party in this process. it is based on the assumption that in most cases there is a registered profile for the user on the server; a profile that includes among a lot of things the username and the password that the user uses to authenticate to the server, the proposed protocol will make use of the username and the password to create a key pair for the user on the fly at the client side (inside the browser), and it will use this key pair as the starting point for creating the secured tunnel instead of taking the server certificate as the   starting point. Additionally the proposed protocol has self-protection against phishing attacks.
> 
> I will be appreciated if you had a look at the document and told me your thoughts about the idea. You can find the document under the following link:
>  
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Tue, 12 Feb 2013 12:42:11 -0800

Hi Russ,

Thank you for being interesting in the draft.

When I start thinking in that approach, I was highly motivated by the
desire to achieve my golden goal; to make the security of my connection to
my internet bank is the ultimate responsibility of me and my internet bank
not anyone else. In the original implementation of the TLS my connection is
as secure as all Certificate Authorities that are trusted by my browser. If
any of those CAs betrayed this trust relationship either intentionally or
by being attacked or even by any insider employee, my connection to my
internet bank will be at risk, so my connection security depends on
hundreds or may be thousands factors that are outside the control of me and
my internet bank as the communication parties. This is the philosophy
behind my idea.

Many workarounds that have been discussed to reduce the risk of this issue,
but they couldn't achieve my golden goal for being independent on any third
party. Of those attempts are: Certification Authority Authorization (CAA) ,
and DNS-based Authentication of Named Entities (DANE). These approaches are
DNS based and can prevent any untrustworthy signer from compromising
anyone's keys except those in their own sub domains, but unfortunately
domains security are based on the security of the DNSSEC; which means these
approaches are vulnerable to the DNS keys integrity corruption if the
registrar for that domain compromised, so registrars still have the power
theoretically to abuse their position because they're responsible for your
communication to the root servers.

So for dane, instead of being dependent on the security of Certificate
Authorities, you will be dependent on the security of the domain
registrars.

I hope I was able to clear my point, and feel free to ask if you need more
explanation of any of the above.

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Feb 2013 23:48:56 -0500

Omar:

> So for dane, instead of being dependent on the security of Certificate Authorities, you will be dependent on the security of the domain registrars. 

You cannot avoid that dependency.  The DNS provides the IP address for the server.  The admin at the bank needs to make sure the right IP address is in the DNS, and it is not a big additional burden to include the public key of that server at the same time.  This adds no further trust relationships than are needed to get the IP address in the first place.

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 13 Feb 2013 07:56:39 +0100

On 02/13/2013 05:48 AM, Russ Housley wrote:
> Omar:
>
>> So for dane, instead of being dependent on the security of Certificate Authorities, you will be 
>> dependent on the security of the domain registrars.
>
> You cannot avoid that dependency.  The DNS provides the IP address for the server.  The admin at 
> the bank needs to make sure the right IP address is in the DNS, and it is not a big additional 
> burden to include the public key of that server at the same time.  This adds no further trust 
> relationships than are needed to get the IP address in the first place.
>

rfc 5054 also does (real) mutual authentication
without need of certificates local (client) trust base.

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Wed, 13 Feb 2013 07:47:14 -0800

Russ :

You cannot avoid that dependency.

Actually that what I am trying to prove with my draft; that we can
completely avoid forcing e-business applications to have trust
relationships with domain registrars, certificate authorities, or any other
third party.

The root cause that fails the current TLS implementation to achieve the
expected security protection even after using dane, is that the client
encrypts the premaster secret using the server certificate it receives from
someone who claims to be the server; this claim is supported by the
attestation of a third party; the third party could be CA, or Domain
Registrar, and the e-business is as secure as this relationship to the
third party is trusted.

the new approach is based on benefiting from the existing account for the
user on the server (internet bank) by reversing the TLS process, the server
will receive a message from the client signed by the user private key, and
he doesn't have to validate the signed message from any third party as it
has the related public key as a part of the user account, and then the
server will use that public key to encrypt the premaster and send it to the
client who will read it using its private key.

For the sake of demonstrating the functionality and proofing the concept
behind UDKP protocol, I have made a simple implementation for the proposed
protocol. In this implementation I have modified the TLS implementation to
reflect the new changes in the handshake messages. I have not written any
application from scratch for this proof of concept; instead, I have
modified

On Wed, Feb 13, 2013 at 7:48 AM, Russ Housley <[email-masked]> wrote:

> You cannot avoid that dependency.  The DNS provides the IP address for the
> server.  The admin at the bank needs to make sure the right IP address is
> in the DNS, and it is not a big additional burden to include the public key
> of that server at the same time.  This adds no further trust relationships
> than are needed to get the IP address in the first place.
>
> Russ
>
>

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Wed, 13 Feb 2013 07:48:51 -0800

Russ :

modified the following open source applications:

1. Tomcat 7 application server (open source written in java).
2. Lobo web browser (open source written in java).
3. OpenJDK Java Run Time Environment 6 (open source written in java).
4. JForum web application (open source forum written in java).

On Wed, Feb 13, 2013 at 7:47 AM, OMAR HASSAN (RIT Student)
<[email-masked]>wrote:

> On Wed, Feb 13, 2013 at 7:48 AM, Russ Housley <[email-masked]>wrote:
>
>> Omar:
>>
>> You cannot avoid that dependency.  The DNS provides the IP address for
>> the server.  The admin at the bank needs to make sure the right IP address
>> is in the DNS, and it is not a big additional burden to include the public
>> key of that server at the same time.  This adds no further trust

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 13 Feb 2013 08:49:12 -0800

How does the user public key gets to the server? Out of band?

The registration part of your specification is the problem. The client
cannot register its public key safely with the server because it has no way
of knowing that it is talking to the right server.

-Piyush

From: [email-masked] [mailto:[email-masked]] On Behalf Of OMAR
HASSAN (RIT Student)
Sent: Wednesday, February 13, 2013 7:49 AM
To: Russ Housley
Cc: [email-masked]
Subject: Re: [TLS] Certificate Authorities are not required anymore

Russ :

 

Actually that what I am trying to prove with my draft; that we can
completely avoid forcing e-business applications to have trust relationships
with domain registrars, certificate authorities, or any other third party.

Registrar, and the e-business is as secure as this relationship to the third
party is trusted.

For the sake of demonstrating the functionality and proofing the concept
behind UDKP protocol, I have made a simple implementation for the proposed
protocol. In this implementation I have modified the TLS implementation to
reflect the new changes in the handshake messages. I have not written any
application from scratch for this proof of concept; instead, I have modified
the following open source applications:

 

On Wed, Feb 13, 2013 at 7:47 AM, OMAR HASSAN (RIT Student) <[email-masked]>
wrote:

Russ :

 

Actually that what I am trying to prove with my draft; that we can
completely avoid forcing e-business applications to have trust relationships
with domain registrars, certificate authorities, or any other third party.

Registrar, and the e-business is as secure as this relationship to the third
party is trusted.

application from scratch for this proof of concept; instead, I have modified

 

Omar:

So for dane, instead of being dependent on the security of Certificate
Authorities, you will be dependent on the security of the domain registrars.

You cannot avoid that dependency.  The DNS provides the IP address for the
server.  The admin at the bank needs to make sure the right IP address is in
the DNS, and it is not a big additional burden to include the public key of
that server at the same time.  This adds no further trust relationships than
are needed to get the IP address in the first place.

Russ

---

From: Ben Laurie <[email-masked]>
Date: Wed, 13 Feb 2013 08:57:07 -0800

On 12 February 2013 20:48, Russ Housley <[email-masked]> wrote:
> server.

And if it is wrong, the server won't have the correct private key.
Isn't that the whole (alleged) point of CAs?

>  The admin at the bank needs to make sure the right IP address is in

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Wed, 13 Feb 2013 17:44:40 -0800

Regarding the user of the SRP; it has the following issues that make it not
widely used in websites:

1) The server needs to store the username, v (which is based on the user
chosen password), and s(salt)
SRP didn't mention how these values will be saved in the first time, most
probably when SRP is deployed with websites, websites  will have to depend
on the Certificate Authority to secure this communication for the first
user registration, or the registration will be out of the internet band.

2) If  v is compromised, an attacker can spoof as Server and fool the user
to log in, and attacker could have full transparently access over the
traffic.

3) the handshake part of SRP needs heavy computation at the server side
each time the user log in, which cannot be afforded by all websites.

In the new approach; the public/private key pair will be generated inside
the browser plugin using heavy computations (but this computation
complexity will be distributed at the client machines during the
handshake), the public, key could be transferred in clear during
registration for the first time, without much dangerous on revealing the
user private key, or user password, as it's generated using heavy
computation based on the user name and user password, and the user password
will never leave the browser.

so the registration message will be:

struct{
                UDKP_private-key-encrypted Random user_token;
                UserName user_name;
                UserPubliKey user_public_key;
        } UserAuthentication;

where the user_token will be constructed by encrypting the
ServerHello.random value using the user private key; this random value
contains the server timestamp, the browser will add or deduct a few random
seconds to it, those random seconds should be short enough to prevent
replay attack, and at the same time should be large enough to protect
against the known plain text attack.

When the user tries to login later, he will provide only the user_name and
the user_token, the token will be validated by tying to reconstructing
the server time stamp, and if succeed the premaster will be generated by
the server and encrypted using the user_public_key, so no one can have
access to the session key unless he has the user private key, so even if
the user_public_key got captured it will not help the attacker to monitor
the traffic.

On Wed, Feb 13, 2013 at 8:57 AM, Ben Laurie <[email-masked]> wrote:

> the