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).
DATACRLF
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
(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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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.
22 matches
Mail list logo
