Re: Mozilla tool to self-verify HTTPS site
Marc Branchaud wrote: > > Ian Grigg wrote: > > > > Tying the certificate into the core crypto protocol seems to be a > > poor design choice; outsourcing any certification to a higher layer > > seems to work much better out in the field. > > I'll reserve judgement about the significance of SSLBar, but I couldn't > agree more with the above point. The only way to use non-X.509 certs > with TLS 1.0 is by rather clunkily extending the ciphersuites to also > identify some kind of certificate type. I'm currently reading Eric Rescorla's SSL&TLS book, and a significant proportion of the problems within the SSL/TLS protocol seem to come from the assumption that the cert should be supplied *within* the core protocol, and not outsourced to a higher layer. I.e., if SSL/TLS was re-written around this simple separation into two separate sub-protocols: 1. get the/a/all certificate(s) 2. use the key within a lot of the complexity would disappear. (I understand the argument that SSL/TLS does not "require" a cert, but to all intents and purposes, everything and everyone assumes it, AFAICS. As a practical issue, as it effects the implementations out there, I'm not sure it makes sense to even consider SSL/TLS without certs.) It seems to me to be a developing principle. We are all agreed that the delivery of (any/the) cert is a very hard problem. We are mostly agreed that it is an unsolved problem. So, as a corollary to the "hard problem," the key to use as the starting point for any crypto protocol should be provided to it, not bootstrapped within. (I wonder if there is a pithy way of stating this principle? Good crypto divorces bad PKIs? Cost effective crypto starts with an assumed key?) > IMO, this fact has significantly contributed to the lack of adoption of > PGP, SPKI, and alternative PKIs on the Internet. (I'm not quite sure what the issue here is with PGP ... it works fine without any certification, and it works slightly better when 3rd party sigs ("certs"?) are added by the user? Although I grant you that the key structure is .. costly to code, to the point of being impermeable to new implementations.) > TLS's new extension mechanism can help address this (see > draft-ietf-tls-openpgp-keys), but it'll be a while before extension > support is common. Yes, my company's protocol (SOX) "extends" the certificate layer by using OpenPGP. Configuring the issuance of a new monetary contract is a bit of a bear, in no small part due to the chain of signatures in the OpenPGP "PKI" that we use. But, it works, and it doesn't feel as though the big costly "PKI" process built out of OpenPGP slows down adoption any. [ We tried x.509 for a while, but it was a mistake; it lacked cleartext signing (minor point, we hacked our own) and its fixed PKI doesn't map to financial relationships, which are based on WoT, not centralised permissions. ] SSH chooses the simplest solution - opportunistic crypto - create the certs on demand and caching them for future checking. That is the best success formula I have seen so far. -- iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Mozilla tool to self-verify HTTPS site
Ian Grigg wrote: Tying the certificate into the core crypto protocol seems to be a poor design choice; outsourcing any certification to a higher layer seems to work much better out in the field. I'll reserve judgement about the significance of SSLBar, but I couldn't agree more with the above point. The only way to use non-X.509 certs with TLS 1.0 is by rather clunkily extending the ciphersuites to also identify some kind of certificate type. IMO, this fact has significantly contributed to the lack of adoption of PGP, SPKI, and alternative PKIs on the Internet. TLS's new extension mechanism can help address this (see draft-ietf-tls-openpgp-keys), but it'll be a while before extension support is common. M. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Mozilla tool to self-verify HTTPS site
[EMAIL PROTECTED] wrote: > How many users can remember MD5 checksums??? If they were rendered into > something pronounceable via S/Key like dictionaries it might be more > useful... Apologies, last night's answer was too brief to be useful! Here's the more detailed and coffee charged explanation: Printing out a fingerprint allows a PGP-ite to feel comfortable, but we all know there are precious few of those on the planet. So the expected benefit to security is fairly low. We don't get much bang for our buck here, so we're agreed on that point. In reality, the importance of the tool is that it signifies - to me at least - that the browser maufacturers (which I conveniently enlarge to include plug-in makers :) are beginning to address the security failures in secure browsing. In small steps, but they are now facing towards the threat, at least. Maybe. I hope. Also, SSLbar isolates and addresses what I percieve to be a questionable design feature in SSL: the certificate and its delivery as an integral and assumed part of SSL. Here, this tool specifically challenges that feature and allows for out-of-band checking of the certificate. It ignores or supplements the debatable assumption that browsers make: a certificate is good if and only if it is signed by a known CA. That's a good thing, IMHO. Tying the certificate into the core crypto protocol seems to be a poor design choice; outsourcing any certification to a higher layer seems to work much better out in the field. (E.g., PGP, SSH, SOX, Eric B's cryptophone.) -- iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Mozilla tool to self-verify HTTPS site
[EMAIL PROTECTED] wrote: > How many users can remember MD5 checksums??? If they were rendered into > something pronounceable via S/Key like dictionaries it might be more > useful... You forgot this bit: > It's a small step for the user, but a giant leap > for userland security. It means that someone is > thinking about solving the hacks against secure > browsing. Caching and distributing techniques > for certificates can't be that far off... -- iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Mozilla tool to self-verify HTTPS site
On Tue, 24 Jun 2003, Ian Grigg wrote: > http://sslbar.metropipe.net/ > > Fantastic news: coders are starting to work > on the failed security model of secure browsing > and improve it where it matters, in the browser. > > This plugin for Mozilla shows the SSL certificate's > fingerprint on the web browser's toolbar. > How many users can remember MD5 checksums??? If they were rendered into something pronounceable via S/Key like dictionaries it might be more useful... -- Viktor. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Mozilla tool to self-verify HTTPS site
http://sslbar.metropipe.net/ Fantastic news: coders are starting to work on the failed security model of secure browsing and improve it where it matters, in the browser. This plugin for Mozilla shows the SSL certificate's fingerprint on the web browser's toolbar. It's a small step for the user, but a giant leap for userland security. It means that someone is thinking about solving the hacks against secure browsing. Caching and distributing techniques for certificates can't be that far off... -- iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]