Subject: Re: [http-auth] [IANA #798267] Last Call: <draft-ietf-httpauth-hoba-07.txt> (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Dec 2014 11:14:57 +0000

Hi Amanda,

Thanks for the review - responses inline and a proto-08
version (handling the various IETF LC comments) is at [1]
with a diff vs. 07 at [2]. I'll plan to publish that as an
official -08 in a few days if there are no comments.

On 22/12/14 22:25, Amanda Baber via RT wrote:
> (BEGIN IANA LAST CALL COMMENTS)
> 
> IESG/Authors/WG Chairs:
> 
> IANA has reviewed draft-ietf-httpauth-hoba.  Authors should review
> the comments and/or questions below.  Please report any inaccuracies
> and respond to any questions as soon as possible.
> 
> IANA's reviewer has the following comments/questions:
> 
> IANA has a question about one of the actions requested in the IANA
> considerations section of this document.
> 
> IANA understands that, upon approval of this document, there are six
> actions which need to be completed.
> 
> First, in the HTTP Authentication Schemes registry under the
> Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry
> heading at
> 
> https://www.iana.org/assignments/http-authschemes/
> 
> a new authentication scheme will be registered as follows:
> 
> Authentication Schemem Name: HOBA Reference: Section 3 of [ RFC-to-be
> ] Notes: [ none ]
> 
> Second, in the Well-Known URI registry located at:
> 
> https://www.iana.org/assignments/well-known-uris/
> 
> a new well-known URI will be registered as follows:
> 
> URI Suffix: hoba Change Controller: IETF Reference: Section 6 of [
> RFC-to-be ] Related Information: [ none ]
> 
> IANA Note -> As this document requests registrations in an Expert
> Review or Specification Required (see RFC 5226) registry, we will
> initiate the required Expert Review via a separate request. Expert
> review will need to be completed before your document can be approved
> for publication as an RFC.

Hmm, that's odd. I disagree with "will need to be completed" - this
is an IETF stream consensus document and the IETF LC trumps expert
review. I'll happily take comments of course when those are received
in time.

> 
> Third, a new registry is to be created called the HOBA Signature
> Algorithms registry.
> 
> IANA understands that the registry will consist of a number, meaning
> and reference.
> 
> IANA Question -> per RFC 5226, what is the registration procedure for
> this registry?

-07 says "specification required" what's not clear there?

> 
> IANA Question -> Where should this new registry be located? Does it
> belong at an existing URL, under an existing heading at
> http://www.iana.org/protocols? If not, please supply a title for the
> new category (for example, "HTTP Origin-Bound Authentication (HOBA)
> Parameters").

Sure a new category is fine. Added that text.

> 
> IANA Question -> Does this registry have a maximum value?

Yes, 99. Added text.

> 
> These are the initial registrations:
> 
> Number: 0 Meaning: RSA-SHA256 Reference: [ RFC-to-be ]
> 
> Number: 1 Meaning: RSA-SHA1 Reference: [ RFC-to-be ]
> 
> Fourth, a new registry is to be created called the HOBA Key
> Identifier Types registry.
> 
> IANA understands that the registry will consist of a number, meaning
> and reference.
> 
> IANA Question -> per RFC 5226, what is the registration procedure for
> this registry?

Specification required as stated in -07.

> 
> IANA Question -> Where should this new registry be located?

As per above.

> 
> IANA Question -> Does this registry have a maximum value?

No.

> 
> These are the initial registrations:
> 
> Number: 0 Meaning: a hashed public key [ RFC6698 ] Reference: [
> RFC-to-be ]
> 
> Number: 1 Meaning: a URI [ RFC3986 ] Reference: [ RFC-to-be ]
> 
> Number: 2 Meaning: an unformatted string, at the user's/UA's whim 
> Reference: [ RFC-to-be ]
> 
> Fifth, a new registry is to be created called the HOB Device
> Identifier Types registry.
> 
> IANA understands that the registry will consist of a number, meaning
> and reference.
> 
> IANA Question -> per RFC 5226, what is the registration procedure for
> this registry?

Specification required as stated in -07.

> 
> IANA Question -> Where should this new registry be located?

See above.

> 
> IANA Question -> Does this registry have a maximum value?

No.

> 
> These are the initial registrations:
> 
> Number: 0 Meaning: an unformatted string, at the user's/UA's whim 
> Reference: [ RFC-to-be ]
> 
> Sixth, in the Permanent Message Header Field Names subregistry of the
> Message Headers registry located at:
> 
> https://www.iana.org/assignments/message-headers/
> 
> a new message header field name will be registered as follows:
> 
> Header Field Name: Hobareg Template: Protocol: HTTP Status: 
> Reference: [ RFC-to-be ]
> 
> IANA Note -> As this document requests registrations in an Expert
> Review or Specification Required (see RFC 5226) registry, we will
> initiate the required Expert Review via a separate request. Expert
> review will need to be completed before your document can be approved
> for publication as an RFC.

See above. I disagree with your interpretation of the expert's
role here (still:-)

Thanks,
S.

> 
> Note:  The actions requested in this document will not be completed
> until the document has been approved for publication as an RFC. This
> message is only to confirm what actions will be performed.
> 
> Thanks,
> 
> Amanda Baber IANA Request Specialist ICANN
> 
> (END IANA LAST CALL COMMENTS)
> 
> 
> On Wed Dec 10 14:23:12 2014, [email-masked] wrote:
>> 
>> The IESG has received a request from the Hypertext Transfer
>> Protocol Authentication WG (httpauth) to consider the following
>> document: - 'HTTP Origin-Bound Authentication (HOBA)' 
>> <draft-ietf-httpauth-hoba-07.txt> as Experimental RFC
>> 
>> The IESG plans to make a decision in the next few weeks, and
>> solicits final comments on this action. Please send substantive
>> comments to the [email-masked] mailing lists by 2014-12-24.
>> Exceptionally, comments may be sent to [email-masked] instead. In
>> either case, please retain the beginning of the Subject line to
>> allow automated sorting.
>> 
>> Abstract
>> 
>> 
>> HTTP Origin-Bound Authentication (HOBA) is a digital signature
>> based design for an HTTP authentication method.  The design can
>> also be used in Javascript-based authentication embedded in HTML.
>> HOBA is an alternative to HTTP authentication schemes that require
>> passwords and therefore avoids all problems related to passwords,
>> such as leakage of server-side password databases.
>> 
>> 
>> 
>> 
>> The file can be obtained via 
>> http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/
>> 
>> IESG discussion can be tracked via 
>> http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ballot/
>> 
>> 
>> No IPR declarations have been submitted directly on this I-D.
>> 
>> 
> 
> 
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 24 Dec 2014 11:30:05 +0000

Hi Stephen,

> On 22/12/14 22:25, Amanda Baber via RT wrote:
  [...]
> review. I'll happily take comments of course when those are received
Specification Required requires expert review. So the expert review is 
required anyway. IETF consensus can't override this, if this is how the 
registry is setup.
(If the registry was setup as "IETF Consensus or Specification 
Required", that would have been a different story.)

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Dec 2014 11:36:51 +0000

Hiya,

> Required", that would have been a different story.)

I recall the IESG discussing this before and thought we'd ended
up with a different conclusion - since IETF LC can change any of
the registry set ups, it basically wins was what I though we
concluded. Seems odd to say that an IETF LC can change the
registration rule without expert input but cannot add an entry.

But whatever, I'm sure it's no big deal in this case and it's
a minor process wrinkle anyway. Be good if we clarify though.
(And it's quite possible this is just me mis-remembering.)

S.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Dec 2014 08:12:03 -0500

> registration rule without expert input but cannot add an entry.

Most IETF consensus calls are silently ignored.   A document that changes a registry is likely to get more notice, at least if someone is paying attention.   So all IETF last calls are not equal, in practice if not in principle.   I wish it were not so.

The expert review serves as a backstop: e.g., RFC 3315 requires expert review because we occasionally get some working group that accidentally changes the DHCP protocol in the process of adding a DHCP option (probably happens with RADIUS and other similar protocols as well).   At least one document with a problem like this got to AUTH48 before anyone who had DHCP fu noticed.   Expert review is way late for catching mistakes like this, but it's better than AUTH48 or post-publication (we have one of those too).

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 24 Dec 2014 13:41:40 +0000

> registration rule without expert input but cannot add an entry.
RFC 5226 is being updated and if this is true, then it is not clear on 
that, I think.

I think IESG can override any registry policies, but I don't think that 
is the procedure that you are trying to invoke.

Anyway, I've done with my IANA registry nitpicking job ;-).
> a minor process wrinkle anyway. Be good if we clarify though.
Agreed.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 24 Dec 2014 11:16:17 -0500

> up with a different conclusion

We did not.  Some registries (ports, media types) are set up so that
IETF consensus documents do not need expert review.  But if the
registry is not set up that way, the expert does get involved.  The
IESG can always explicitly override that, but IETF consensus does not.

If someone should want to submit a document to change the registration
policy to exempt registrations made from IETF consensus documents from
expert review, someone certainly could do that.

Barry

---

From: [email-masked]
Date: Wed, 24 Dec 2014 17:04:39 +0000

> expert review, someone certainly could do that.

Wouldn't that be part of 5226bis if it were what we wanted?

As to the (minor) substance here I'd suggest that experts be consulted but non blocking for ietf consensus docs I think. Adding unexpected twists like this at the end of the process is bad in general (though not a problem in this case) 

S

---

From: Barry Leiba <[email-masked]>
Date: Wed, 24 Dec 2014 12:49:43 -0500

> Wouldn't that be part of 5226bis if it were what we wanted?

Perhaps, but it's clearly not what we want, in general (see below).
And 5226bis does suggest using combinations of policies to handle
this, combinations such as "IETF Review or Expert Review" (see Section
2.3.2).

> As to the (minor) substance here I'd suggest that experts be consulted
> but non blocking for ietf consensus docs I think. Adding unexpected
> twists like this at the end of the process is bad in general

This is not an unexpected twist: anyone looking at the registration
policy can clearly see that it requires expert review, and nothing
indicates an exception for IETF consensus documents.  Further, as to
your first sentence (and my "see below" above), I have pushed back, in
IESG Evaluation, on expert review policies, asking if they wanted to
make an exception for IETF consensus documents.  In every case where I
pushed back, they did *not*.  They always wanted to get the designated
experts involved to make sure things looked right.

This actually makes sense, because in many cases it's possible -- even
likely -- that registrations will be requested by authors, working
groups, or other sub-communities who are not experts in the ins and
outs of the particular registry involved, and the creators of the
registry want to make sure that someone who *is* gives the
registration request at least a once-over.

Barry

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 24 Dec 2014 14:29:06 -0500

Thanks for the discussion on this.  We'll make sure the expert review happens before I add a ballot and I'll move this out further if needed.  The draft is on the agenda for 1/8 right now.

Best regards,
Kathleen 

Sent from my iPhone

---

From: Barry Leiba <[email-masked]>
Date: Wed, 24 Dec 2014 15:03:15 -0500

I wouldn't wait on the ballot.  The substance of the document probably
won't change significantly.

Barry

On Wednesday, December 24, 2014, Kathleen Moriarty <
[email-masked]> wrote:

> Thanks for the discussion on this.  We'll make sure the expert review
> happens before I add a ballot and I'll move this out further if needed.
> The draft is on the agenda for 1/8 right now.
>
> Best regards,
> Kathleen
>
> Sent from my iPhone
>
> On Dec 24, 2014, at 12:49 PM, Barry Leiba <[email-masked]
> <javascript:;>> wrote:
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 24 Dec 2014 15:06:31 -0500

Sent from my iPhone

> On Dec 24, 2014, at 3:03 PM, Barry Leiba <[email-masked]> wrote:
> 
> I wouldn't wait on the ballot.  The substance of the document probably won't change significantly.

Ok, thanks.  I'll just wait for the next revision as Stephen has changes he was confirming with reviewers.  The ballot is ready to go, so it'll get posted once the draft is there,

Thanks & merry Christmas, happy Chanukah, and happy Festivus for everyone else :-)

Kathleen 

> 
> Barry
> 
>> On Wednesday, December 24, 2014, Kathleen Moriarty <[email-masked]> wrote: