Re: draft-newman-tls-imappop-02.txt

On Fri, 30 Jan 1998, Paul Hoffman / IMC wrote:
> ...which I feel are not acceptable. The insertion of heavy-handed politics
> into this draft is inappropriate, given that no one on this list asked
> for them.

I've been trying to distill all the conversation I've heard on the topic
on various IETF lists I follow.  It's quite possible the result was a
dismal failure, so comments are welcome.

> The first paragraph of section 2 is fine; the second and third paragraphs
> should be removed.

What do others think?

> In the second paragraph, you mandate user interface requirements, which I
> think is a first for you, Chris. :-)

It isn't a first.  A number of my documents include UI recommendations or
requirements -- often in the security considerations sections.  I'm always
skeptical of attempts to rule certain classes of issues as out-of-scope
for the IETF.  I happen to think there are cases when it is a good idea to
include UI requirements.  Deliberately misleading a user into believing
that their data is secure when it isn't certainly meets the rules in RFC
2119 by my reading.

If there is rough concensus to remove that comment, I'll go along in this
case, but I disagree with the general idea that UI issues are out of 
scope.  They are often vital to correct interoperability or user access to
the underlying service.

> The first paragraph clearly states the requirements, and that is good enough
> for the protocol. Please remove the junk and put out another draft that we can
> look at before you submit this to the IESG.

I'm willing to tone it down at your request, but I'll sit on it until I
hear more comments.

> Another note. You have the following paragraph buried in the security section:
> 
>      An active attacker can always cause a down-negotiation to the
>      weakest authentication mechanism or cipher suite available.  For
>      this reason, implementations need to be configurable to refuse weak
>      mechanisms or cipher suites.
> 
> There was a desire on this list to put that kind of wording in the normative
> text portion of the SMTP/TLS draft. That would be harder for you, because
> you'd
> have to put it in three times, but you should still consider it. This is the
> one aspect of foo/TLS that was of most interest to people on the TLS mailing
> list, and was probably the most carefully scrutinized during the SMTP/TLS
> discussion.

Ok, I'll move it up front with the cipher suite requirements.

		- Chris