Subject: [http-auth] Terry Manderson's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT)

From: "Terry Manderson" <[email-masked]>
Date: Tue, 01 Nov 2016 16:57:33 -0700

Terry Manderson has entered the following ballot position for
draft-ietf-httpauth-mutual-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for writing a very detailed document. 

A few minor comments.

1) Please review the introduction, there are several grammatical errors
in there. Meaning still came through just fine, but they were a little
distracting.

2) The state machine diagram of the client is quite complex. A candidate
for the new RFC format?

3) I agree with Alvaro's comment on the IPR. Thank you for making it
royalty free, however not sure you need to add the text in the RFC.

4) This to me seems as it is essentially a shared secret construct, one
sentence from RFC 2361 (security considerations) seems applicable here.
"All the security in this system is provided by the secrecy of the
private keying material." If this the case, please provide ample warning
that (as one would expect) loss of the password from either the client or
the server results in a complete compromise.

---

From: 大岩寛 <[email-masked]>
Date: Wed, 2 Nov 2016 08:41:16 +0000

Dear Terry, thank you very much.

> 1) Please review the introduction, there are several grammatical errors in
> there. Meaning still came through just fine, but they were a little distracting.

We'll do it.

> 2) The state machine diagram of the client is quite complex. A candidate for
> the new RFC format?

Maybe :-)  I have picture-based (HTML/PDF) versions, too.

> 3) I agree with Alvaro's comment on the IPR. Thank you for making it royalty
> free, however not sure you need to add the text in the RFC.

Thank you very much for the suggestion.

> 4) This to me seems as it is essentially a shared secret construct, one sentence
> from RFC 2361 (security considerations) seems applicable here.
> "All the security in this system is provided by the secrecy of the private keying
> material." If this the case, please provide ample warning that (as one would
> expect) loss of the password from either the client or the server results in
> a complete compromise.

We already put some analysis on those, but we'll make it more prominent.
More precisely, loss from the client is really critical (even with a strong password);
Loss from the server is only severe when the password is weak for dictionary attacks.

-- 
Yutaka OIWA, Ph.D.       Leader, Cyber Physical Architecture Research Group
                                  Information Technology Research Institute
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Yutaka OIWA <[email-masked]>
Date: Wed, 9 Nov 2016 15:11:12 +0900

Dear Terry,

thank you for the detailed comment.

We try to improve it in the next draft.

> 2) The state machine diagram of the client is quite complex. A candidate

Maybe :-)  We have a vector-graphics version in our hand.
(former submitted PDF versions have included it.)

> royalty free, however not sure you need to add the text in the RFC.

Thank you.  We remove it.

> the server results in a complete compromise.

Situation is a bit more detailed (strong passwords are safe against
server-side compromise), and We'll add a new subsection in Security Consideration.