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

[Kathleen Moriarty <[e-mail]>]

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 <[e-mail]> 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   [phone] (cell)
>> 155 Beaver Street, Milford, MA 01757 USA
>> [e-mail]
>