[NNTP] Fwd: Discuss: nntp authinfo and tls
rra at stanford.edu
Thu Jul 21 18:22:27 PDT 2005
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/>
More information about the ietf-nntp