[NNTP] Future-proofing for including capabilities in responses

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:
> Clive D.W. Feather wrote:
>> Russ Allbery said:

>>> * Add a final response to the STARTTLS protocol so that, after TLS
>>>   negotiation completes, the server sends a response to the client saying
>>>   that the TLS negotiation completed.  We discussed doing this before and
>>>   there was some support for doing it, but we didn't, as I recall, mostly
>>>   because other protocols didn't and there didn't seem to be a point.

>> I would be very much in favour of this. As I recall, I suggested
>> re-sending the 200 or 201 greeting.

> Wouldn't this break INN?  It currently has a STARTTLS implementation
> based on existing practice in IMAP/POP/SMTP which also conforms to the
> current nntp-tls draft.

Yes, this would break (well, declare non-compliant) INN's current
behavior.  Note that INN also uses the wrong reply codes and has a few
other problems at the moment.

I'm not aware of any news client that issues STARTTLS at present, rather
than using a separate port for SSL connections.  I think we're probably
still at the point where we can change this.  On the other hand, changing
who's supposed to go next is a much more significant change than changing
response codes.

> Is this response sent in the clear, or is it encrypted?

Encrypted.  (There wouldn't be any use for using it to convey capabilities
otherwise.)

> Obviously, this response would have to be sent in the clear.  It would
> seem totally asymetric to have a command return an encrypted response in
> one case, but a plaintext response in the other.  I'm sure this is one
> of the reasons why the existing TLS profiles, don't use a response
> code. I could probably dig through some archives to see if there is a
> thread which discusses this.

Mark seemed to feel that adding a response code at the end wouldn't be a
problem protocol-wise, so he may have an immediate feeling on how to
handle this issue.

> Actually, there is a response, just not one that conforms to NNTP.  The
> TLS exchange will finish with a success/failure.  Adding a response to
> NNTP would just be redundant (since both the client and server already
> know the result), but I won't argue this point very strongly.

Right, it is redundant for all of our current purposes.  The only reason
to add it from our perspective is to allow it to be used as a vehicle for
capabilities information in the future, should one of the proposals for
how to do that mature.

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