Subject: Re: [TLS] TLS Digest, Vol 103, Issue 17

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Wed, 13 Feb 2013 17:34:21 -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 7:47 AM, <[email-masked]> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/tls
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send TLS mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/tls
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of TLS digest..."
>
>
> Today's Topics:
>
>    1. Re:  Certificate Authorities are not required anymore
>       (OMAR HASSAN (RIT Student))
>    2. Re:  Certificate Authorities are not required anymore
>       (Russ Housley)
>    3. Re:  Certificate Authorities are not required anymore
>       (Peter Sylvester)
>    4. Re:  Certificate Authorities are not required anymore
>       (Peter Gutmann)
>    5. Re:  Certificate Authorities are not required anymore
>       (OMAR HASSAN (RIT Student))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 12 Feb 2013 12:42:11 -0800
> From: "OMAR HASSAN (RIT Student)" <[email-masked]>
> To: Russ Housley <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [TLS] Certificate Authorities are not required anymore
> Message-ID:
>         <
> [email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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.
>
>
>
> On Tue, Feb 12, 2013 at 10:01 PM, Russ Housley <[email-masked]>
> wrote:
>
> > 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:
> >
> > http://tools.ietf.org/html/draft-omar-tls-udkp-00
> >
> >
> > Thank You
> > _______________________________________________
> > TLS mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tls
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/tls/attachments/20130212/bf929a08/attachment.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 12 Feb 2013 23:48:56 -0500
> From: Russ Housley <[email-masked]>
> To: "OMAR HASSAN (RIT Student)" <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [TLS] Certificate Authorities are not required anymore
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> 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
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/tls/attachments/20130212/14b869ac/attachment.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 13 Feb 2013 07:56:39 +0100
> From: Peter Sylvester <[email-masked]>
> To: [email-masked]
> Subject: Re: [TLS] Certificate Authorities are not required anymore
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> 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.
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/tls/attachments/20130213/53645b31/attachment.htm
> >
>
> ------------------------------
>
> Message: 4
> Date: Wed, 13 Feb 2013 12:36:17 +0000
> From: Peter Gutmann <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: Re: [TLS] Certificate Authorities are not required anymore
> Message-ID:
>         <
> [email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> "OMAR HASSAN (RIT Student)" <[email-masked]> writes:
>
> >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.
>
> How does this improve on TLS-SRP and TLS-PSK, which already do the same
> thing?
>
> Peter.
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 13 Feb 2013 07:47:14 -0800
> From: "OMAR HASSAN (RIT Student)" <[email-masked]>
> To: Russ Housley <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [TLS] Certificate Authorities are not required anymore
> Message-ID:
>         <CALxQUYEqYy1C2++fh=_H3qLvPVkKexBjwHoUNZZqbn=
> [email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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:
>
> > 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
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/tls/attachments/20130213/fd239bff/attachment.htm
> >
>
> ------------------------------
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>
> End of TLS Digest, Vol 103, Issue 17
> ************************************
>