(For what it's worth, I find your style of monocase and ellipses so
incredibly difficult to read that I usually delete your postings unread.)
as previously mentioned, somewhere back behind everything else ... there
is strong financial motivation in the sale of the SSL domain name
digital
as previously mentioned, somewhere back behind everything else ... there
is strong financial motivation in the sale of the SSL domain name digital
certificates.
While I am *not* arguing that point, per se, if having a
better solution would require, or would have required, no
more
On 25/08/10 11:04 PM, Richard Salz wrote:
A really knowledgeable net-head told me the other day that the problem
with SSL/TLS is that it has too many round-trips. In fact, the RTT costs
are now more prohibitive than the crypto costs. I was quite surprised to
hear this; he was stunned to find
On 08/26/2010 06:38 AM, d...@geer.org wrote:
While I am *not* arguing that point, per se, if having a
better solution would require, or would have required, no
more investment than the accumulated profits in the sale
of SSL domain name certs, we could have solved this by now.
the profit from
On Thu, 26 Aug 2010, d...@geer.org wrote:
as previously mentioned, somewhere back behind everything else ... there
is strong financial motivation in the sale of the SSL domain name digital
certificates.
While I am *not* arguing that point, per se, if having a
better solution would require,
Richard Salz writes:
A really knowledgeable net-head told me the other day that the problem
with SSL/TLS is that it has too many round-trips. In fact, the RTT costs
are now more prohibitive than the crypto costs. I was quite surprised to
hear this; he was stunned to find it out.
Also, note that HSTS is presently specific to HTTP. One could imagine
expressing a more generic STS policy for an entire site
A really knowledgeable net-head told me the other day that the problem
with SSL/TLS is that it has too many round-trips. In fact, the RTT costs
are now more
On Aug 25, 2010, at 9:04 20AM, Richard Salz wrote:
Also, note that HSTS is presently specific to HTTP. One could imagine
expressing a more generic STS policy for an entire site
A really knowledgeable net-head told me the other day that the problem
with SSL/TLS is that it has too many
On 08/25/2010 09:04 AM, Richard Salz wrote:
Also, note that HSTS is presently specific to HTTP. One could imagine
expressing a more generic STS policy for an entire site
A really knowledgeable net-head told me the other day that the problem
with SSL/TLS is that it has too many round-trips. In
A really knowledgeable net-head told me the other day that the problem
with SSL/TLS is that it has too many round-trips. In fact, the RTT costs
are now more prohibitive than the crypto costs.
Yes, although that's a different class of issue from the ones we're trying to
address in hasmat and
On Sun, Aug 22, 2010 at 11:51:01AM -0400, Anne Lynn Wheeler wrote:
On 08/22/2010 06:56 AM, Jakob Schlyter wrote:
There are a lot of work going on in this area, including how to use secure
DNS to
associate the key that appears in a TLS server's certificate with the the
intended
domain name
On Aug 16, 2010, at 9:19 49PM, John Gilmore wrote:
who's your enemy? The NSA? The SVR? Or garden-variety cybercrooks?
Enemy? We don't have to be the enemy for someone to crack our
security. We merely have to be in the way of something they want;
or to be a convenient tool or foil in
On 2010-08-15 7:59 AM, Thor Lancelot Simon wrote:
Indeed. The way forward would seem to be ECC, but show me a load balancer
or even a dedicated SSL offload device which supports ECC.
For sufficiently strong security, ECC beats factoring, but how strong is
sufficiently strong? Do you have
On Fri, Aug 13, 2010 at 02:55:32PM -0500, eric.lengve...@wellsfargo.com wrote:
There are some possibilities, my co-workers and I have discussed. For
purely internal systems TLS-PSK (RFC 4279) provides symmetric
encryption through pre-shared keys which provides us with whitelisting
as well as
On Aug 15, 2010, at 1:17 30PM, Peter Gutmann wrote:
Ray Dillinger b...@sonic.net writes:
On Fri, 2010-08-13 at 14:55 -0500, eric.lengve...@wellsfargo.com wrote:
The big drawback is that those who want to follow NIST's recommendations
to migrate to 2048-bit keys will be returning to the
On Fri, 2010-08-13 at 14:55 -0500, eric.lengve...@wellsfargo.com wrote:
Moore's law helped immensely here. In the last 5 years systems have gotten
about 8 times faster, reducing the processing cost of crypto a lot.
The big drawback is that those who want to follow NIST's recommendations
Ray Dillinger b...@sonic.net writes:
On Fri, 2010-08-13 at 14:55 -0500, eric.lengve...@wellsfargo.com wrote:
The big drawback is that those who want to follow NIST's recommendations
to migrate to 2048-bit keys will be returning to the 2005-era overhead.
Either way, that's back in line with the
Anne Lynn Wheeler writes:
subset ... was based on computational load caused by SSL cryptography
in the online merchant scenario, it cut thruput by 90-95%; alternative to
handle the online merchant scenario for total user interaction would have
required increasing the number of servers
On 08/13/2010 03:16 PM, Chris Palmer wrote:
When was this *ever* true? Seriously.
re:
http://www.garlic.com/~lynn/2010m.html#50
... original design/implementation. The very first commerce server
implementation
by the small client/server startup (that had also invented SSL) ... was mall
On Fri, Aug 13, 2010 at 09:32:57AM -0700, Jeff Simmons wrote:
It wouldn't surprise me if there's been some blowback from the
adoption of PCI-DSS (Payment Card Industry Data Security
Standards). As someone who has had to help several small to medium
size businesses comply with these 'voluntary'
Ann Lynn Wheeler wrote:
the original requirement for SSL deployment was that it was on from the
original URL entered by the user. The drop-back to using SSL for only small
subset ... was based on computational load caused by SSL cryptography in
the online merchant scenario, it cut
On Fri, Aug 13, 2010 at 02:55:32PM -0500, eric.lengve...@wellsfargo.com wrote:
The big drawback is that those who want to follow NIST's
recommendations to migrate to 2048-bit keys will be returning to
the 2005-era overhead. Dan Kaminsky provided some benchmarks in a
different thread on this
As part of a thread on another list, I noticed that Bank of America, who until
recently didn't bother protecting the page where users are expected to enter
their credentials with anything more substantial than a GIF of a padlock, now
finally use HTTPS on their home page, and redirect HTTP to HTTPS
On Friday 13 August 2010 04:59, Peter Gutmann wrote:
As part of a thread on another list, I noticed that Bank of America, who
until recently didn't bother protecting the page where users are expected
to enter their credentials with anything more substantial than a GIF of a
padlock, now finally
What on earth happened? Was there a change in banking regulations in
the last few months?
No, but we know that banks move in herds, and they mostly talk to each
other, not anyone with outside expertise.
More likely someone noticed that computers are a lot faster than they
were a decade ago, you
What on earth happened? Was there a change in banking regulations in the last
few months?
Possibly it's related to PCI DSS and other work that BITS has been doing. Also,
if one major player cleans up their act and sings about how cool they are, then
that can cause the ice to break.
Another
Jeff Simmons wrote:
It wouldn't surprise me if there's been some blowback from the adoption of
PCI-DSS (Payment Card Industry Data Security Standards). As someone who
has
had to help several small to medium size businesses comply with these
'voluntary' standards, the irony of the fact that
On 08/13/2010 02:12 PM, Jon Callas wrote:
What on earth happened? Was there a change in banking regulations in the last
few months?
Possibly it's related to PCI DSS and other work that BITS has been doing. Also,
if one major player cleans up their act and sings about how cool they are, then
28 matches
Mail list logo
