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

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 24 Apr 2014 06:20:59 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-precis-framework-16: 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:
----------------------------------------------------------------------

- 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: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Apr 2014 08:31:38 -0600

> http://datatracker.ietf.org/doc/draft-ietf-precis-framework/

Appendix A has been checked using two implementations. The question is 
whether we want to base the initial registration on a third.

But yes, the *initial* registration *could* use Appendix A once it has 
been reviewed by the designated expert (who might find errors, despite 
the fact that Takahiro Nemoto and I checked our independent results and 
came to agreement on the derived properties).

This was discussed on the WG list, see for instance:

http://www.ietf.org/mail-archive/web/precis/current/msg00605.html

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

We are simply referencing RFC 5892 here:

http://tools.ietf.org/html/rfc5892#section-2.7

Further, the PRECIS Derived Property Value Registry will specify only 
the derived properties (e.g., UNASSIGNED or PVALID), not the interim 
steps used to calculate the derived properties (e.g., HasCompat or 
BackwardCompatible). So the latter values are never populated into the 
registry.

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

s/MUST/are strongly encouraged to/ ?

One example of what an application protocol spec could say is here:

http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12#section-7.3.2

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

Well, draft-ietf-precis-saslprepbis currently says:

    In protocols that provide usernames as input to a cryptographic
    algorithm such as a hash function, the client will need to perform
    proper preparation of the username before applying the algorithm.

and:

    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.

Would some text along those lines in the security considerations of this 
document meet your needs?

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Apr 2014 15:40:38 +0100

Hi Peter,

> http://www.ietf.org/mail-archive/web/precis/current/msg00605.html

I'm fine that you've discussed this with Barry.

> BackwardCompatible). So the latter values are never populated into the

The bit that I found odd (no more) was: "G: cp is in {}"

I think that's just saying there are no code points in this
category at the moment, which is fine, but that wasn't
(clearly) stated, instead it says "This category includes..."
which is a bit confusing since its the empty set.

If you wanted, s/This category includes/This currently
empty category will include/ would be clearer for me.
(Assuming I read it right:-)

> s/MUST/are strongly encouraged to/ ?

Yes, I think that's better.

> http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12#section-7.3.2

Right. I note that that's over a page of text. Seems like
a pity it can't be much shorter, but I guess that's just
life;-)

> document meet your needs?

You already reference that draft from here so its probably
ok, but I guess the point is generic and not sasl-specific
so it could (also) be mentioned here. Your call though, as
its a fairly minor and pretty obvious thing.

Cheers,
S.