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

Stephen Farrell <> Tue, 30 December 2014 22:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7FDF01A8777; Tue, 30 Dec 2014 14:09:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VL4lPbW4ZFRA; Tue, 30 Dec 2014 14:09:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0EB051A8776; Tue, 30 Dec 2014 14:09:06 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02F09BEC4; Tue, 30 Dec 2014 22:09:04 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xCd-9Okupa7i; Tue, 30 Dec 2014 22:09:02 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 89E5ABEC3; Tue, 30 Dec 2014 22:09:02 +0000 (GMT)
Message-ID: <>
Date: Tue, 30 Dec 2014 22:09:02 +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: Barry Leiba <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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 22:09:09 -0000


On 30/12/14 19:48, Barry Leiba wrote:
> On just a couple of points...
>>> 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.
> I think that if we think a change in the formatting would make things
> clearer, we should do that ourselves, and not defer it to the RFC
> Editor.  *We* should be happy with the document before we send it
> over.

I figure this is such a minor change that we are actually happy,
even if we might also like to nitpick ourselves unhappy from time
to time;-)

>>> 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:
> I'm with Stephen here: please leave this alone.  At this point, the
> document is making a request, and that's a fine way to put it.
>>> 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.
> With this and all other strings, the question isn't whether users are
> going to see it or not, but how implementors are supposed to know what
> a "string" is and how to create it.  

In these cases coders look @ the IANA registry to find the string
in question. If IANA, and some expert, manage to muck up that badly
then I suspect we have worse problems. I only agreed with the UTF8
addition in the did case as I could see that being presented to a
user as a "you last logged in from a &^%SS device on Tuesday" so
there's a chance that a non ASCII string might be worthwhile there.
For a kid type (not kid, but a kid type) that's just not worth even
these electrons, even if it appears to bear all the markings of a
good i18n bunfight:-)

Neither string is ever sent in the HOBA protocol itself.


> If it's an arbitrary sequence of
> bytes, then it should say that, rather than "string".  If it's really
> a string and is meant to represent characters in some encoding system,
> then it needs to say either what encoding system that is (UTF-8,
> US-ASCII, or whatever) or that it doesn't matter and that any encoding
> can be used.  The latter only works if the string is never consumed by
> an entity other than the one that created it.
> Barry