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

On Thu, 28 Aug 1997, Mike Macgirvin wrote:
> > 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?

Third option is to do an Informational RFC rather than standards track.

> Anyway, I'd like to see this thrown back on TLS, and any
> restrictions imposed there, rather than here.

Somebody from Netscape just decided to support this on the TLS list and so
far there haven't been any dissenting statements on the list.  One can
hope...

> Can you think of any other ways to pull the munitions issue out of the
> compliance requirements?

Three possibilities I can see.  One idea I had was to define levels of
compliance -- "U.S. Export weak compliance" and "full compliance".  It
might just get past the IESG, but I'm doubtful as it harms
interoperability in practice.  Next choice would be to stack the IETF
nominations committee for two years in a row with people who would oppose
anyone on the IESG/IAB not willing to compromise on the issue.  That would
require a lot of volunteers and even then might not work--it could also
have a nasty backlash and it's too late to do it this year.  Final choice
would be to fix government export policy.  I prefer option 3 :-)

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

Point taken.  The main issue is that products which don't distinguish
between 40-bit and real encryption should be declared non-compliant.  It's
a really bad thing to do as it results in interoperability problems and 
user confusion.

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

With the caveat that I will strongly oppose standardization of an imaps
URL scheme, I guess I can live with this.  What do others think?

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

A mandatory-to-implement mechanism is not a mandatory-to-use mechanism.
That site will preferentially buy products which can be configured to
require their key escrow mechanism.  Ditto for sites which need faster
ciphers.

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

I sympathize.