On Thu, Jan 19, 2006 at 12:54:34AM +0800, Bill Hacker wrote:
> Kjetil Torgrim Homme wrote:
[>> Bill]
[>>> Kjetil]
> All STARTTLS brought to the party was the ability for a 'stranger' to
> seek one standard port, then adapt to what was offered by 'negotiation'.
>
> That has immense value on port 25, and 'public facing' MTA's less so on
> other ports or private/internal MTAs.
STARTTLS is almost, but not quite entirely, useless on port 25.
>> fair enough, but this is at odds with Internet standards
> Depends on which rev/age of which Request For Comment you choose.
How much do you know about the IETF Standards Track? This comment would
appear to suggest that it's not a lot. (Note here the difference between:
STANDARD, PROPOSED STANDARD, RFC, Internet-Draft).
> Everything is in compliance with some, at odds with others - current or
> otherwise.
> 'Internet Standard' is a goal - and a desireable one generally - but not
> a reality.
These comments are meaningless.
>>>> it is NOT required to use STARTTLS, many prefer to use
>>>> CRAM-MD5 or similar schemes which aren't vulnerable to sniffing.
>>> How, pray tell, is the know-long-ago-compromised MD5 less 'vulnerable'
>>> than the current higher-level releases of SSL/TLS?
>> I didn't make such a claim. (and CRAM-MD5 is not compromised by MD5
>> collision attacks, anyway.)
> Be that as it may, (not betting either way...) plaintext inside of a
> pre-existing SSL tunnel is *way* easier to use, and no less secure, *so
> long as* you do not permit 'fallback' to unencrypted.
Well, well, an interesting idea of an argument, so I'll jump in. Out of
interest, the certificate you present as a server cert? It might either
be (a) self-signed or (b) signed by a certificate authority. If the latter
I'd be very surprised if the signature algorithm wasn't RSA-MD5 (and
collision certificates *have* been generated). If (a) then how does SSL/TLS
actually protect you (think man-in-the-middle here)?
> Forcing SSL/TLS-on-connect by port 'up front' in the configure guards
> against that possibilty, whereas an obscure coding error in your
> authenticators might permit fallback to plantext with 'negotiated' TLS.
Well, this is all very well, but let's suppose, for a second, that I have
a work laptop using your service to send mail from my work address, and
some random system to send mail from a home address or vanity domain. I
have to authenticate to both. Why make yours different (yes, sure you can)
from this, just so actually it's more pain for me in the end? This sort of
thing is not actually a win for your customers, and it's probably not a win
for you, in terms of your support calls, but hey, you can just carry on
living in your own planet, because it does only affect your customers
(unlike, say, running an open relay).
Cheers
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
(Please use this address to reply)
