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

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

I believe that 1 is the preferable choice given the two. 

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

What's the third?  Anyway, I'd like to see this thrown back on TLS, and any
restrictions imposed there, rather than here. I know you've tried to cover
the export problem by suggesting that an implementation might try 40bit in
a non-US environment; but vendors are stuck between a rock and a hard place
because it is _impossible_ to be compliant to this spec overseas. I
understand your dilemna, but hope you can see ours as well. Can you think
of any other ways to pull the munitions issue out of the compliance
requirements?


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

This paragraph is likewise troubling. Obviously, we'd like to market our
products as offering _some_ level of security, and 40 bit encrypted streams
are significantly harder for an intruder to browse than a plaintext stream,
so it *is* secure from "casual" eavesdropping. It's all a matter of degree.
Rather than MUST NOT indicate this is secure, I'd prefer to see something
that says MUST indicate or MUST make available an indication of the
relative level of security. 

> 6. imaps and pop3s ports
> 
>      Use of the registered "imaps" and "pop3s" ports is hereby strongly
>      discouraged and considered non-standard behavior.

I would leave it as just "discouraged" or leave this section out. 

Incidentally I was asked to draft an "experimental" or "informational" RFC
covering the separate port case as an "interim technology" - but have not
done so precisely to keep it from propogating. I can now see a small
possibility of continuing life as a very specialized service; and there may
yet be a need to define its operation in a standards forum. Let's just not
slam that door yet. You've got my word that any such definition will point
to this specification as the standard and acceptable way to perform
IMAP/TLS; and that we otherwise intend to deprecate the second port. I
believe Microsoft is committed to the same track.


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

It may also be the case that site policy mandates a particular key escrow
technology, and since D-H is the strongest mechanism available (and
mandated to be available) it will always end up to be the default cypher -
regardless that the company requires a _weaker_ cypher.

I'm not going to try and justify this, but I'm throwing out other reasons
why the mandating of specific cyphers may cause conflicts. If that's the
way it's got to be, all right; but it just gives folks more reasons to go
with non-standard solutions; because the "standard" solution was
short-sighted and/or too heavy-handed and/or unworkable. That's what I'm
trying to avoid.

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