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

Stephen Farrell <> Tue, 30 December 2014 17:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1EEE71A03A2; Tue, 30 Dec 2014 09:52:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kZpCk93G4XDQ; Tue, 30 Dec 2014 09:52:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCE571A039B; Tue, 30 Dec 2014 09:52:14 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C092BEC6; Tue, 30 Dec 2014 17:52:13 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Idy-Syw0W_bO; Tue, 30 Dec 2014 17:52:11 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 7389DBEC4; Tue, 30 Dec 2014 17:52:10 +0000 (GMT)
Message-ID: <>
Date: Tue, 30 Dec 2014 17:52:09 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Donald Eastlake <>, "" <>,
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: "" <>
Subject: Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Dec 2014 17:52:18 -0000

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
>    That will contain of at least one CPK and a web-origin;
>                   ^^
>    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:
>    This section also
>    covers the actions that give HOBA similar user features as today's
>    passwords have.
>    This section also
>    covers the actions that give HOBA user features similar to today's
>    passwords.


> 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

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



> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA