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

2. Should I explicitly revoke registration of the IMAP+SSL port?
     I'm not inclined to do so as this isn't as serious a design flaw as
     the SMTP+SSL port, and there are already deployed IMAP+SSL
     implementations.

Obviously I'd suggest that this wouldn't be a tremendously productive thing
to do.

I've heard a few arguments for maintaining a second port service even if
STARTTLS is available on 143. These mostly have to do with allowing a
firewall to pass certain outside users through a secure service while
providing insecure connections to 143 internally. Yes, this could be solved
in other ways, but perhaps not as elegantly.

I don't think there's any disagreement that SMTP+TLS should be a single
port solution, and that the SMTP/TLS port should be revoked or otherwise
forcefully deprecated; although I think the IANA is limited to marking it
"historical").


     1. The cipher suite requirement is included to meet the decisions
     made at the Munich and Danvers IETF meetings.  The additional text
     about exportable ciphers is my invention to hopefully improve
     interoperability.  Comments are welcome.

---
      Support for the TLS mechanism TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is
      REQUIRED by all IMAP software implementing this extension.
      Implementations MUST NOT assume any other cipher suite is present.
      Unfortunately, it is possible that due to certain government
      export restrictions some non-compliant versions of this extension
      could be deployed.  Implementations wishing to interoperate with
      such non-compliant versions MAY offer the
      TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA mechanism.  However, since
      40 bit ciphers are known to be vulnerable to attack by current
      technology, any client which actives a 40 bit cipher MUST NOT
      indicate to the user that the connection is secure from
      evesdropping.

I would argue against mandating !any! ciphers. I see this as completely a
site policy or even a product issue. It is possible that I might consider
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to be too weak for my needs; or that it
presents a problem in certain countries in which I wish to sell products,
such as France. How do we reconcile this? 

I laud the goal of ensuring that there is a common cipher in all
implementations, but think that a response to the STARTTLS command to the
effect of

	A001 NO [AUTH-TOO-WEAK] Cannot negotiate a mutually acceptable cipher

would be a better choice - although the TLS negotiation would have
determined this already; so the message might be redundant and NO is all
that's required. 


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.

begin:          vcard
fn:             Mike Macgirvin
n:              Macgirvin;Mike
org:            Netscape Communications Corporation
adr:            Mail Stop MV029;;501 E. Middlefield Road;Mountain View;California;94043;USA
email;internet: [email protected]
title:          Postmaster General
tel;work:       (650) 937-3798
tel;home:       (650) 964-7340
note:           <A HREF="http://people.netscape.com/max/"><B>http://people.netscape.com/max/</B></A>
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard