Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 06 January 2015 08:11 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A351A9123; Tue, 6 Jan 2015 00:11:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id io-SRS6QhRgB; Tue, 6 Jan 2015 00:11:28 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5701A9119; Tue, 6 Jan 2015 00:10:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0DAAEBEC0; Tue, 6 Jan 2015 08:10:27 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yKCl9dU_pxb; Tue, 6 Jan 2015 08:10:25 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.42.19.48]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A765BEB1; Tue, 6 Jan 2015 08:10:25 +0000 (GMT)
Message-ID: <54AB9870.50505@cs.tcd.ie>
Date: Tue, 06 Jan 2015 08:10:24 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <CALaySJ+j2u3_amk-BSjDgRvoGKFjsqn8k1Lm8pN0dW5dCXck3g@mail.gmail.com> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <CALaySJ+QY12hbrn0SkzwCakcBR3mqSD7XkHAQEspogafVq1_-g@mail.gmail.com>
In-Reply-To: <CALaySJ+QY12hbrn0SkzwCakcBR3mqSD7XkHAQEspogafVq1_-g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/wnKHxgzABazBrMVvNmqBnElDjSo
Cc: Barry Leiba <barry.leiba@huawei.com>, "httpauth-chairs@tools.ietf.org" <httpauth-chairs@tools.ietf.org>, "draft-ietf-httpauth-hoba.all@tools.ietf.org" <draft-ietf-httpauth-hoba.all@tools.ietf.org>, "http-auth@ietf.org" <http-auth@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT)
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jan 2015 08:11:31 -0000

Thanks for updating the ballot. I'll process your comments separately
so this is just on the remaining DISCUSS point.

On 06/01/15 03:36, Barry Leiba wrote:
>>>>> >>>> -- Section 8.2 --
>>>>> >>>>
>>>>> >>>> I don't think you need to say "a la LinkedIn," and I think it's a
>>>>> >>>> bad idea to have us link a company's name to a password
>>>>> >>>> compromise forever in an RFC.  Especially when it's not
>>>>> >>>> necessary.
>>>> >>>
>>>> >>> Is that really DISCUSS worthy? I don't think it is. Which of the
>>>> >>> DISCUSS criteria relate to that. Seems like a stylistic thing to
>>>> >>> me.
>>> >>
>>> >> I think it is: I think it's a very bad thing to disparage specific
>>> >> companies in our RFCs.
>> >
>> > Its a statement of fact though. That is very different.
>> >
>>> >> That said, if you'd actually discuss
>> >
>> > Rhetorical fail alert:-) That last use of "discuss" != DISCUSS-worthy.
>> > You're ignoring a) that this is a style issue and explicitly not
>> > DISCUSS-worthy and b) that I am in fact happy to discus your
>> > non-blocking comments.
>> >
>> > I think it's entirely fair to establish if a point does or does not
>> > warrant being blocking before disposing of the detail. (And hey,
>> > when did an author not want to demote a DISCUSS to a COMMENT if that
>> > is fair-game? Not often.:-)
>> >
>>> >> this with me (why you think it's
>>> >> important to leave it there), then the discussion will have happened,
>>> >> and we can move ahead.

Yet here we still are? :-)

>> >
>> > Facts are much more convincing than abstractions. We could risk a
>> > Streisand effect by not naming one of the major breaches of this
>> > kind. That one was the most topical at the time that text was first
>> > written. A naive reader following up on that will find a plethora
>> > of other examples, of real associated costs and of lessons learned
>> > none of which would be anywhere near as easily found starting (as
>> > a naive reader) from an example.com abstraction (at least afaik
>> > example.com have not had a significant password breach so far,
>> > maybe we ought engineer one:-).
>> >
>> > That enough?
> The fact that there's a plethora of examples really speaks to not
> calling out one company on this, 

I re-iterate: At the time of writing this was the poster-child
example. It still remains one, and a good one for RFC readers.

> as well as that it's not necessary to
> do so.  We could just say "the many password exposures that have been
> well documented in the media," for example.

That may be a reasonable comment, but I continue to maintain that
it is not DISCUSS-worthy. And I think being so shy about this is
a bad plan actually and we ought if anything be more direct about
it.

> (On the DISCUSS criteria, "This cannot be an exhaustive list, but this
> set should be taken as exemplary of the common causes for DISCUSSes
> seen by the IESG in the past."  This is a rare situation, so, of
> course, it's not explicitly listed.  I can only say again that I think
> it's a bad idea to call out specific companies unless there's a strong
> need to.)

"bad idea" does not mean DISCUSS-worthy, and extending the DISCUSS
criteria in that way seems very wrong to me.

The DISCUSS non-criteria also exists though, quoting, I think this falls
squarely under two of those:

"
- Pedantic corrections to non-normative text. Oftentimes, poor phrasing
or misunderstandings in descriptive text are corrected during IESG
review. However, if these corrections are not essential to the
implementation of the specification, these should not be blocking
comments.

- Stylistic issues of any kind. The IESG are welcome to copy-edit as a
non-blocking comment, but this should not obstruct document processing.
"

I think in a case like this it is entirely correct to reference well
publicised security incidents in the most natural fashion via the name
of the organisation that experienced the incident. In this case, I
re-iterate that that incident was I think the most commonly cited one
at the time of writing. (I can buy that adding a citation for more
detail would be a good addition though.)

Cheers,
S.




>