Re: [TLS] User Defined Key Pair

["OMAR HASSAN (RIT Student)" <[e-mail]>]

Hi Dan,

I believe that your protocol will better suit for customized applications,
but when it comes to websites you will definitely face those issues that I
took about.



It's very common that a SQL injection attack against the website would give
the attacker the opportunity to steal database records, which will allow
the attacker to impersonate the client (I think TLS-SRP adds a little
complexity to protect against that scenario, I am sure you can improve this
part in your protocol)



Also TLS termination is very important, and must be supported by the
protocol, and the first challenge in that regard is that the load balancer
where the TLS connection should be terminated will not have access to the
server database, and I think without access to the server database you will
not be able to terminate the encrypted connection.



Regarding UDKP, I believe that the only valid attack against it is during
the registration. In that case using an initial TLS authenticated
connection will solve this issue, and for all later usages there is no need
to be dependent on certificate authorities.



In UDKP, if the server data has been stolen, the attacker will get only the
public key, and he will not be able to impersonate the client as he will
need the private key. And regarding TLS termination, the load balancer
could use the user public key to terminate the encrypted connection, and
the let the server authenticate the user. You can refer to section 5.2 in
the draft:

http://tools.ietf.org/html/draft-omar-tls-udkp-01#section-5.2

In the coming version of the draft I will put a detailed analysis for the
attack scenarios.


On Thu, Jul 11, 2013 at 6:22 PM, Dan Harkins <[e-mail]> wrote:

>
>   Hi Omar,
>
> On Thu, July 11, 2013 2:42 am, OMAR HASSAN (RIT Student) wrote:
> > Hi Dan,
> >
> > I had a quick look at your work item, and I have some questions:
> >
> > What will be the consequences if the server data has be stolen? will the
> > attacker be able to impersonate as the user?
>
>   Successfully stealing records from the server's password file will
> enable the thief to impersonate the client (back to the hacked server)
> for all stolen records.
>
> > How will the password be stored in the server initially?
>
>   That is completely up to the server.
>
> > How will you handle TLS termination that is used many websites to
> > centralize the related measurements and protection against the common SSL
> > attacks in one place, and to allow the application firewalls to validate
> > and check the incoming requests for application-level attacks such as SQL
> > injection and cross-site scripting?
>
>   This is really an operational question. At the risk of sounding flippant
> I guess I'd just say it will be handled in the best way possible.
>
>   You claim in your draft that "UDKP aims to completely replace the TLS
> protocol." That is a much more ambitious goal and you will need to handle
> these sorts of issues. The tls-pwd draft just defines certificate-less
> ciphersuites that are resistant to dictionary attack (and are better than
> the various PSK ciphersuites) for use with the existing TLS protocol.
>
>   regards,
>
>   Dan.
>
> > Thanks
> >
> >
> >
> > On Wed, Jul 10, 2013 at 8:49 PM, Dan Harkins <[e-mail]>
> wrote:
> >
> >>
> >> On Mon, June 24, 2013 11:34 am, Salz, Rich wrote:
> >> [snip]
> >> > If you are trying to avoid CA's, then why not just use self-signed
> >> > certificates or similar like PGP?
> >>
> >>   Or why not use a protocol that is already a work item of the
> >> TLS working group:
> >>
> >>      http://tools.ietf.org/html/draft-ietf-tls-pwd-00
> >>
> >>   Dan.
> >>
> >>
> >>
> >>
> >
>
>