Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 30 December 2014 18:19 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580B61A1A15; Tue, 30 Dec 2014 10:19:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no
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 Irb6vU5fLO9U; Tue, 30 Dec 2014 10:19:27 -0800 (PST)
Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352811A0371; Tue, 30 Dec 2014 10:19:27 -0800 (PST)
Received: by mail-qa0-f49.google.com with SMTP id dc16so10424485qab.36; Tue, 30 Dec 2014 10:19:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pg0VmZ0oNG20wCqR+/dSlfRLMoUg0YtTp3yjK9EXbKY=; b=U8Ei1vS+2m2T5ok02I3ZpL65HszKO2nkXibeA0+bPO323fAbYN1EF8waOcszgUCWcq UP21TK3PqYkWWVAr39wZcJrQREvlt++R9OCinTGGLeKr38LUxceTK+qGWWN0xuQ23cQL aTTge+gUEYQqpNnpjUYhGOIM7Ffb/do947KtuEuMgXVH8emy7cFPWkOYiZGkvJtHqb4N E0Ge/DPQqCv866wE49fzvzcOy/vI1Iu1NEMl/ChtZ/hrPx0IrA4glBB9tbRzUqPgBMzG RfueNGz1+aD4wFGE3v09iPz/jSdUTgXukGixAVtr8QS/SkLdAULlNvgRRItqCYHHNlqv mOkg==
X-Received: by 10.224.25.139 with SMTP id z11mr68139699qab.17.1419963566007; Tue, 30 Dec 2014 10:19:26 -0800 (PST)
Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id j21sm1005683qgd.36.2014.12.30.10.19.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Dec 2014 10:19:24 -0800 (PST)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Google-Original-From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (11D257)
In-Reply-To: <54A2E649.9060705@cs.tcd.ie>
Date: Tue, 30 Dec 2014 13:19:24 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <95B2FD3B-4776-4DCA-8D26-F80C8C8C4A51@gmail.com>
References: <CAF4+nEH3qmXQRg1B2F+uD4iwO8KQijzUTsJKb=u9TR5tEaAjSQ@mail.gmail.com> <54A2E649.9060705@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ipVKKQsIRMogdaiv9alp0VpDW4U
Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" <draft-ietf-httpauth-hoba.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Dec 2014 18:19:31 -0000

Thanks for the review, Donald and the quick response, Stephen.  Too posting, sorry.

Yes, please do go ahead and post the -09 version to correct the mostly editorial changes in case it helps any of the IESG reviews.  I'll add the ballot after that.

Thanks,
Kathleen

Sent from my iPhone

> On Dec 30, 2014, at 12:52 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> 
> Hi Donald,
> 
> Thanks for the review.
> 
>> On 28/12/14 20:50, Donald Eastlake wrote:
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  Document editors and WG chairs should treat these comments just
>> like any other last call comments.
>> 
>> This draft specifies an Experimental protocol to use digital
>> signatures in response to challenges for authentication to HTTP
>> servers as a replacement for passwords. There are a lot more details
>> than that and considerable effort has been put into making this fit
>> into existing web authentication so as to be easily deployable.
>> Overall, it looks like a good job. See comments below.
>> 
>> As a heavily security oriented draft, I recommend it be looked at by
>> the non-author Security AD :-)
> 
> Reasonable plan:-) I'm sure Kathleen has it in hand.
> 
>> 
>> 
>>> Security Comments <
>> ---------------------
>> 
>> This draft is fairly clear about what happens when mandatory 2119
>> requirements are violated in strictly security contexts, such as a
>> signature not validating. But is generally doesn't say much about
>> what happens when mandatory formatting requirements are violated. I
>> guess if things don't parse, then authentication will fail. But, for
>> example, it says "The "realm" attribute MUST NOT appear more than
>> once." Whenever I see something like that, I say to myself, OK, so
>> what happens if the "MUST NOT" is violated? If the spec says nothing,
>> then I would expect that with some implementations authentication
>> would fail while others would use the first realm attribute and still
>> others would use the last realm attribute. Could that be a problem?
> 
> Well, we could add a generic sentence saying "if formatting is bad in
> any way then servers MUST fail authentication" but I think that'd
> just be repetition really.
> 
>> 
>> This draft uses "random" and "randomness" in various places without
>> any reference/definition.
> 
> True. I'd argue that that's ok, but I suppose a reference to rfc4086
> might be useful. If pressed, I'd not object to adding one.
> 
>> 
>> Security Considerations:
>> 
>> Perhaps there should be a reference in the Security Considerations
>> section to Section 1.1.
> 
> I think that'd just be repetitive though, the point is made in 1.1.
> 
>> 
>> Can some level of confusion/denial be caused by setting max-age to a
>> lower value than the server intended?
> 
> I don't believe so.
> 
>> 
>> Appendix B: It is good that an example is provided it seems like some
>> things are missing. Shouldn't it specify the "alg" string and wouldn't
>> it be useful if it gave the TBS blob explicitly?
> 
> Yep - you're right that we ought say its rsa-sha256, though to be fair
> the consumer of the example only has two values from which to guess;-)
> But if there's any change made (almost inevitable:-) then I'll make
> sure to include that in a -09.
>> 
>>> Wording/Format Comments <
>> ---------------------------
>> 
>> Abstract: I always worry about words like "all" (or, being recursive
>> to this sentence, "always" :-). I suggest deleting the one occurrence
>> of "all" in the Abstract.
>> 
>> Page 5, Section 1.2
>> OLD
>>   That will contain of at least one CPK and a web-origin;
>>                  ^^
>> NEW
>>   That will contain at least one CPK and a web-origin;
> 
> Ah crap - so I defo do need a -09, ah well, I'll make the chages
> above as well so:-)
> 
>> 
>> Page 6/7/13, Figure 1/2/3: I'm not sure that something that is
>> entirely textural is best called a "Figure". But in any case, since
>> the text is, or at least has, lines that are flush left, it looks like
>> part of the preceding text and there isn't a clear demarcation of the
>> start. I recommend that the body of the Figures be indented 3 or 4
>> spaces.
> 
> I'd prefer let the RFC editor fix those if needed.
> 
>> 
>> Page 6, Section 2:
>> - For "alg" inconsistently says it is "an ASCII character" and "ASCII
>> numbers" where perhaps it should say "an ASCII encoded one or two digit
>> non-negative integer" or something.
> 
> Tweaked to remove a bit of repetition.
> 
>> - For "origin" perhaps the example should note that it would be
>> prefixed by "28:" in the TBS blob.
> 
> That's the len all right, but that's just a per the abnf. I don't
> think saying so would make it easier to code.
> 
>> - Delete one of the two sequential occurrences of "reduce the amount
>> of".
> 
> Did that.
> 
>> 
>> Page 10, Section 5:
>> I suggest rewording this sentence:
>> OLD
>>   This section also
>>   covers the actions that give HOBA similar user features as today's
>>   passwords have.
>> NEW
>>   This section also
>>   covers the actions that give HOBA user features similar to today's
>>   passwords.
> 
> Almost
> 
>> 
>> Page 16, Section 6.4: duplicated word "response".
> 
> Sigh, why do I keep doing that:-)
> 
>> 
>> Page 18, Section 8.2: Is it a good idea to mention a particular
>> on-line service name here?
> 
> I think its fair.
> 
>> 
>> Page 19, IANA Considerations: It seems from
>> draft-leiba-coton-iana-5226bis that IANA would prefer IANA
>> Considerations to be written in the past tense as if the actions had
>> already been accomplished, presumably to minimize IANA re-writing
>> effort. Thus, I suggest that consideration be given to changing the
>> initial part, between the Section 9 heading and the Section 9.1
>> heading, to the following and making similar changes in the remainder
>> of the IANA Considerations Section:
>> 
>>   IANA has created the registries and made the registration specified
>>   below, placing the new registries in a new "HTTP Origin-Bound
>>   Authentication (HOBA) Parameters" category.
> 
> I'd rather not go there. I've also seen the opposite request
> made so would prefer to not be involved in such bureaucratic
> battles:-)
> 
>> 
>> Page 20, Section 9.3: A better way to note the restriction on
>> potential values of Algorithm Name would be to add a third entry to
>> the registry something like the following (there should also be a
>> third Reference column):
>> 
>> 2-99        Unassigned        [this document]
> 
> I'm not convinced that's better tbh and as-is its fine so no
> change there.
> 
>> 
>> Page 20, Section 9.4: Suggest the "Meaning" for 2 be "an unformatted
>> UTF8 string". There should probably be a Reference column. "a small
>> positive integer" is undefined.
> 
> Oh come on. Small positive integer utterly clear as is unformatted
> string in this context. UTF8 isn't needed here as this is not meant
> to be seen by a user.
> 
>> 
>> Page 20, Section 9.5: Seems like this should say "UTF8 string" and I'm
>> not sure it needs "at the user's/UA's whim". There should also be a
>> "[this document]" entry in a Reference column.
> 
> I added UTF8 since this could be presented to a user. (Good catch
> that.) I didn't make the other changes.
> 
>> 
>> Maybe there should be ABNF for "kid" and "did" somewhere. Since "kid"
>> and "did" are ordinary English words, suggest globally replacing them
>> with "KID" and "DID" respectively.
> 
> No thanks - it's clear enough and upper case wouldn't make it better
> I think.
> 
>> 
>> Page 24, Appendix A
>> This is a nice appendix but there is no reference to it anywhere in the
>> body of the draft. Suggest adding such a reference to the
>> Introduction.
> 
> I think we had it earlier and were asked to take it out. And
> I think that's fine as-is.
> 
> Thanks for the good catches.
> 
> I've a working copy of a -09 at [1], with the diff vs. -08
> at [2]. I'll wait for Kathleen to say if she wants that posted
> now or not, as almost all the changes are nit-fixes.
> 
> Cheers,
> S.
> 
> [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-09.txt
> [2]
> https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-08.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-09.txt
> 
>> 
>> Thanks,
>> Donald
>> =============================
>> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>> 155 Beaver Street, Milford, MA 01757 USA
>> d3e3e3@gmail.com
>