Subject: [NNTP] draft-ietf-nntpext-tls-nntp-02.txt

From: clive at demon.net (Clive D.W. Feather)
Date: Fri Sep 17 06:17:33 2004

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-nntpext-tls-nntp-02.txt

1.1: suggest you replace the last para with the text that's in NNTPAUTH:

     The notational conventions used in this document are the same as
     those in [NNTP] and any term not defined in this document has the
     same meaning as in that one.

2 para 3: s/MUST NOT be used/MUST NOT be relied on/  (the stuff in 11.6
only forbids caching security information).

2 last para: we don't have the concept of a mode change in NNTP. This
paragraph merely repeats the meaning of "This command MUST NOT be
pipelined" in 3.1 and therefore isn't needed.

3.2.1 para 2: in option (1), rather than dropping the connection
immediately it should use the 400 generic response code.

However, it appears from discussions back in March that this situation can
never happen because it's the server which decides what offer in the first
place. So all this text can be deleted.

Also back in March, I wrote:

| However, I'm a little bothered by the asymmetry between TLS failure, where
| the *server* moves next (issuing a response code), and success, where the
| *client* moves next (issuing a command). If this isn't cast in stone, then
| I would strongly suggest making it always the server. This has an
| additional benefit: you can specify that, after TLS negotiation ends
| successfully, both sides return to the NNTP initial connection state with
| the server issuing an initial greeting. I suspect this will make things
| easier for client design.

I'm not sure that I ever got an answer.

3.2.1 last para, second bullet: s/client, however/client. However/

3.2.2 first para: will it be clear from the TLS negotiation whether it
succeeded or failed? Note that this would be a good place for the 400 I
mention above.

Is there any benefit in having a response

6 para 7: do you mean "deleting the 382 response" or do you mean "replacing
the 382 response with a 502 response"? If you just delete the response, the
client will sleep forever.

6 para 8: s/retry TLS at a later time/retry TLS later in the session/

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: rra at stanford.edu (Russ Allbery)
Date: Sun Sep 26 15:56:51 2004

>      same meaning as in that one.

Sounds fine to me.

> only forbids caching security information).

Agreed.

> pipelined" in 3.1 and therefore isn't needed.

Agreed.

> immediately it should use the 400 generic response code.

No, because at the successful conclusion of the command, it's the client's
turn, at least as we've currently laid out the specification.  The server
is allowed to simply close the connection, but it's not allowed to send a
response, as I understand it.

> However, it appears from discussions back in March that this situation
> can never happen because it's the server which decides what offer in the
> first place. So all this text can be deleted.

This also sounds correct to me, and deleting text is even better.

> | However, I'm a little bothered by the asymmetry between TLS failure,
> | where the *server* moves next (issuing a response code), and success,
> | where the *client* moves next (issuing a command). If this isn't cast
> | in stone, then I would strongly suggest making it always the
> | server. This has an additional benefit: you can specify that, after
> | TLS negotiation ends successfully, both sides return to the NNTP
> | initial connection state with the server issuing an initial
> | greeting. I suspect this will make things easier for client design.

> I'm not sure that I ever got an answer.

This sounds like a fundamentally good idea to me.  Ken, any opinions here?

> succeeded or failed?

Yes.

> Note that this would be a good place for the 400 I mention above.

I don't see how.  580 doesn't mean that the connection is closing, whereas
400 does, does it not?

> 6 para 7: do you mean "deleting the 382 response" or do you mean
> "replacing the 382 response with a 502 response"? If you just delete the
> response, the client will sleep forever.

Yes, it would need a replacement.  I agree with this change.

The other minor wording changes look good to me.  Does everyone think that
with the above issues resolved, we're ready to go to last call on this
document?

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: clive at demon.net (Clive D.W. Feather)
Date: Tue Sep 28 05:49:31 2004

Russ Allbery said:
> turn, at least as we've currently laid out the specification.

Yes, but (a) see below and (b) the server can respond with a 400 to the
*next* command.

> This also sounds correct to me, and deleting text is even better.

Which makes it moot.

>> 3.2.2 first para: will it be clear from the TLS negotiation whether it

Okay.

> I don't see how.  580 doesn't mean that the connection is closing, whereas

That's the point. The server then has a choice, something like this:

    If the TLS handshake fails in such a way that it is possible to
    recover the underlying NNTP session, the server will send a
    response (without encryption), beginning with the first post-
    handshake octet. If the server is willing to continue the connection
    the response code 580 MUST be used; if not, the response code 400
    MUST be used and the server MUST then close the connection.

So we get four cases:
* succeeded: no response, client's turn
* failed, session recovered, server will continue     -> 580 response
* failed, session recovered, server will not continue -> 400 response
* failed, session can't be recovered, close connection (?)

Yes.

---

From: rra at stanford.edu (Russ Allbery)
Date: Tue Sep 28 12:00:49 2004

>> I don't see how.  580 doesn't mean that the connection is closing,
>> whereas 400 does, does it not?

> * failed, session can't be recovered, close connection (?)

Yeah, I see your point.  I think that originally we had the server
responding after the completion of the TLS handshake, and then that was
removed for some reason (maybe because other protocols didn't have it).

IMAP has asynchronous replies, so what it does doesn't help.  POP doesn't
have any server response after the TLS negotiation; it either succeeds or
fails, but the server only sends -ERR before it even tries (it sends
either -ERR or +OK and then, if it sent +OK, goes immediately into the TLS
negotiation).  SMTP also says that the server responds immediately to the
STARTTLS command and then the TLS handshake begins following that
response.  It does not allow the server to send any response following
completion of the TLS handshake.

None of the other protocols that use STARTTLS appear to allow the server
to send a response after the STARTTLS negotiation.  I think that the first
paragraph of 3.2.2 doesn't actually belong in 3.2.2.  In fact, I think
that we can drop it completely, since it arises via a difference in
wording between our draft and SMTP.  We say:

     After the TLS handshake has been completed successfully, both
     parties MUST immediately decide whether or not to continue based on
     the authentication and privacy achieved.

SMTP says (RFC 3207):

     After the TLS handshake has been completed, both parties MUST
     immediately decide whether or not to continue based on the
     authentication and privacy achieved.

Note the absence of the word "successfully."  I think we should just adopt
the SMTP language, which makes the problem go away -- a failed TLS
handshake that allows recovery of the NNTP session is then completion of
the TLS handshake, with no authentication and privacy achieved, and the
client and server should then proceed as described in 3.2.1.  We can say
something explicit about that if it seems useful.

---

From: ken at oceana.com (Ken Murchison)
Date: Wed Sep 29 08:05:46 2004

>      same meaning as in that one.

Done.

> only forbids caching security information).

Done.

> pipelined" in 3.1 and therefore isn't needed.

Done.

> immediately it should use the 400 generic response code.

Taking this discussion to another post.

> 3.2.1 last para, second bullet: s/client, however/client. However/

Done.

Yes.

  > 6 para 7: do you mean "deleting the 382 response" or do you mean 
"replacing
> client will sleep forever.

This was a failed translation from RFC 3207.  The sentence should say:

"... deleting the STARTTLS extension label in the LIST EXTENSIONS 
response from the server."

> 6 para 8: s/retry TLS at a later time/retry TLS later in the session/

Done.

-- 
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

---

From: ken at oceana.com (Ken Murchison)
Date: Wed Sep 29 08:22:15 2004

>>    MUST be used and the server MUST then close the connection.

Note that the option of closing the connection is something that is not 
present in RFC 3207 (on which most of this text is based).  It was added 
by Jeff because he felt that servers may not want to have client beating 
on them after a failed TLS.  I never really liked this text and would 
prefer to just stick with the original RFC 3207 text (just issue 483 
responses to subsequent commands).  Doesn't the base doc already allow 
servers to unilaterally terminate the connection and addresses how to do 
this?  If so, do we need to address this in the STARTTLS doc?

> removed for some reason (maybe because other protocols didn't have it).

Correct.

> paragraph of 3.2.2 doesn't actually belong in 3.2.2.

I believe that someone wanted this text added to clarify that the 580 
response would be unencrypted.  I think it should be obvious that if the 
TLS negotiation failed, that we don't have encryption, so I'm open to 
removing this paragraph, or moving it elsewhere if we want to keep the 
clarification.

> In fact, I think

Agreed.

---

From: rra at stanford.edu (Russ Allbery)
Date: Wed Sep 29 11:59:15 2004

> this?  If so, do we need to address this in the STARTTLS doc?

I'm pretty sure unilateral termination is already allowed, and in any
event it can happen whether allowed or not so clients have to cope with
it.  I don't have a problem with sticking to the original text here.
Jeff, do you still think this is needed?

---

From: jeff at litech.org (Jeffrey M. Vinocur)
Date: Wed Sep 29 19:28:22 2004

> Jeff, do you still think this is needed?

[ I'm scrambling to keep up with all this traffic. Trying to follow. ]

IIRC, this was because any case where the server can unilaterally close 
the connection makes me worried about a naive client inadvertently 
DOS'ing the server.

I mean, if the client author isn't prepared for a unilateral 
termination to be purposeful (rather than a network glitch dropping the 
connection), the client software might immediately reconnect and repeat 
the same sequence of commands, causing the server to unilaterally 
terminate again, and so on, indefinitely.

This concern seems very real to me, but I could certainly be convinced 
if people disagree.

And if it's real concern, I'm not necessarily sure this is the best 
text to handle it either.

Regardless, I do feel like we're misleading to client authors if the 
spec says only "the server will reject all further commands" when in 
practice servers are quite likely to close the connection, even if 
somewhere in a different document we warn them that the server can 
close the connection at any time.

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: rra at stanford.edu (Russ Allbery)
Date: Wed Sep 29 19:46:16 2004

> the connection makes me worried about a naive client inadvertently

Yeah, I can see that part.

> somewhere in a different document we warn them that the server can close
> the connection at any time.

This I'm not sure about, just in that I'm not sure why the server would
need to close the connection.  Surely if it starts returning 483 to every
command, the client will either go back and try doing this again, or will
eventually give up.  As a server author, I'd tend to just throw the server
into a reject everything mode and not worry too much about it.

---

From: jeff at litech.org (Jeffrey M. Vinocur)
Date: Thu Sep 30 02:46:46 2004

> into a reject everything mode and not worry too much about it.

I was basing this on the fact that INN's nnrpd does close the 
connection on a failed AUTHINFO USER/PASS, which is a vaguely parallel 
case.

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: ken at oceana.com (Ken Murchison)
Date: Thu Sep 30 09:55:25 2004

> into a reject everything mode and not worry too much about it.

So, are we saying that we can omit the discussion of the server closing 
the connection and just stick with returning 483 to subsequent commands?

---

From: rra at stanford.edu (Russ Allbery)
Date: Thu Sep 30 10:43:34 2004

>> need to close the connection.  Surely if it starts returning 483 to
>> every command, the client will either go back and try doing this again,
>> or will eventually give up.  As a server author, I'd tend to just throw
>> the server into a reject everything mode and not worry too much about
>> it.

> the connection and just stick with returning 483 to subsequent commands?

That's my vote, but I'm not sure if anyone objects.

---

From: rra at stanford.edu (Russ Allbery)
Date: Thu Sep 30 11:12:25 2004

Jeffrey M Vinocur <[email-masked]> writes:

> I was basing this on the fact that INN's nnrpd does close the connection
> on a failed AUTHINFO USER/PASS, which is a vaguely parallel case.

Ah, okay.  I'm not sure that INN is correct to do that either.