Subject: [precis] Last Call: <draft-ietf-precis-saslprepbis-15.txt> (Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 14 Apr 2015 11:59:58 -0700

The IESG has received a request from the Preparation and Comparison of
Internationalized Strings WG (precis) to consider the following document:
- 'Preparation, Enforcement, and Comparison of Internationalized Strings
   Representing Usernames and Passwords'
  <draft-ietf-precis-saslprepbis-15.txt> as Proposed Standard

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 2015-04-28. 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

   This document describes updated methods for handling Unicode strings
   representing usernames and passwords.  The previous approach was
   known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454).
   The methods specified in this document provide a more sustainable
   approach to the handling of internationalized usernames and
   passwords.  The PRECIS framework, RFC YYYY, obsoletes RFC 3454, and
   this document obsoletes RFC 4013.

   [[ NOTE TO RFC EDITOR: please replace "YYYY" in the previous
   paragraph with the RFC number assigned to draft-ietf-precis-
   framework. ]]

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 24 Apr 2015 13:41:39 +0200

Hi.  I would appreciate if this document contained a discussion of the
implications for RFCs that currently normatively reference RFC 4013.
This is warranted since the new document intends to obsolete RFC 4013.

SASLprep and the several profiles defined by this document give
different outputs for some inputs.  This new protocol can also give
different outputs depending on which Unicode version the implementation
uses.  Further, it is not clear how to map different uses of SASLprep
into the different profiles described in this document.  Combined, these
aspects may lead to interoperability and security issues if migration is
not coordinated among protocols and implementations.

Essentially, what does it mean for this document to obsolete RFC 4013
for an implementation implements a protocol that normatively reference
RFC 4013?  When are implementations supposed to be updated to use this
document?  Now, or when the respective RFC is updated to point towards
this new document?

I have read section 6 on migration.  It is helpful, but does not really
address the question above.

If my assumption that other RFCs needs to be updated before
implementations should be updated, please consider clarifying this in
the document by adding a paragraph like this to section 6.  Feel free to
reword or rewrite this as you want.

  While this section describes migration, this document does not have
  any direct implication for implementations that implement RFCs that
  uses SASLprep today.  These RFCs will each need to be updated before
  implementation should migrate to using the techniques described in
  this document.  Non-coordinated updates of protocol implementations
  can affect interoperability and security and is therefor discouraged.

Thanks,
/Simon

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 27 Apr 2015 20:00:01 -0600

> This is warranted since the new document intends to obsolete RFC 4013.

Good point.

> uses.

Do you think that more text is needed on those points?

> Further, it is not clear how to map different uses of SASLprep
> into the different profiles described in this document.

As I see it, that "mapping" task is a job for those who update 
definitions for existing uses of SASLprep. See below.

> Combined, these

I am not sure if migration needs to be coordinated across protocols 
(e.g., does XMPP need to be in sync with STUN?).

I do think that some rough coordination across implementations of a 
given protocol is desirable, and those implementation communities would 
do well to pursue such coordination through the normal standards 
processes. See below.

> document?  Now, or when the respective RFC is updated to point towards

The latter.

I see this as similar to, say, RFC 6125 on server identity checking or 
draft-ietf-uta-tls-bcp on TLS usage. If an existing application protocol 
uses SASLprep as defined in RFC 4013, then that protocol can and should 
continue to use SASLprep until and unless the relevant RFC is updated or 
obsoleted. To choose an example at random, Dynamic Symmetric Key 
Provisioning Protocol (DSKPP) as defined in RFC 6063 uses SASLprep to 
normalize user input. Unless someone publishes 6063bis to obsolete that 
usage, DSKPP would continue to use SASLprep until the end of time. If 
the community of people who implement and deploy DSKPP care about these 
issues and experience the pain of being locked into Unicode 3.2 forever 
(etc.) through Stringprep, then they will take the initiative to update 
or obsolete RFC 6063. If they added that text about using SASLprep only 
to please some IESG member who mentioned internationalization, then the 
DSKPP community might never modernize their specifications. But this is 
not significantly different from things like server identity checking or 
applying TLS best practices.

>    can affect interoperability and security and is therefor discouraged.

Yes, something like that would be very helpful; thanks for the proposed 
text. We might also borrow some text or concepts from existing 
documents, such as Section 1.4 of RFC 6125, Section 1 of RFC 6648, and 
Section 5 of draft-ietf-uta-tls-bcp.

Peter

--
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 27 Apr 2015 20:19:16 -0600

> Section 5 of draft-ietf-uta-tls-bcp.

Here is further proposed text:

    This document does not modify the handling of internationalized
    strings in usernames and passwords as prescribed by existing
    application protocols that use SASLprep.  If the community that uses
    such an application protocol wishes to modernize its handling of
    internationalized strings to use PRECIS instead of stringprep, it
    needs to explicitly update the existing application protocol
    definition (one example is [I-D.ietf-xmpp-6122bis], which obsoletes
    [RFC6122]).  Non-coordinated updates to protocol implementations are
    discouraged because they can have a negative impact on
    interoperability and security.

Does that address your concern?

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Apr 2015 12:42:55 +0200

> Do you think that more text is needed on those points?

I don't think text will help.  I believe this design property will lead
to slow migration and frustration from implementers.  Compare the state
of IDNA2008.  So, I don't see how more text would make a difference.

> (e.g., does XMPP need to be in sync with STUN?).

Agreed.  I didn't intend that and agree my wording could be interpreted
the wrong way.  I meant coordination among implementation of a
particular protocol.  It would be bad if, for two implementations of one
protocol, for one of the implementations to migrate from SASLprep to
SASLprepbis on its own.

> given protocol is desirable, and those implementation communities
> would do well to pursue such coordination through the normal standards
> processes. See below.

Agreed.

>> document?  Now, or when the respective RFC is updated to point towards

Good!  I wasn't confident in this interpretation.

> Does that address your concern?

Awesome, thank you!

/Simon