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
TLS negotiation.

> 	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: <[email protected]> TLS=TLS1.0,SSL3.0,ABORT NOTIFY=FAILURE \
> ORCPT=rfc822;[email protected]
> 
> 	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: <[email protected]> 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.)