Re: WYTM?
On 10/16/2003 07:19 PM, David Honig wrote: it would make sense for the original vendor website (eg Palm) to have signed the MITM site's cert (palmorder.modusmedia.com), not for Verisign to do so. Even better, for Mastercard to have signed both Palm and palmorder.modusmedia.com as well. And Mastercard to have printed its key's signature in my monthly paper bill. Bravo. Those are golden words. Let me add my few coppers: 1) This makes contact with a previous thread wherein the point was made that people often unwisely talk about identities when they should be talking about credentials aka capabilities. I really don't care about the identity of the order-taking agent (e.g. palmorder.modusmedia.com). What I want to do is establish the *credentials* of this *session*. I want a session with the certified capability to bind palm.com to a contract, and the certified capability to handle my credit-card details properly. 2) We see that threat models (as mentioned in the Subject: line of this thread), while an absolutely vital part of the story, are not the whole story. One always needs a push-pull approach, documenting the good things that are supposed to happen *and* the bad things that are supposed to not happen (i.e. threats). 3) To the extent that SSL focuses on IDs rather than capabilities, IMHO the underlying model has room for improvement. 4a) This raises some user-interface issues. The typical user is not a world-class cryptographer and may not have a clear idea just what ensemble of credentials a given session ought to have. This is not a criticism of credentials; the user doesn't know what ID the session ought to have under the current system, as illustrated by the Palm example. The point is that if we want something better than what we have now, we have a lot of work to do. 4b) As a half-baked thought: One informal intuitive notion that users have is that if a session displays the MasterCard *logo* it must be authorized by MasterCard. This notion is enforceable by law in the long run. Can we make it enforceable cryptographically in real time? Perhaps the CAs should pay attention not so much to signing domain names (with some supposed responsibility to refrain from signing abusively misspelled names e.g. pa1m.com) but rather more to signing logos (with some responsibility to not sign bogus ones). Then the browser (or other user interface) should to verify -- automatically -- that a session that wishes to display certain logos can prove that it is authorized to do so. If the logos check out, they should be displayed in some distinctive way so that a cheap facsimile of a logo won't be mistaken for a cryptologically verified logo. Even if you don't like my half-baked proposal (4b) I hope we can all agree that the current ID-based system has room for improvement. = Tangentially-related point about credentials: In a previous thread the point was made that anonymous or pseudonymous credentials can only say positive things. That is, I cannot discredit you by giving you a discredential. You'll just throw it away. If I somehow discredit your pseudonym, you'll just choose another and start over. This problem can be alleviated to some extent if you can post a fiduciary bond. Then if you do something bad, I can demand compensation from the agency that issued your bond. If this happens a lot, they may revoke your bond. That is, you can be discredited by losing a credential. This means I can do business with you without knowing your name or how to find you. I just need to trust the agency that issued your bond. The agency presumably needs to know a lot about you, but I don't. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
Ian Grigg [EMAIL PROTECTED]: I agree. As a side note, I think it is probably a good idea for TLS to deprecate ADH, simply because self-signed certs are more or less equivalent, and by unifying the protocol around certificates, it reduces some amount of complexity without major loss of functionality. Actually the anonymous DH ciphersuites can be (and are) employed to implement *authenticated* DH by using non-TLS means for authentication. (Specifically, what you can do is authenticate the TLS Finished messages, which involve hashes of the complete handshake.) This can be useful for using TLS in protocols without tainting them with X.509, and without creating specific new TLS ciphersuites. It is true that TLS would be (slightly) less complex if it didn't have both certificate-based and certificate-less ciphersuites. But TLS as employed in such protocols would become more complex if you had to use self-signed certificates (meaning that implementations would have to be able to parse X.509 stuff that currently can do without it). Also note that using a self-signed certificate means that you actually have to sign it (after all, the peer might try and verify it). This means additional private-key operations, and thus makes the protocol slower. Bottom line: Deprecating TLS ADH in favor of self-signed certificates would reduce complexity in a certain sense, but add complexity in other contexts. It also would make the handshake slower. I don't think it would be a good idea. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
Tim Dierks [EMAIL PROTECTED]: Ian Grigg [EMAIL PROTECTED]: Steven M. Bellovin: What's your threat model? Self-signed certs are no better than ADH against MITM attacks. I agree. As a side note, I think it is probably a good idea for TLS to deprecate ADH, simply because self-signed certs are more or less equivalent, and by unifying the protocol around certificates, it reduces some amount of complexity without major loss of functionality. (AFAIK, self-signed certs in every way dominate ADH in functional terms.) In TLS, AnonDH offers forward secrecy, but there are no RSA certificate modes which do (except for ExportRSA). You can use ephemeral DH key agreement keys with static certified DSA keys, though. To be clear, this is a protocol issue, not really a self-signed certs vs. DH issue. From a different point of view, this is not even a protocol issue ... it is an RSA issue: When using self-signed certificates, nothing stops you from creating a new key and certificate every now and then. The only slight problem is that key generation for RSA is quite slow, compared with key generation for logarithm-based cryptosystems; you probably wouldn't want to create an RSA key for every incoming connection. But, on typical server hardware, it is no problem at all to create an RSA key every couple of minutes or so. While generally among the RSA-based TLS ciphersuites, only the RSA_EXPORT ones provide forward secrecy (thanks to an ephemeral 512-bit RSA key), in the case of self-signed certificates the distinction between export-restricted and other RSA ciphercuites is not an issue as far as forward secrecy is concerned. [Even when using proper certificates from some CA, you could provide forward secrecy for RSA ciphersuites: Instead of obtaining an end-entity certificate and directly using it on the TLS cipher, obtain a CA certificate with nameConstraints appropriately limited. Then the server can sign its own end-entity certificates without resorting to self-signed certificates in the usual sense. This allows the server to use newly created keys whenever it feels like it.] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Feds admit error in hacking conviction
http://news.com.com/2100-7348_3-5092697.html?tag=st_lh Federal prosecutors asked a San Francisco appeals court this week to reverse a computer-crime conviction that punished a California man for notifying a company's customers of a flaw in the company's e-mail service. Filed on Tuesday in San Francisco's Ninth District Court of Appeals, the unusual request conceded that federal prosecutors in Los Angeles erred in bringing a criminal case against, and obtaining the conviction of, 30-year-old Bret McDanel. The one-time system administrator has already served his 16-month sentence and is currently on supervised release, during which time his access to computers is curtailed. ... If the court agrees to overturn the conviction, it will remove a precedent that could have squelched the research of many security experts. The original conviction by U.S. District Judge Lourdes G. Baird determined that, by revealing a flaw in a system's security, a researcher could be accused of harming the system, a violation of computer crime laws. ... Thom Mrozek, a spokesman for the U.S. attorney's office for the Central District of California said that prosecutors rarely ask for a reversal. It's pretty damn rare, he said. I have never seen it happen. ... -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
On Fri, 2003-10-17 at 00:58, John S. Denker wrote: Tangentially-related point about credentials: In a previous thread the point was made that anonymous or pseudonymous credentials can only say positive things. That is, I cannot discredit you by giving you a discredential. You'll just throw it away. If I somehow discredit your pseudonym, you'll just choose another and start over. This problem can be alleviated to some extent if you can post a fiduciary bond. Then if you do something bad, I can demand compensation from the agency that issued your bond. If this happens a lot, they may revoke your bond. That is, you can be discredited by losing a credential. This means I can do business with you without knowing your name or how to find you. I just need to trust the agency that issued your bond. The agency presumably needs to know a lot about you, but I don't. One can claim this is what a credit card does for the consumer the name on the card is somewhat tangential to it being a credential; it is there so that the merchant can authenticate the credential by cross checking the name on the card with names on other credentials that you might be carrying. If you have enuf credentials with the same name ... then it eventually satisfies the merchant that it is your credential. Some number of places are taking the name off the card as part of improving consumer privacy at point-of-sale. They can do this with debit where the PIN is a substitution for otherwise proving it is your credential. however, as previously posted there is a lot of skimming going an with the information for making a counterfeit card as well as skarfing up the corresponding PIN is being done. This is also being done with some kinds of chip cards where a PIN is involved but since the infrastructure trusts the cards the counterfeit cards are programmed to accept any PIN see the yes card at the bottom of the following URL. http://www.smartcard.co.uk/resources/articles/cartes2002.html The issue is that technique used to skim static data for making counterfeit magstripe cards also applies to skimming static data for making counterfeit yes cards. The claim in X9.59 is that the signature from something like an asuretee card ... can both demonstrate two (or three) factor authentication as well as proving that the transaction hasn't been tampered with since it was signed. In this case, while the card may still look like an (offline) credential from pre-1970s (with printed credential revokation lists mailled out every month to all merchants) it, in fact does an online transaction. The digital signature proving 2/3 factor authenticaiton (and no transaction tampering during transit) is then accepted (or not) by the financial institution which reports back real-time result to the relying party (merchant). This is a move from the ancient offline paradigm that has been going on for hundreds of years (with credentials as substitute for real-time interaction) to an online paradigm. While the form-factor may still appear the same as the rapidly becoming obsolete offline credential; it is actually operating as a long-distance 2/3 factor authentication mechanism between the consumer and their financial institution with the merchant/relying-party getting back a real-time response as to whether the institution stands behind the request. The difference between the x9.59/asuretee implementation and the yes card implementation is that there is no static data to skim (and use for creating counterfeit cards/transactions). misc. x9.59 refs: http://www.garlic.com/~lynn/index.html#x959 misc. aads chip strawman asuretee refs: http://www.garlic.com/~lynn/index.html#aads The integrity of the chipcard and the integrity of the digital signature substitutes for requiring the merchants to cross-check the name on the card with the names on an arbitrary number of other credentials until they are comfortable performing the transaction. The current (non-PIN card) infrastructure is sort of half way between the old style everything is a credential and the new everything is online to a fully trusted online infrastructure. The magstripe does an online transaction and the institution will approve the transactions with some number of caveats regarding it not being a counterfeit/fraudulent transaction. For the non-PIN transactions, the merchant (can) uses the name on the card to cross check with as many other credential names until the merchant becomes comfortable. This is similar to the scenario with the existing SSL domain name certificate issuing process (using names mapping to common/real-world identities in order to achieve authentication). The domain name system registers the owner's name. The CA SSL certificate issuer obtains a name of the certificate requester and then the CA attempts to map the two names into the same real world identities as a means of achieving authentication. The
