Re: Status of opportunistic encryption

2006-06-03 Thread Anne Lynn Wheeler

James A. Donald wrote:

I was unaware of this.  So I googled for DNSSEC. Reading
the DNSSEC documents I found
: :In order to support the larger DNS message
: :sizes that result from adding the DNSSEC RRs,
: :DNSSEC also requires EDNS0 support ([RFC
: :671]). 

and

: :its authentication keys can be authenticated
: :by some trusted means out of band from the
: :DNS protocol.

This does not sound workable to me.


this could be analogous or the same as the trusted certification 
authority authentication keys that are incorporated into browsers when 
they are distributed (to the extent that distributed certification 
authority authentication keys, that are authenticated out of band from 
the standard PKI process, appear to work, it could be possible that 
something similar might also work for DNS).


the specification of the root DNS servers could include specifying the 
associated authentication keys ... in much the same way that the 
distribution of the root CAs information include the distribution of the 
associated CA authentication keys.


my rfc index
http://www.garlic.com/~lynn/rfcietff.htm

select Term (term-RFC#) under RFCs listed by ... and then select 
DNSSEC in the acronym fastpath.



domain name system security  (DNSSEC )
see also domain name system, domain name system extensions,
security
 4509 4470 4431 4398 4322 4310 4035 4034 4033 3845 3833 3755
 3658 3226 3225 3130 3110 3090 3008 3007 2931 2930 2845 2541
 2540 2539 2538 2537 2536 2535 2137 2065

in frames mode, clicking on the RFC number brings up the RFC summary in 
the lower frame. clicking on the .txt= field in the RFC summary 
retrieves the actual RFC.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Status of opportunistic encryption

2006-06-03 Thread Anne Lynn Wheeler

James A. Donald wrote:

In an organization with hundreds of administrators
managing tens of thousand of machines, what goes wrong
with trusting your key store?  And who administers
Kerberos?  Don't they have a problem with tens of
thousands of machines?


the original pk-init draft for kerberos just had public keys being 
registered in lieu of passwords ... in much the same way that people 
register public keys as part of the registration authority part of a 
pki certification authority process.

http://www.garlic.com/~lynn/subpubkey.html#kerberos

machines then could have public keys to authenticate communicating with 
the trusted public key store (imagine it like real-time access to a 
certification authority ... in lieu of the stale, static digital 
certificates). to the extent that such machines can trust a repository 
of trusted certification authority public keys ... then they could also 
have a trusted repository of public keys for real-time communication 
with key store (where a key store might also be replicated for 
availability and scaling ... in manner analogous to the way DNS had 
replicated trusted servers).

http://www.garlic.com/~lynn/subpubkey.html#certless

it was only later that the draft succumbed to the pressure to also allow
PKI digital certificate mode of operation ... i.e. the machines rather 
than doing real-time authenticated communication with the trusted key 
store ... they might also use a local trusted public key repository to 
authentication certification authority digital signatures on stale, 
static digital certificates.


basically the key registration process is identical in the PKI digital 
certificate mode of operation and the certificateless public key mode of 
operation. the management of the trusted public key repository (of 
trusted root keys ... in one case for certification authorities, in the 
other case for the key store) on each machine is effectively also 
identical. however, the certificateless public key mode uses real-time 
communication with the key store ... while the PKI digital certificate 
mode substitutes the whole digital certificate issuing, management, 
administrative, etc infrastructure overhead (in lieu of the much simpler 
real time communication).



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Status of SRP

2006-06-03 Thread James A. Donald

--
Jeffrey Altman wrote:
 Unfortunately, SRP is not the solution to the phishing
 problem. The phishing problem is made up of many
 subtle sub-problems involving the ease of spoofing a
 web site and the challenges involved in securing the
 enrollment and password change mechanisms.

With SRP, the web site cannot be spoofed, for it must
prove it knows the  user's secret passphrase.

Now Wagner keeps complaining that the users are complete
morons, who could be taken in by a very shoddy spoof,
and no doubt that is true, but right now it is possible
to make a very good spoof, and that can be fixed.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 K0DkzvBcnUAkU1t725Cg9Fmh6awjA9b9S8SmmanA
 4HYHXPVEWxmojVTOmRDh7L/Eu6KRWMz3WCh5tL2Eq


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Status of SRP

2006-06-03 Thread James A. Donald

--
Lance James wrote:
 Here's where SRP fails:

 1) SSL is built into the browser - doesn't stop
 phishers

SSL protects true names, SRP protects true
relationships.  Protecting true names turned out to be
not very useful.

 Hi, we're having a problem with your account system
 as our SRP database was corrupted, please login
 through the webpage to verify your information and
 reset your SRP account to working order.

They set up their SRP account through the chrome, not
through a webpage.  This attack fails to mimic what is
routine.  Phishing relies on mimicry and habit. The
poorer the mimicry, the less people are likely to fall
for it.  Certainly some people will fall for it, there
is a sucker born every minute, but right now we are
seeing phishing attacks that quite sophisticated people
fall for.


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 7hBodKZ++GbmAsbf7YHZGQsErgEpvrEN+jMzkRVJ
 4jFzcd0zA2X0mdrrP52Wb9NZEOfARFgb0RMwwJCL7

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Status of SRP

2006-06-03 Thread Florian Weimer
* Ka-Ping Yee:

 Passpet's strategy is to customize a button that you click.  We
 are used to recognizing toolbar buttons by their appearance, so
 it seems plausible that if the button has a custom per-user icon,
 users are unlikely to click on a spoofed button with the wrong
 icon.  Unlike other schemes, such as special-looking windows or
 a custom image shown with the login form, this strategy requires
 the user to directly interact with the customized UI element.

I'm not sure if this can't be defeated by something like a Choose a
new funny icon for your security button! offer. 8-( However, this
points to a more general problem: We have no real-world studies how
users make their day-to-day trust decisions when using the Internet.

For example, if I need to judge the trustworthyness of a web page, a
large factor is the way I got there.  If it was a link from an email
message that looks like spam, or something that was returned by a
search engine, I'm rather sceptical.  This is why those 80% can't
tell a phishing page apart from the real one web-base studies are
quite worthless.  They simply do not present enough context.

| The field for entering your master password isn't labelled Enter
| your password: - instead, it's labelled Enter Betty's secret:.
| Since the persona differs from user to user, it's hard to even ask
| for the password because the spoofer doesn't know what to call it.

I suppose this can be circumvented if you you use email to lure the
victim to the fake web page and have obtained names matching the email
addresses.  Even if you want to present the full address to the
victim, you can buy this data from direct marketing companies, I
think.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Status of SRP

2006-06-03 Thread Florian Weimer
* Anne  Lynn Wheeler:

 Florian Weimer wrote:
 If you've deployed two-factor authentication (like German banks did in
 the late 80s/early 90s), the relevant attacks do involve compromised
 customer PCs. 8-( Just because you can't solve it with your technology
 doesn't mean you can pretend the attacks don't happen.

 EU finread terminal was countermeasure to (widely held impression
 that) PCs are extremely vulnerable to compromise.

You say that as if that assumption were unrealistic.
Transaction-rewriting malware is out in the wild. 8-(

FINREAD is really interesting.  I've finally managed to browse the
specs, and it looks as if this platform can be used to build something
that is secure against compromised hosts.  However, I fear that the
support costs are too high, and that's why it hasn't caught on in
retail online banking.

 card authentication required pin entry to work ... and finread
 terminal had its own PIN-pad distinct the vulnerable PC
 keyboard. orientation was towards transaction authentication ... with
 the finread terminal also having its own display of what was being
 authentication.

The interesting part is that it's possible to create an application
that runs exclusively on the trustworthy component and presents the
actual transaction data to the user before it is signed.

Previous card readers/smart card combinations relied on host software
to provide the display contents, without any way to check that it
matches the blob that was to be signed.  Of course, it's still
possible to develop a FINREAD application that behaves that way,
perhaps in order to cut down development costs.  As usual, just
because it's FINREAD, it's not automatically secure (and a
transparent mode exists as well).

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Status of SRP

2006-06-03 Thread Ka-Ping Yee
On Thu, 1 Jun 2006, Jeffrey Altman wrote:
 Solving the phishing problem requires changes on many levels:

I agree.

 (1) Some form of secure chrome for browsers must be deployed where
 the security either comes from a trusted desktop or by per-user
 customizations that significantly decrease the chances that the
 attacker can fake the web site experience.

What do you think of the various trusted-path ideas that have been
proposed?  In particular i'm curious what you think of the solution
i currently favour (the customized toolbar button), but some of the
others certainly seem promising (such as PwdHash's special hotkey
at the beginning of a password).

 (2) Reducing the number of accounts and passwords (or other identifiers)
 that end users need to remember.

Password hashing is one way to deal with this.  In Passpet's case,
the password is generated by hashing a master secret with a label
that you provide for each site.

 (3) Secure mechanisms must be developed for handling enrollment and
 password changing.

With Passpet, you would click the button to fill in the password on a
new account registration form, which generates a unique password for
the site.  To change your password, you would go to the site's account
settings page, click the button to fill in your old password, edit the
site label, then click the button again to get a new password.

Does that address the issues you had in mind, or were you thinking of
other situations?


-- ?!ng

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Status of SRP

2006-06-03 Thread Anne Lynn Wheeler

Florian Weimer wrote:

FINREAD is really interesting.  I've finally managed to browse the
specs, and it looks as if this platform can be used to build something
that is secure against compromised hosts.  However, I fear that the
support costs are too high, and that's why it hasn't caught on in
retail online banking.


if they can build a $100 PC ... you think that they could build a 
finread terminal for a couple bucks. sometimes there are issues with 
volume pricing ... you price high because there isn't a volume and there 
isn't a volume because you price high.


there is one issue missing from the actual FINREAD specification.

when we were doing X9.59 financial standard ... we allowed for a digital 
signature for authentication as well as for a digital signature from the 
environment that the transaction was performed in. the issue from a 
relying party standpoint ... is what assurances do they have as to the 
actual environment that a transaction was executed in. consumers could 
claim they were using a FINREAD terminal when they weren't. counterfeit 
FINREAD terminals could be out in the wild.


part of the x9.59 financial standard looked at the assurance/integrity 
that a relying party might have with regard to the actual authentication 
... one factor, two factor, three factor ... and the actual 
assurance/integrity of the associated factors (or conversely, how 
vulnerable were the factors to compromise). this somewhat led into also 
having to consider the assurance/integrity environment that the 
authentication took place in (and what assurances would a relying party 
have with regard to the environment).


part of it has been some past inclination to just specify some standard 
... w/o regard to how a relying party might actual have assurances as to 
whether some standard or another was being followed in an open 
environment (and considering threat scenarios that might involve 
compromise/impersonation of various components).


for instance, there was a recent scenario in the UK where crooks were 
impersonating maint. people and were updating secure POS terminals with 
compromised components.



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Status of SRP

2006-06-03 Thread Anne Lynn Wheeler

Anne  Lynn Wheeler wrote:
if they can build a $100 PC ... you think that they could build a 
finread terminal for a couple bucks. sometimes there are issues with 
volume pricing ... you price high because there isn't a volume and there 
isn't a volume because you price high.


re:
http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP

another aspect was that there was a program in the past to give away 
smartcards and card readers to consumers as part of doing smartcard 
financial transactions. the issue at the time was that deployed support 
for pc/sc standard only supported pc serial port interfaces ... and 
therefor the free card reader was a serial port device. there was an 
ensuing disaster as consumers tried to get the serial port device 
operational ... lots of stories of BSOD, having to re-install everything 
from scratch, etc. as the dust was settling, there was a quickly 
spreading opinion that smartcards (or at least smartcard readers) were 
not viable in the consumer market segment. it was during this period 
that m'soft even canceled its smartcard operating system project.


recent post discussing the subject:
http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means 
Pressed Flowers



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]