On 4/24/15 5:41 AM, Simon Josefsson wrote:
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.
Good point.
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.
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
aspects may lead to interoperability and security issues if migration is
not coordinated among protocols and implementations.
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.
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?
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.
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.
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/