Re: Any drafts for IMAP4/TLS and/or POP3/TLS

On Wed, 27 Aug 1997, Mike Macgirvin wrote:
> I've heard a few arguments for maintaining a second port service even if
> STARTTLS is available on 143.

If you think what's in section 6 is too strong, please suggest alternate
wording which we can discuss.

> I would argue against mandating !any! ciphers.

We have two choices:
1) Standards track with mandatory-to-implement strong Diffie-Hellman based
   cipher suite.
2) Not standards track.

I prefer (1).  The "strong" part was decided in the IETF plenary in
Danvers and the "Diffie-Hellman" part was decided in the IETF plenary in
Munich.  The "mandatory" part comes from the IESG refusing to standardize 
protocols which don't interoperate.

> I see this as completely a site policy or even a product issue.

It's the "Internet" Engineering Task Force, not the "Intranet" Engineering
Task Force or "Single-Vendor-Solution" Task Force.  If it's possible to
build a compliant client which can't interoperate with a compliant server,
then the standard is broken.

I'll also mention that the TLS spec got remanded from the IESG back to the
WG because it failed to have a mandatory cipher suite.  The TLS WG has 
three options to meet the interoperability requirement -- either mandate
3DES Diffie-Hellman, in which case I'm willing to remove the paragraph
from this spec, or mandate that any use of TLS with a standards track
protocol MUST have a profile including a mandatory-to-implement cipher
suite.

> It is possible that I might consider
> TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to be too weak for my needs;

There isn't a stronger mechanism defined, so I suspect you're making a
strawman argument.

> or that it
> presents a problem in certain countries in which I wish to sell products,
> such as France. How do we reconcile this? 

This issue was decided at the Danvers IETF plenary.  The quality of
standards isn't to be compromised by governmental whims.  If a country
prevents you from selling compliant software somewhere, then you need to
make a special non-complaint version for that country.

I'll ask you directly, given a choice between (1) or (2) above, which do
you prefer?

> Q:	Should we indicate presence of IMAP TLS with a CAPABILITY? I could see
> the answer to this go either way. It would prevent clients from issuing
> STARTTLS on a server where it isn't implemented. One round trip, big deal -
> but it's an extra round trip. For POP we have no choice. The con side is
> that advertising a security capability isn't generally perceived as a good
> thing.

I don't see any practical security difference between announcing and
probing.  Either way, it's possible to discover if TLS is implemented
prior to authenticating.  I'm inclined to keep the text about announcing
the "STARTTLS" capability as is, unless a security expert can explain a
real advantage of probing over announcing.

		- Chris