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

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 May 2014 20:16:01 -0600

Hi Stephen, sorry about the delayed reply - I'm just not getting back to 
processing feedback on this I-D.

On 4/24/14, 8:40 AM, Stephen Farrell wrote:
>
> Hi Peter,
>
> On 04/24/2014 03:31 PM, Peter Saint-Andre wrote:
>> On 4/24/14, 7:20 AM, Stephen Farrell wrote:
>>> 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.
>>
>> 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
>
> I'm fine that you've discussed this with Barry.

The exact disposition of the appendix and the registration process 
remains to be clarified, in part based on Pete's work in finding a 
designated expert.

>>> 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.
>>
>> 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.
>
> 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:-)

That part is quoted from RFC 5892. However, in the note that precedes 
the quoted text, I suggest that we add the following sentence:

    At the time of this writing (and also at the time that
    RFC 5892 was published), this category consisted of the
    empty set; however, that is subject to change as described
    in RFC 5892.

>>> 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?
>>
>> s/MUST/are strongly encouraged to/ ?
>
> Yes, I think that's better.

Will fix.

>> 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
>
> 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;-)

Sorry, internationalization is messy.

>>> 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:-)
>>
>> 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?
>
> You already reference that draft from here so its probably
> ok, but I guess the point is generic and not sasl-specific

Actually, despite its title, draft-ietf-precis-saslprepbis is not really 
SASL-specific.

> so it could (also) be mentioned here. Your call though, as
> its a fairly minor and pretty obvious thing.

Nothing is obvious. :-) We'll add some text here (I think I'll just copy 
and paste that paragraph from draft-ietf-precis-saslprepbis).

Thanks again for your feedback.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 May 2014 19:01:51 -0600

On 5/21/14, 1:26 PM, John C Klensin wrote:
>
>
> --On Tuesday, 20 May, 2014 20:16 -0600 Peter Saint-Andre
> <[email-masked]> wrote:
>
>> ...
>> That part is quoted from RFC 5892. However, in the note that
>> precedes the quoted text, I suggest that we add the following
>> sentence:
>>
> Unless I misunderstand, if the kinds of exceptions that would
> justify using that category were to arise, we'd need separate
> review and evaluation systems and approvals for IDNA and PRECIS,
> even if they were largely performed by the same people.

Unless *I* misunderstand, the kinds of exceptions that would lead to 
populating the BackwardCompatible category specified in RFC 5892 are 
limited to adding characters to or removing characters from the 
LetterDigits category. If indeed one of our goals is to reduce the 
possibility of user astonishment, it seems preferable for the PRECIS 
classes (and profiles thereof) to track the BackwardCompatible category 
itself, rather than to define a PrecisBackwardCompatible category. This 
will also simplify implementations.

Peter

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 May 2014 15:26:13 -0400

Unless I misunderstand, if the kinds of exceptions that would
justify using that category were to arise, we'd need separate
review and evaluation systems and approvals for IDNA and PRECIS,
even if they were largely performed by the same people.
Moreover, if PRECIS stays with the profile model it is using
now, we have no basis on which to judge whether this category
(exceptions apply to all protocols and profiles) is adequate or
whether each new version of Unicode requires per-protocol or
per-profile reviews.  That is another reason why a system that
allows or encourages a growing family of profiles gives me the
creeps.  

Six months ago, it would have been sensible to treat the above
comment as largely theoretical: the category was reserved as a
placeholder that we never expected to use.   At this point,
unless an apparent problem that was spotted in Unicode 7.0.0
beta is addressed in a serious way by UTC, the possibility of
having to use the category is very real.  It is also important
to note that the problem was spotted by inspection by a
moderately skilled human after it had successfully gotten
through the usual testing implementations and preliminary review
by the relevant expert.

best,
     john