Subject: [precis] Stephen Farrell's No Objection on draft-ietf-precis-framework-22: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 19 Feb 2015 07:55:35 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-precis-framework-22: 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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-precis-framework/

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

Last time this came around I had the comments below.
While Barry no longer has a DISCUSS, I'd still be 
interested in chatting a bit about these. (Apologies
that I've not had time to re-read the draft though, so
feel free to just tell me these comments are OBE if
that's the case.)

"
- I agree with Bary's discuss - it seems weird to not
have the initial registries in hand when the RFC is
being issued. People will, I guess, implement from
Appendix A here anyway, so why not either delete this
and get the registry in place, or else make Appendix A
be the initial registry content.

7.7: This uses the empty set, which is puzzling. I think
you mean that this set is to be populated by the DE in
the IANA registries but if so, saying so would be good.

10.5: This says that a) its all too hard but also b)
"Nevertheless, specifications for application protocols
that use this framework MUST describe how confusable
characters can be abused to compromise the security of
systems that use the protocol in question, along with any
protocol-specific suggestions for overcoming those
threats." That seems like a 6919 MUST (but we know you
won't) to me. Is that a good plan?

10.6: Prompted by the secdir review, it might be worth a
few words on password hashing, which is very common.  E.g.
say that the canonical form is input to hashing and
therefore just can't be mucked about with. (But say that
nicely:-)
"

---

From: Pete Resnick <[email-masked]>
Date: Thu, 19 Feb 2015 10:23:35 -0600

OBE. We changed the whole way this was done.

> the IANA registries but if so, saying so would be good.

OBE. Section changed to make this clear.

> won't) to me. Is that a good plan?

Changed "MUST" to "are strongly encouraged to"

> therefore just can't be mucked about with. (But say that

Added:

    In protocols that provide passwords as input to a cryptographic
    algorithm such as a hash function, the client will need to perform
    proper preparation of the password before applying the algorithm,
    since the password is not available to the server in plaintext form.

I hope that addresses everything.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Feb 2015 18:44:52 +0000

All good thanks,
S.