[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Please discuss: draft-housley-evidence-extns-00<
see inserted:
>> Stefan Santesson wrote:
> >
> > I think you misunderstand my problem statements. Both user
> > authentication and signing of transactions in interactive
> > web services such as on-line banking has historically been
> > problematic and forced users to use either external devices
> > or download client plug-ins. I haven't followed this lately
> > but last time I checked this was still an issue.
>
> I do NOT consider this an "ISSUE", it is the only reasonable approach,
> is less confusing to the user in that there is a huge difference
> between online-authentication and digital signatures and
> are much harder to abuse in that digital signatures are going
> to be pushed out to users in a covert fashion.
I agree with the above statement from Martin. Majority of the banks found
ways to manage the risk. If the issue was raised 10 or more years ago it may
have been different. BTW, when I used wells fargo (wellsfargo.com) in 2003 I
was able to transfer money between accounts with a simple user name /
password authentication. But I did hear about other solutions employed by
non-US banks - but they look at them as a satisfactory solutions.
-Omirjan
>
> Why does Microsoft want a tigther integration between TLS
> and Kerberos authentication? Because this is what customers
> desperately want in order to do single Sign-On. Just that
> the TLS Evidence is mutually exclusive with a lot of things,
> including cert-less single sign-on with Kerberos.
>
> One generic approach to creation of digital signatures
> (or two, one for the frontend and one for the backend),
> that will work independent of the online authentication
> scheme that is being used will be so much better for all
> of us, and in particular for the average end user.
>
>
> >
> > I'm simply curious whether this solution has a place or not.
>
> TLS Evidence is the most evil protocol extension (proposal) I am aware of.
>
> >
> > The solution itself does not have a serious security flaw.
>
> On my scorecard it has several security flaws.
>
>
> >
> > But the way it is used can, if used improperly.
>
> That's an interesting way to put it.
> If I get around to it, I'll put it up for the next BigBrother award.
>
> >
> > I think we can leave the DMZ out of this. There are different
> > architectures with different problems.
>
> Really bad idea. DMZ has significant security benefits and
> is being used and necessary in many SSL/TLS deployments.
> It already was a good idea 10 years ago, when you didn't
> have weekly 0-day vulnerability reports.
>
> Responsible sysadmins of large companies do not only use a DMZ
> to seperate the company network from the internet, they also
> have one or more internal networks seperated with a DMZ
> from the company internal network. And even without a
> "full blown" DMZ, the main characteristic of a single entry point
> through an SSL Accellerator or Reverse Proxy with Load-balancer
> is the norm for large-scale application deployment using
> web-based presentation frontends.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxxxxxxxx
> https://www1.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls