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

From: jeff at litech.org (Jeffrey M. Vinocur)
Date: Fri Oct 1 04:44:10 2004

On Sep 30, 2004, at 2:12 PM, Russ Allbery wrote:

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

I never found that behavior elegant, but I can certainly see why server 
authors might choose it.

Hmm.  I mean, if no one else thinks is a problem, I'm not about to fall 
on my sword over it.

(Perhaps we could add a caution to client authors in the Generic 
Responses section of the base spec, warning not to DOS the server by 
rapidly retrying many times after receiving a 400 response?)

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: clive at demon.net (Clive D.W. Feather)
Date: Fri Oct 1 04:55:17 2004

Russ Allbery said:
> 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.

I agree. [Minor nit: I would say "... based on *any* ...".]

-- 
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: clive at demon.net (Clive D.W. Feather)
Date: Fri Oct 1 04:58:29 2004

Ken Murchison said:
> 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

Nor do I: a dropped connection is likely to be seen as an error and the
client could then retry automatically. So it beats on the server anyway.

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

I think that the STARTTLS doc just needs to say something like "If the
client is unhappy with the state of the connection, issue QUIT. If the
server is unhappy with the state of the connection, issue 483 if more TLS
negotiation could fix it and 400 (and terminate) if it can't." Only in
better words, of course.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Fri Oct 1 04:59:29 2004

> rapidly retrying many times after receiving a 400 response?)

I'd be happy to do that if Russ is happy with the procedural load (it means
issuing a new draft for Last Call instead of the present one).

---

From: clive at demon.net (Clive D.W. Feather)
Date: Fri Oct 1 05:01:07 2004

Jeffrey M. Vinocur said:
> 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.

Indeed.

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

I see this as a concern.

And this is why we have the 400 response - to indicate *purposeful*
termination rather than accidental.

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

So we say "the server will reject all further commands, which MAY
include issuing a 400 generic response".

---

From: rra at stanford.edu (Russ Allbery)
Date: Fri Oct 1 11:25:44 2004

Clive D W Feather <[email-masked]> writes:

> server is unhappy with the state of the connection, issue 483 if more
> TLS negotiation could fix it and 400 (and terminate) if it can't." Only
> in better words, of course.

Yeah, this sounds right to me as well.

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

---

From: rvtol at isolution.nl (Ruud H.G. van Tol)
Date: Fri Oct 1 11:26:26 2004

> rapidly retrying many times after receiving a 400 response?)

Or even strongly suggest that the time in between retries 
should be doubled for each retry.

-- 
Grtz, Ruud

---

From: rra at stanford.edu (Russ Allbery)
Date: Fri Oct 1 11:29:33 2004

> I'd be happy to do that if Russ is happy with the procedural load (it
> means issuing a new draft for Last Call instead of the present one).

Actually, we've already gone through Last Call, and I don't believe we've
made any changes of sufficient substance to force us to go through it
again.  However, I'm currently talking with Mark Crispin and he's raised
some good points that I'm still trying to digest enough to relay to the
mailing list.  We may have to do another round with those changes since he
appears to have completely missed the first Last Call that we did (I'm not
quite sure what the procedure is on that).

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 4 02:35:13 2004

> quite sure what the procedure is on that).

Okay, so it sounds like I should be planning on a new draft anyway. I'll
add changes to the 400 text.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 4 02:43:06 2004

>>>> rapidly retrying many times after receiving a 400 response?)

Proposed change:

    If the server has to terminate the connection for some reason, it
    MUST give a 400 response code to the next command and then immediately
+   close the TCP connection.  Following a 400 response, clients SHOULD
+   NOT simply reconnect immediately and retry the same actions.  Rather,
+   a client SHOULD either use an exponentially increasing delay between
+   retries (e.g. double the waiting time after each 400 response) or
+   present any associated text to the user for them to decide whether and
+   when to retry.

---

From: rra at stanford.edu (Russ Allbery)
Date: Mon Oct 4 12:35:06 2004

> +   present any associated text to the user for them to decide whether and

This sounds fine to me.