Re: Welcome to the ietf-apps-tls mailing list

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

	True, but less of a concern than a server which may or may not do TLS
and we knew it once did - saying it doesn't do it anymore. If we're talking to
a TLS (port) service, we will either agree that we're talking to who we think
we are, or we say bye-bye (and not fall back on a non-TLS service on the normal
port). In any event, a separate port isn't on the table. Paul H has given some
very good reasons in past discussions why this should be avoided at all costs.

> Every client and server needs to be configured with a minimum security
> level, regardless of the protocols or negotiation mechanisms used.

Certainly. 

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

Hmmm. Then you recommend that once we've gone through the trouble of
establishing a trust channel with the first MTA in the chain, that we then just
throw our message to the wolves once it's left that system. I'm typically not
too worried about the wire going from me to the nearest server. In most places
I've worked, I could physically inspect it if I wanted. I'm REAL worried about
the other 100 wires between that server and my message destination.

Object security has a high cost in perceived delay time to the end user during
message retrieval. Certainly it's more secure and easier to maintain than a set
of trust/verify relationships, but it bites hard on dialups if your mailbox is
suddenly 90% base64. It also does not address security tunneling via the
message envelope and header; which often betray the contents.

I believe each approach has its place; and will appeal to different customers.
...Some might even want both. 

> 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.)

I suppose this means that my midnight ramblings weren't polished enough for an
RFC or draft submission... sigh... and I tried so hard.... 

;=)