[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Welcome to the ietf-apps-tls mailing list
On Wed, 7 May 1997, Mike Macgirvin wrote:
> This is one of the conditions that gave us problems for TLS/IMAP. There
> doesn't seen to be any way out of this without prior client knowledge - or a
> separate port (which isn't an option for TLS/SMTP).
A separate port doesn't solve the problem as one can always muck with the
> It would seem that the submission agent needs to be configured for
> minimum security level. That's not a difficult problem. In the case of relays,
> it does get a bit more complicated.
Every client and server needs to be configured with a minimum security
level, regardless of the protocols or negotiation mechanisms used.
> This appears to be ripe for a RCPT To: extension which can get passed
> along and provides an indication of what security level should be achieved, and
> how to react if it can't. We've come from a world where SMTP does everything in
> its power to get the message to the destination, but this is one place where it
> would be entirely reasonable for the sender to indicate that an abort was the
> only appropriate action if a secure channel could not be negotiated. This could
> be linked with DSN's for reporting.
> RCPT TO: <max@xxxxxxxxxxxx> TLS=TLS1.0,SSL3.0,ABORT NOTIFY=FAILURE \
> indicates we try tls1.0, then sslv3 and drop the message (with a return
> DSN) if this cannot be achieved. Without the NOTIFY parameter, we just RTS.
> RCPT TO: <max@xxxxxxxxxxxx> TLS=TLS1.0,SSL3.0
> indicates we try tls1.0, then sslv3 but allow the delivery to continue
> in any event with no reports.
This proposal would lead the the appearance of having end-to-end security,
without actually having it. For that reason, I think it's a bad idea. We
should all be using standards-track message object security such as
defined in RFC 2015 for real end-to-end security.
Besides, this proposal also fails to mention things like what key length
is acceptable and which encryption algorithms are acceptable (I'd
probably request that key-escrow, key-recovery, and trade-secret
algorithms not be used since their security characteristics are unknown.)