Re: Status of opportunistic encryption
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
oh, and some number of certification authorities actually backed some parts of DNSSEC ... including the idea that people register a public key when they registered a domain name. this was countermeasure to various kinds of domain name hijacking vulnerabilities ... i.e. the domain name owner would digitally sign communication ... and the domain name infrastructure would validate the digital signature with the onfile public key. this became attractive to certification authorities. currently they require a ssl domain name certificate application to supply a lot of identification information. the certification authority then performs the time-consuming, error prone, and expensive process of matching the supplied identification information with the information on file with the domain name infrastructure. with communication authenticated with the onfile public keys, there is a reduction in the chance of domain name hijacking ... and therefor the certification authority has higher level of assurance that they aren't dealing with a ssl domain name certificate applicant that has just hijacked the domain name. also, if the public keys were on file with the domain name infrastructure, then certification authorities could require that application for ssl domain name certificates be digitally signed. then the certification authorities could change from a time-consuming, error prone, and expensive process of matching identification information to the less-expensive and more reliable process of simply authenticating the digital signature. they would execute dnssec protocol with the domain name infrastructure requesting real-time retrieval of the onfile public key for the domain name. they would validate the response with DNSSEC trusted root public key on file in their local repository of trusted dnssec public keys (in much the same way that the existing PKI infrastructure validate digital signatures on digital certificates using CA public key from their local repository of trusted (CA) public keys). This whole thing then goes to the root of improving the integrity of the SSL domain name certificate infrastructure. The catch22 for the certification authority infrastructure is that if they can start retrieving real-time public keys for authenticating digital signatures on ssl domain name certificate applications ... then possibly the rest of the world could also start using DNSSEC to also do real-time retrieval of onfile public keys from the domain name infrastructure. one might even imagine a highly optimized SSL type session protocol where instead of the existing protocol chatter exchange ... the servers on-file public key could piggyback on the standard DNS response for hostname->ipaddress. the client in the initial transmission send a random session key encrypted with the server's public key. a few recent posts mentioning this catch22 dilemma for the SSL domain name certificate industry: http://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh http://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing" http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh http://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of opportunistic encryption
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
-- 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
-- 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
* 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
* 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
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
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
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]
