Re: Dutch Transport Card Broken
Victor Duchovni wrote: SMTP does not need TCP to provide reliability for the tail of the session, the application-level . (end-of-data) and server 250 response complete a transaction, everything after that is optional, so for example Postfix will send (when PIPELINING). DATACRLF354 Go ahead Message-Content Lots of acks .CRLFQUITCRLF 250 Ok and will disconnect after reading the 250 response without waiting for the 221 response. The TCP 3-way shutdown (FIN, FIN-ACK, ACK) happens in the kernel in the background, the SMTP server and client are by that point handling different connections. So the reliable shutdown latency is of no consequence for application throughput. A pipelined SMTP delivery can be completed over TCP in 5 RTTs not 7. 0. SYN SYN-ACK 1. ACK 220 2. EHLO 250 3. MAIL RCPT DATA 250 250 354 4. MSG . QUIT 250 221 5. close socket TCP is fine, latency is primarily the result of application protocol details, not TCP overhead. The only TCP overhead above is 1 extra RTT for the connection setup. Everything else is SMTP not TCP, and running SMTP over UDP (with ideal conditions and no lost packets, ...) would save just 1 RTT. re: http://www.garlic.com/~lynn/aadsm28.htm#21 Dutch Transport Card Broken sorry, I didn't say that TCP required seven round-trips for reliable exchange; the statement was that minimum TCP operation was seven packet exchange (for reliable operation) sort of 3.5 round-trips. That VMTP (rfc 1045) reduced that to minimum of five packet exchange (sort of 2.5 round-tips) ... and that XTP got it to a minimum of three packet exchange (sort of 1.5 round-trips) for reliable operation. from my RFC index http://www.garlic.com/~lynn/rfcietff.htm rfc 1045 summary http://www.garlic.com/~lynn/rfcidx3.htm#1045 1045 E VMTP: Versatile Message Transaction Protocol: Protocol specification, Cheriton D., 1988/02/01 (123pp) (.txt=264928) (Refs 955, 966, 969) (Ref'ed By 1050, 1072, 1105, 1106, 1190, 1263, 1323, 1453, 1458, 1700, 2018, 2375, 2757) (VMTP) as always, clicking on the .txt=nnn field (in rfc summary) retrieves the actual RFC. If there is more than minimum amount of data ... TCP might involve more than seven packet exchange ... but the minimum packet exchange is seven packets (not round-trips). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
Sandy Harris [EMAIL PROTECTED] writes: What I don't understand is why you think tinc is necessary, or even worth the trouble. IPsec is readily available -- built into Windows, Mac OS and various routers, and with implementations for Linux and all the *BSDs -- has had quite a bit of expert security analysis, and handles VPNs just fine. Does tinc do something that IPsec cannot? I use a VPN system other than IPSec on a regular basis. The reason is simple: it is easy to configure for my application and my OS native IPsec tools are very difficult to configure. There is a lesson in this, I think. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
(as if anyone uses client certificates anyway)? Guess why so few people are using it ... If it were secure, more people would be able to use it. People don't use it because the workload of getting signed up is vastly beyond their skillset, and the user experience using the things is pretty bad too. And there are hundreds of internal systems I heard of that are using client certificates in reality every day. There's always a few people using a technology. It's certainly a nonplayer out there. Probably more servers out there authing with Digest, honestly. Validated email addresses for spamming. Spear-phishing perhaps, ... There are CA´s on this planet that put things like social security numbers into certificates. Who? Seriously, that's pretty significant, I'd like to know who does this. Where does the SSL specification say that certificates shouldn´t contain sensitive information? I am missing that detail in the security consideration section of the RFC. The word public in Public Key isn't exactly subtle. Do we have any more ideas how we can get this flaw fixed before it starts hurting too much? Make it really easy to use some future version of SSL client certs, and quietly add the property you seek. Ease of use drives technology adoption; making the tech actually work is astonishingly secondary. Heh, you asked :) We have an issue here. And the issue isn´t going to go away, until we deprecate SSL/TLS, or it gets solved. To be clear, we'd *have* an issue, if any serious number of people used SSL client certs. I think you have a point that if SSL client certs become very popular going forward, then every website you go to will quietly grab your identity through their ad banners. * We fix SSL Does anyone have a solution for SSL/TLS available that we could propose on the TLS list? If not: Can anyone with enough protocol design experience please develop it? What solution could there be? You're actually going to SSL to the banner ad network, and you're going to give them your client cert. * We deprecate SSL for client certificate authentication. We write in the RFC that people MUST NOT use SSL for client authentication. (Perhaps we get away by pretending that client certificates accidently slipped into the specification.) People by in large do not use SSL client cert authentication. This is problematic, as there's some very nice cryptographic aspects of the system. * We switch from TLS to hmmm ... perhaps SSH, which has fixed the problem already. Hmm, there we would have to write all the glue RFCs like HTTP over SSH again ... I used to code for SSH. SSL is an entire top-to-bottom stack, replete with a deep PKI infrastructure. SSH? Tunneling transport, barely even librarized. Try to send a DVD iso image (4GB) over a SSL or SSH encrypted link with bit errors every 1 bits with a client software like scp that cannot resume downloads. I gave up after 5 tries that all broke down in average after 1 GB. (In that case it was a hardware (bad cable) initiated denial of service attack ;-) The problem here isn't checksums. SSH is notoriously buggy when packets are dropped. I think there are certain windows in which OpenSSH assumes it will get a response. If it doesn't, it just dies. So, outages more than a few hundred milliseconds have a small percentage chance of causing the session to permanently stall. Corrupted MAC on input -- this is a decent sign of corruption at the app layer. Did you really try this with OpenSSL? I've had much better luck there. If the link layer gives you 1/256, and the TCP layer gives you 1/65536, and the SSL layer demands 0/16777216, then end up with 1/16777216 too much. Actually, 256*65536 = 1677216 :) In actuality, you have both IP and TCP checksums. So you get 8 bits from link, 16 bits from IP, and 16 bits from TCP. A random corrupt packet has about 2^40 odds of getting through. Of course, one real problem is that the checksum algorithms don't exactly distribute noise randomly, and noise is not random. Still, corruption doesn't start being a problem until you get some pretty serious amounts of transfer. (Interestingly, I've been looking at IPsec lately, not for encryption, but for better checksumming.) Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
Guus Sliepen wrote: Peter's write-up was the reason I subscribed to this cryptography mailing list. After a while the anger/hurt feelings I had disappeared. I knew then that Peter was right in his arguments. Nowadays I can look at Peter's write-up more objectively and I can see that it is not as ad-hominem as it felt back then, although the whole soundwave paragraph still sounds very childish ;) When tinc 2.0 will ever come out (unfortunately I don't have a lot of time to work on it these days), it will probably use the GnuTLS library and authenticate and connect daemons with TLS. For performance reasons, you want to tunnel network packets via UDP instead of TCP, so hopefully there is a working DTLS implementation as well then. I have been considering the problem of encrypted channels over UDP or IP. TLS will not work for this, since it assumes and provides a reliable, and therefore non timely channel, whereas what one wishes to provide is a channel where timeliness may be required at the expense of reliability. I have figured out a solution, which I may post here if you are interested. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Victor Duchovni wrote: Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds round-trips to SSL warrants some evidence (it is very temping to express this skepticism more bluntly). With unextended SMTP for example, the minimum RTT count is: 0. SYN SYN-ACK 1. ACK 220 2. HELO 250 3. MAIL 250 4. RCPT 250 ... n recipients RCPT 250 4+n DATA 354 5+n ... stream of message content segments CRLF.CRLF 250 so it takes at least 6 RTTs to perform a delivery (of a short single-recipient message), but only 1 of the 6 RTTs is TCP overhead. This is improved with PIPELINING: 0. SYN SYN-ACK 1. ACK 220 2. EHLO 250 ... PIPELINING ... 3. MAIL RCPT(n times) DATA 250 250 (n times) 354 4. ... stream of message content segments CRLF.CRLF 250 Here the application protocol is pipelined, and 5+n RTTs becomes 4 RTTs. The solution is not replacing TCP, but reducing the number of lock-step interactions in the application protocol. If someone has a faster than 3-way handshake connection establishment protocol that SSL could leverage instead of TCP, please explain the design. You are asking for a layered design that works better than the existing layered design. My claim is that you get an additional round trip for each layer - which your examples have just demonstrated. SSL has to be on top of a reliable transport layer, hence has to have an extra round trip. I was not proposing something better *for* SSL, I was proposing something better *instead* *of* SSL. If one takes SSL as a given, then indeed, *three* round trips are needed before the client can send any actual data - which is precisely my objection to SSL. The TCP handshake adds a 1-RTT delay at the start of the connection. What 0-RTT algorithm will allow the server to delay creating expensive connections to clients until the client acks the server response or discover the MSS before sending the first segment? With TCP, at least SYN floods require unspoofed client IPs. Most of the application protocols we wrap in TLS are not DNS. Sure if you can guarantee a single packet response to a single packet request, TCP is not the answer. Otherwise, claiming that SSL is less efficient over TCP smacks of arrogance. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
On Wed, Jan 30, 2008 at 02:47:46PM -0500, Victor Duchovni wrote: If someone has a faster than 3-way handshake connection establishment protocol that SSL could leverage instead of TCP, please explain the design. I don't have one that exists today and is practical. But we can certainly imagine possible ways to improve this situation: move parts of TLS into TCP and/or IPsec. There are proposals that come close enough to this (see the last IETF SAAG meeting's proceedings, see the IETF BTNS WG) that it's not too farfetched, but for web stuff I just don't think they're remotely likely. Prior to the advent of AJAX-like web design patterns the most noticeable latency in web apps was in the server (for dynamic content) and the client (re-rendering the whole page on every click). Applying GUI lessons to the web (asynchrony! callbacks/closures!) fixed that. TLS was not to blame. TLS probably still isn't to blame for whatever latency users might be annoyed by in web apps. It's *much* easier to look for improvements in the app layer first given that web app updates are much easier to deploy than TLS (which in turn is much easier to deploy than changes to TCP or IPsec). Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Eric Rescorla wrote: (as if anyone uses client certificates anyway)? Guess why so few people are using it ... If it were secure, more people would be able to use it. No, if it were *convenient* people would use it. I know of absolutely zero evidence (nor have you presented any) that people choose not to use certs because of this kind of privacy issue--but I know of plenty that they find getting certs way too inconvenient. In a CA I have something to do with, I'm observing a site that just started experimenting with client certs (100 users, will reach 1000, maybe more). When we discovered that the certificate includes PII (personally identifying information) and the website stores additional PII, the service was directed to drop all additional PII, and some thought was put into the in-cert PII. Current view is that the service must engage the user in a contract to accept the storing of that in-cert PII, otherwise it must not store the info in the cert (which means no identity, no persistence, and no point to the client certs). Writing contracts and securing agreement of course is a barrier, a burden. If this were a general requirement, then this would be enough (imho) to not recommend client certs, because contracts need lawyers, they cost real money, they don't solve the problem, and not recommending them is likewise unacceptable. (Then, as you say, there are convenience issues.) This is an experiment to force client certs to be used, so they are plugging on. It's a CA so it is trying to prove that there is value in these things. So... there are two slight variations that could be employed. Firstly, all data placed in the cert could be declared public in advance, and then no contract is required to use it in a context that is compatible with public data. That is, the question of the contract is pushed to the CA/CPS. (You mentioned that the premise is that it is all public data...) Another variation is to switch to username + password, of course, in which case the username is freely given and expected to be stored (certs being more or less invisible to users, so we can presume no such). (definately open to other ideas...) The PII equation is particularly daunting, echoing Lynn's early '90s experiences. I am told (but haven't really verified) that the certificate serial number is PII and therefore falls under the full weight of privacy law regs ... this may sound ludicrous, but privacy and security are different fields with different logics. If that is true, the liability is far too high for something that should be private, but is already public by dint of its exposure in certificates. Privacy liabilities are sky-high in some places, and not only that, they are incalculable, unknowable, and vary with the person you are talking to. So a superficial conclusion would be don't use client certificates because of the privacy issues although the issues are somewhat more complex than PII revealed in SSL key exchange. As I say, they'll plug on, as they need to prove that the cert is worth issuing. It's a data point, no more, and it doesn't exactly answer your spec above. But I'm having fun observing them trying to prove that client certs are worth any amount of effort. iang PS: normal disclosures of interest + conflicts, included. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Victor Duchovni [EMAIL PROTECTED] writes: Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds round-trips to SSL warrants some evidence (it is very temping to express this skepticism more bluntly). If anyone's interested, I did an analysis of this sort of thing in an unpublished draft Performance Characteristics of Application-level Security Protocols, http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf. It compares (among other things) the cost in RTT of several variations of SSL and SSH. It's not the TCP RTTs that hurt, it's all the handshaking that takes place during the crypto connect. SSH is particularly bad in this regard. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
At Fri, 01 Feb 2008 18:42:03 +1000, James A. Donald wrote: Guus Sliepen wrote: Peter's write-up was the reason I subscribed to this cryptography mailing list. After a while the anger/hurt feelings I had disappeared. I knew then that Peter was right in his arguments. Nowadays I can look at Peter's write-up more objectively and I can see that it is not as ad-hominem as it felt back then, although the whole soundwave paragraph still sounds very childish ;) When tinc 2.0 will ever come out (unfortunately I don't have a lot of time to work on it these days), it will probably use the GnuTLS library and authenticate and connect daemons with TLS. For performance reasons, you want to tunnel network packets via UDP instead of TCP, so hopefully there is a working DTLS implementation as well then. I have been considering the problem of encrypted channels over UDP or IP. TLS will not work for this, since it assumes and provides a reliable, and therefore non timely channel, whereas what one wishes to provide is a channel where timeliness may be required at the expense of reliability. DTLS: RFC 4347. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Ian G wrote: The PII equation is particularly daunting, echoing Lynn's early '90s experiences. I am told (but haven't really verified) that the certificate serial number is PII and therefore falls under the full weight of privacy law regs ... this may sound ludicrous, but privacy and security are different fields with different logics. If that is true, the liability is far too high for something that should be private, but is already public by dint of its exposure in certificates. Privacy liabilities are sky-high in some places, and not only that, they are incalculable, unknowable, and vary with the person you are talking to. So a superficial conclusion would be don't use client certificates because of the privacy issues although the issues are somewhat more complex than PII revealed in SSL key exchange. As I say, they'll plug on, as they need to prove that the cert is worth issuing. It's a data point, no more, and it doesn't exactly answer your spec above. But I'm having fun observing them trying to prove that client certs are worth any amount of effort. the problem that digital certificates were suppose to address was first time communication between strangers ... the electronic analogy of the letters of credit/introduction from sailing ship days. this harks back to the offline email days of the early 80s ... dial-up electronic post-office, exchange email, hangup, and now authenticate first-time email from total stranger. the design point assumptions are invalidated if the relying party has their own repository of information about the party being dealt with (and therefor can included that party's public key) and/or has online, timely electronic access to such information. one of my favorite exchanges from the mid-90s was somebody claiming that adding digital certificates to the electronic payment transaction infrastructure would bring it into the modern age. my response was that it actually would regress the infrastructure at least a couple decades to the time when online, real-time transactions weren't being done. The online, real-time transaction provides much higher quality and useful information than a stale, static digital certificate (with an offline paradigm from before modern communication). Having an available repository about the party being dealt with ... including things like timely, aggregated information (recent transactions) is significantly mover valuable than the stale, static digital certificate environment (the only thing that it has going for it, is it is better than nothing in the oldtime offline environment). misc. past posts referencing certificate-less public key operation http://www.garlic.com/~lynn/subpubkey.html#certless for some real topic drift ... i've mentioned x9.59 financial standard protocol that can use digital signatures for authentication w/o requiring digital certificates http://www.garlic.com/~lynn/x959.html#x959 part of the issue included that digital certificates (even relying party only digital certificates) can add a factor of one hundred times payload bloat to a typical payment transaction http://www.garlic.com/~lynn/subpubkey.html#bloat however, we were also got involved in co-authoring the x9.99 privacy standard ... as part of that we had to look at a number of things, HIPAA, GLBA ... as well as EU-DPD. as part of that we had also done a privacy merged taxonomy and glossary ... some notes http://www.garlic.com/~lynn/index.html#glosnote EU had also made a statement in the mid-90s that electronic retail payments should be as anonymous as cash. The dominant use of SSL in the world today is electronic commerce between a consumer and a merchant. Passing a client certificate (with PII information) within an encrypted SSL channel to a merchant ... still exposes the information to the merchant ... also violating making purchases as anonymous as cash. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Nicolas Williams wrote: I don't have one that exists today and is practical. But we can certainly imagine possible ways to improve this situation: move parts of TLS into TCP and/or IPsec. There are proposals that come close enough to this (see the last IETF SAAG meeting's proceedings, see the IETF BTNS WG) that it's not too farfetched, but for web stuff I just don't think they're remotely likely. my view of ipsec was that it faced a significant barrier to entry since it required upgrading lots of installed kernels all over the infrastructure (aka tcp/ip protocol stack have been integrated kernel implementations) both SSL and VPN offered implementations that require having to upgrade existing deployed kernels (something that has gotten somewhat easier in the last decade plus). about the same time as SSL, a friend that we had worked on off with over a couple decades introduced what was to become called VPN in gateway committee at fall '94 IETF meeting in san jose. my view was this resulted in some amount of consternation with the ipsec forces as well as some of the router vendors. the ipsec forces were somewhat mollified by being able to refer to vpn as lightweight ipsec (while others then would refer to ipsec as heavyweight ipsec). the initial proposal involved border routers providing authentication and (encryption) tunneling through the internet. some of the router vendors had processors that could handle the encryption load. however, there was opposition from the router vendors that didn't have products with processors that could handle the encryption load (or at least stalling until they had such a product). in any case, uptake of both SSL and VPN ... was the significantly easier and less complex deployment ... vis-a-vis ipsec. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
James A. Donald [EMAIL PROTECTED] writes: When tinc 2.0 will ever come out (unfortunately I don't have a lot of time to work on it these days), it will probably use the GnuTLS library and authenticate and connect daemons with TLS. For performance reasons, you want to tunnel network packets via UDP instead of TCP, so hopefully there is a working DTLS implementation as well then. I have been considering the problem of encrypted channels over UDP or IP. TLS will not work for this, since it assumes and provides a reliable, and therefore non timely channel, whereas what one wishes to provide is a channel where timeliness may be required at the expense of reliability. DTLS does not assume a reliable channel -- it is designed for applications that use UDP. Perhaps you are not familiar with it. I have figured out a solution, which I may post here if you are interested. With respect, James, I think they'd be better off using DTLS. It was designed by experts and it shares the same security properties as TLS. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
On Thu, Jan 31, 2008 at 04:07:03PM +0100, Guus Sliepen wrote: Peter sent us his write-up up via private email a few days before he posted it to this list (which got it on Slashdot). I had little time to think about the issues he mentioned before his write-up became public. When it did, I (and others too) felt attacked in a cruel way. Peter ignored all the reasons *why* we used the kind of crypto we did at that moment, compared it to a very high standard, and made it feel like every thing we didn't do or didn't do as well as SSL made our crypto worthless. There is no valid reason to ship snake oil cryptography (at any moment). There is no standard but a high standard which is appropriate for comparison. Since SSL was already available, there was no excuse to do anything worse. It seems that you still don't understand those things, or you would not complain about them even at this far removed date. How unfortunate. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
On Thu, Jan 31, 2008 at 03:46:47PM -0500, Thor Lancelot Simon wrote: On Thu, Jan 31, 2008 at 04:07:03PM +0100, Guus Sliepen wrote: Peter sent us his write-up up via private email a few days before he posted it to this list (which got it on Slashdot). I had little time to think about the issues he mentioned before his write-up became public. When it did, I (and others too) felt attacked in a cruel way. Peter ignored all the reasons *why* we used the kind of crypto we did at that moment, compared it to a very high standard, and made it feel like every thing we didn't do or didn't do as well as SSL made our crypto worthless. There is no valid reason to ship snake oil cryptography (at any moment). There is no standard but a high standard which is appropriate for comparison. Since SSL was already available, there was no excuse to do anything worse. Please understand the following: I am not defending the use of our less-than-SSL crypto in tinc. But there are reasons why we implemented it the way we did at that time. It doesn't matter whether these reasons were bad or good. The result of ignoring the why, and attacking others by pointing out everything they do wrong in your perspective (even though your perspective is perfectly right), and then finishing off the way Peter did, which is easily perceived as an insult if you are on the receiving end of it, does not encourage others to fix the problems, but rather puts others in defensive mode. Are you out to help others, or just to look down on them? If it's the first, then please make others accept your help by just formulating things in a more friendly way (although a patch with a fix would soften up things as well). If it's the latter, please continue just as you are doing now. Now some (good and/or bad) reasons why we ended up with our lesser-than-SSL crypto, in no particular order: - SSL was not perceived at that time as a solution for our problem. - We were application writers, not security specialists. We had to encrypt traffic, we did the best to our knowledge at that time. - I had read Schneier's Applied Cryptography from front to end a few times. It made me feel I knew everything about crypto. Even Bruce admits he thought at that time he had put everything a programmer needed to know about crypto in that book. It doesn't mention SSL. - We needed to tunnel data over UDP, with UDP semantics. SSL requires a reliable stream. Therefore, we had to use something other that SSL to tunnel data. - It was fun to come up with a full duplex authentication scheme using RSA. More fun than using someone elses stuff. - Because we could. - We were Free Software developers who did it in our spare time for fun, we were not a company that sells it as one of its products. It seems that you still don't understand those things, or you would not complain about them even at this far removed date. How unfortunate. It seems that you haven't read the rest of my email, or you would not have written that sentence. I am enlightened now :) -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Dutch Transport Card Broken
Perry E. Metzger [EMAIL PROTECTED] writes: SSL involves digital certificates. Not really, James Donald/George W. Bush. It involves public keys, and it provides a channel by which X.509 certificates can be exchanged, Actually it doesn't even require X.509 certs. TLS-SRP and TLS-PSK provide mutual authentication of client and server without any use of X.509. The only problem has been getting vendors to support it, several smaller implementations support it, it's in the (still unreleased) OpenSSL 0.99, and the browser vendors don't seem to be interested at all, which is a pity because the mutual auth (the server has to prove possession of the shared secret before the client can connect) would significantly raise the bar for phishing attacks. (Anyone have any clout with Firefox or MS? Without significant browser support it's hard to get any traction, but the browser vendors are too busy chasing phantoms like EV certs). The particular digital certificate format necessarily imply a PKI structure No, James Donald/George W. Bush, that's not even remotely true. There is no requirement that you use the certs as anything other than key containers. There's actually no requirement that you use certs at all. In fact if everyone dropped them (i.e. stopped pretending that they work and moved towards something that does) we might all be a whole lot better off. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
James A. Donald wrote: I have been considering the problem of encrypted channels over UDP or IP. TLS will not work for this, since it assumes and provides a reliable, and therefore non timely channel, whereas what one wishes to provide is a channel where timeliness may be required at the expense of reliability. This is what Guus was getting at: - We needed to tunnel data over UDP, with UDP semantics. SSL requires a reliable stream. Therefore, we had to use something other that SSL to tunnel data. To put it in more fundamental terms, TLS assumes that what you want is a stream. If you want packets, then TLS is a millstone around your neck. It's not that it can't deliver packets, but that it forces all your application to think in stream-mode, which results in messes up and down the stack (including the human). The vast majority of applications are not pure stream. The vast majority are not pure packet, either ... so they are all somewhere in between. The selection of where your app is on the spectrum and what tools you need is the job of the protocol architect; unfortunately, the prevailing wisdom is that as we only have a widely deployed stream protocol (TLS) then that should be used for everything. This has resulted in some easy wins and some intractable messes as well the current thread (repeated into the past and will be repeated into the future). Advising TLS for a packet delivery requirement is simply wrong. You might be wise to give that advice, if you can show some other factors, but that requires ... more subtlety than simply repeating that TLS has to be used for everything. I have figured out a solution, which I may post here if you are interested. I'm interested. FTR, zooko and I worked on part of the problem, documented briefly here: http://www.webfunds.org/guide/sdp/index.html I've successfully got that going in 3 UDP transport scenarios, with different key exchange scenarios and languages. (I was never able to deploy it tho, for business reasons.) For the most part, the requirements include no relationship between packets, but an expectation of a return path ... a.k.a. connections, but without the streaming assumption ... which means having to relearn how to do context over UDP. One can compare that approach to the DTLS, which has the benefit of leveraging SSL technology and history. My impression was that it assumed too much of the nature of SSL at the core, so it didn't cover enough of the territory to satisfy me. But if it becomes widely deployed, that may be the better bet than designing another one or a home-brew. Deployment counts over elegance, most times. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
On Fri, Feb 01, 2008 at 09:24:10AM -0500, Perry E. Metzger wrote: Does tinc do something that IPsec cannot? I use a VPN system other than IPSec on a regular basis. The reason is simple: it is easy to configure for my application and my OS native IPsec tools are very difficult to configure. There is a lesson in this, I think. I agree wholeheartedly. I'm trying to fix this too. But for web stuff, IPsec won't have a chance for a long time, maybe never. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
Peter Gutmann wrote: Perry E. Metzger [EMAIL PROTECTED] writes: SSL involves digital certificates. Not really, James Donald/George W. Bush. It involves public keys, and it provides a channel by which X.509 certificates can be exchanged, Actually it doesn't even require X.509 certs. TLS-SRP and TLS-PSK provide mutual authentication of client and server without any use of X.509. The only problem has been getting vendors to support it, several smaller implementations support it, it's in the (still unreleased) OpenSSL 0.99, and the browser vendors don't seem to be interested at all, which is a pity because the mutual auth (the server has to prove possession of the shared secret before the client can connect) would significantly raise the bar for phishing attacks. (Anyone have any clout with Firefox or MS? Without significant browser support it's hard to get any traction, but the browser vendors are too busy chasing phantoms like EV certs). That's actually a sad observation. I keep telling my colleagues that this technology is coming any day now to a browser near you - didn't realize that that there was no interest with the browser companies to add support for this... Why do the browser companies not care? What is the adoption issue? Still the dark cloud of patents looming over it? Not enough understanding about the benefits? (marketing) Economic reasons that we wouldn't buy anymore server certs? -Frank. -- Frank Siebenlist [EMAIL PROTECTED] The Globus Alliance - Argonne National Laboratory smime.p7s Description: S/MIME Cryptographic Signature
Re: Gutmann Soundwave Therapy
Ian G [EMAIL PROTECTED] writes: This is what Guus was getting at: - We needed to tunnel data over UDP, with UDP semantics. SSL requires a reliable stream. Therefore, we had to use something other that SSL to tunnel data. The version of SSL (which is officially called TLS) that does this is called DTLS. It has already existed for some time now. To put it in more fundamental terms, TLS assumes that what you want is a stream. If you want packets, then TLS is a millstone around your neck. That's why you use Datagram TLS, aka TLS if your app needs UDP instead of TCP. If you want to learn more about DTLS, this Wikipedia page: http://en.wikipedia.org/wiki/DTLS points at the RFC, which is here: http://tools.ietf.org/html/rfc4347 OpenSSL has had DTLS support for a while, so there is unencumbered code for you to roll into your app for the purpose any time you like. Advising TLS for a packet delivery requirement is simply wrong. DTLS is there for packet delivery. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
Frank Siebenlist wrote: Why do the browser companies not care? I spent a few years trying to interest (at least) one browser vendor with looking at new security problems (phishing) and using the knowledge that we had to solve this (opportunistic cryptography). No luck whatsoever. My view of why it is impractical / impossible to interest the browser vendors in new ideas and new security might be summed as this: * Browser vendors operate a closed security shop. I think this is because of a combination of things. Mostly, all security shops are closed, and there aren't any good examples of open security shops (at least that I can think of). We see some outreach in the last few years (blogs or lists by some) but they are very ... protected, the moat is still there. * Browser vendors are influenced heavily by companies, which have strong agendas. Security programmers at the open browsers are often employed by big companies who want their security in. They are not interested in user security. Security programmers need jobs, they don't do this stuff for fun. So it is not as if you can blame them. * Browser vendors don't employ security people as we know them on this mailgroup, they employ cryptoplumbers. Completely different layer. These people are mostly good (and often very good) at fixing security bugs. We thank them for that! But they are completely at sea when it comes to systemic security failings or designing new systems. * Which also means it is rather difficult to have a conversation with them. For example, programmers don't know what governance is, so they don't know how to deal with PKI (which is governance with some certificate sugar), and they can't readily map a multi-party failure. OTOH, they know what code is, so if you code it up you can have a conversation. But if your conversation needs non-code elements ... glug glug... * Browser vendors work to a limited subset of the old PKI book. Unfortunately, the book itself isn't written, with consequent problems. So certain myths (like all CAs must be the same) have arisen which are out of sync with the original PKI thinking ... and out of sync with reality ... but there is no easy way to deal with this because of the previous points. * Browser vendors may be on the hook for phishing. When you start to talk in terms like that, legal considerations make people go gooey and vague. Nobody in a browser vendor can have that conversation. Which is all to say ... it's not the people! It's the assumptions and history and finance and all other structural issues. That won't change until they are ready to change, and there are only limited things that outsiders can do. Just a personal opinion. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
On Fri, Feb 01, 2008 at 07:58:16PM +, Steven M. Bellovin wrote: On Fri, 01 Feb 2008 13:29:52 +1300 [EMAIL PROTECTED] (Peter Gutmann) wrote: (Anyone have any clout with Firefox or MS? Without significant browser support it's hard to get any traction, but the browser vendors are too busy chasing phantoms like EV certs). The big issue is prompting the user for a password in a way that no one will confuse with a web site doing so. Given all the effort that's been put into making Javascript more and more powerful, and given things like picture-in-picture attacks, I'm not optimistic. It might have been the right thing, once upon a time, but the horse may be too far out of the barn by now to make it worthwhile closing the barn door. And on top of that web site designers don't want browser dialogs for HTTP/TLS authentication. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
questions on RFC2631 and DH key agreement
So AFAICT from perusal of RFC2631 Diffie-Hellman Key Agreement Method and
RFC2630 CMS, when one executes a simple DH static profile between two parties,
the only things that really need to go over the wire are each party's public
keys (ya and yb) if { p, q, g, j } are known to both parties. And thus,
Generation of Keying Material is done by each party separately, using the
value of ZZ that each independently calculates, yes? Thus keying material
doesn't cross the wire and risk exposure (among various things).
So if p, q, g are not static, then a simplistic, nominally valid, DH profile
would be to..
a b
-- --
g, p, ya
--- yb
[calculates ZZ] [calculates ZZ]
[calculates keying material][calculates keying material]
. .
. .
. .
..yes?
Other than for b perhaps wanting to verify the correctness of { p, q, g, j }
(group parameter validation), is there any reason to send q ?
thanks,
=JeffH
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
