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
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]
