IETF Logo Mail Archive

Re: Further IESG feedback on draft-crispin-imapv-17.txt

ned.freed@mrochek.com Fri, 20 September 2002 18:30 UTC

Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KIU1L28185 for ietf-imapext-bks; Fri, 20 Sep 2002 11:30:01 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KIU0k28179 for <ietf-imapext@imc.org>; Fri, 20 Sep 2002 11:30:00 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KMP5PUHPY800628S@mauve.mrochek.com> for ietf-imapext@imc.org; Fri, 20 Sep 2002 11:29:50 -0700 (PDT)
Date: Fri, 20 Sep 2002 11:29:07 -0700
From: ned.freed@mrochek.com
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
In-reply-to: "Your message dated Fri, 20 Sep 2002 13:22:25 -0400" <3D8B5951.2090104@mit.edu>
To: "Jeffrey I. Schiller" <jis@mit.edu>
Cc: Larry Osterman <larryo@exchange.MICROSOFT.com>, ned.freed@mrochek.com, IMAP Mailing Liste <imap@u.washington.edu>, IMAP Extensions WG <ietf-imapext@imc.org>, paf@cisco.com
Message-id: <01KMQ0D9X8B200628S@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="us-ascii"; format="flowed"
Content-transfer-encoding: 7bit
References: <72C5FDA4D9CC3045B80EA1B76DB86A99ED2CB0@DF-BOWWOW.platinum.corp.microsoft.com> <3D8B5951.2090104@mit.edu>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

> So what is the lesser of two evils.

> 1)It is possible, and in fact done universally, the implement an IETF
>    Standard that sends passwords in the clear, even though we say that we
>    want secure protocols in the IETF and it has been at least three years
>    since we declared that the IETF would not standardize things with
>    plain text passwords...

> 2)We render all existing implementations non-conformant.

> An alternative that we discussed on the call which I don't believe Ned
> described was to reword the paragraph so that it was a MUST NOT unless
> the implementation or its user knew that the underlying transport was
> providing security (aka running IMAP over an SSH tunnel).

That suggestion was incorporated into the alternate wording I proposed.

				Ned

v2.23.0 | Report a Bug | By Email