[NNTP] Future-proofing for including capabilities in responses

[Ken Murchison]

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.

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

> Would you want a separate code for a failed TLS?

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.


> As a very minor point, it eliminates the anomaly that the 382 response is,
> in effect, final rather than intermediate - there's no later 2xx/4xx/5xx
> response.

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.

> Off the top of my head, I can think of three ways that the information can
> be provided once the feature has been turned on:
> 
> (1) Any response can be preceded by an update response code in the 6xx
> block:
> 
>     [C] STARTTLS
>     [S] 382 Continue with negotiation
>     [TLS negotiation occurs here]
>     [S] 601 New capability list follows
>     [S] VERSION 2
>     [S] READER POST
>     [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT
>     [S] .
>     [S] 201 Welcome to the secure server
> 
> (2) A flag, either before or after the three digit code, indicates that
> capability information will follow:
> 
>     [C] STARTTLS
>     [S] 382 Continue with negotiation
>     [TLS negotiation occurs here]
>     [S] 201+ Welcome to the secure server, capability information follows
>     [S] VERSION 2
>     [S] READER POST
>     [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT
>     [S] .
> 
> (3) A flag before the three digit code of a response indicates another
> response will follow:
> 
>     [C] STARTTLS
>     [S] 382 Continue with negotiation
>     [TLS negotiation occurs here]
>     [S] +201 Welcome to the secure server
>     [S] 101 Capability information follows
>     [S] VERSION 2
>     [S] READER POST
>     [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT
>     [S] .
> 
> [In each case I'm using STARTTLS as the example, but the same could apply
> to AUTHINFO and MODE READER among others.]

The only variants that would work with AUTHINFO are (2) and (3).  Since 
AUTHINFO SASL might negotiate a security layer, the capabilities stuff 
MUST NOT be returned until AFTER the SASL exchange has completed, which 
may not be until a 283 response (server success data).

Of the two, I prefer (2) since (3) has back-to-back response codes.  (2) 
has the feel of transforming what would normally be a single line 
response into a multi-line response, which seems cleaner IMHO.

Actually, if the client enables the "unsolicited capabilities response" 
feature do we even need an indicator like "+", since the client will 
already know to expect the capabilities after STARTTLS, AUTHINFO and 
MODE READER?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp