[NNTP] Fwd: Discuss: nntp authinfo and tls

[Russ Allbery]

Sam's message first and then my comments:

| To: iesg at ietf.org
| Cc: rra at stanford.edu
| Subject: Discuss: nntp authinfo and tls
| From: Sam Hartman <hartmans-ietf at mit.edu>
| 
| The authinfo draft needs to discuss internationalization of the
| strings for the authinfo user and authinfo pass commands.  They are
| listed as UTF8 but no issues like normalization are discussed.
| Personally I'd recommend that the server should use saslprep on the
| strings.  Regardless of what decision the WG comes to the issue needs
| discussion and consideration.  There is somewhat of a discussion of
| the complexities in the sasl plain draft.
| 
| 
| The authinfo draft needs to discuss what happens if both a SASL
| security layer and TLS are negotiated.  I'd recommend that the SASL
| security layer be applied first, although double check against
| existing implementations.  I would explicitly recommend against the
| option of forbidding both security layers and TLS at the same time
| although the WG certainly can make that decision if it chooses.
| 
| In the TLS draft, please check the text about resuming after TLS
| failures with the TLS community.  It is my understanding that most
| implementations make this difficult or impossible.  I don't need to
| review any text changes in response to this item.  I'm simply
| requesting that you double check with the TLS community and make an
| informed decision.
| 
| The TLS document discusses certificate matching but does not discuss
| certificate verification.  I'd recommend using the certificate
| verification specified in RFC 3280.  You certainly need to say
| something about verification.
| 
| 
| Shouldn't the change controller for these extensions be the IESG not
| the authors?

There has been further discussion of the i18n consideration for AUTHINFO
USER/PASS.  I think the best course of action would be to drop the comment
in the draft saying that the username and password are in UTF-8, which
implies that some canonicalization should be done, and instead say that
they are opaque strings and the server will do a byte-by-byte comparison.
That's a good description of current practice.

I'm not sure if we should still recommend (but not require)
canonicalization.  I'll forward another message about that.

The language about security layers is there; I'll let Sam know.

We're already discussing resuming after TLS failure.

I haven't looked at the verification point in detail yet.  I'll inquire
further about change controller; I'm not sure what the issue is exactly,
but Sam's comment seems reasonable to me.

--
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>