Subject: [NNTP] TLS draft question

From: Russ Allbery <[email-masked]>
Date: Tue, 19 Jul 2005 13:40:16 -0700

Currently, the TLS draft says that STARTTLS may fail but the NNTP session
may continue.  A question has been raised as to whether this is possible
to do reliably, since if TLS has failed, the connection may be in an
indeterminate state.  Are there other STARTTLS specifications that allow
this case?  I don't remember off-hand if the TLS working group review
addressed this point in particular.

The alternative would be to simply require closing the connection if the
TLS negotiation fails, either on the server or the client end (rather than
only on the client end as is currently specified).

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

---

From: Ken Murchison <[email-masked]>
Date: Tue, 19 Jul 2005 16:53:03 -0400

Russ Allbery wrote:

> indeterminate state.

Both the client and server will know if the negotiation failed, so I 
don't think its indeterminate.

> Are there other STARTTLS specifications that allow

Yes.  I believe that our text follows that of IMAP, POP3 and SMTP in 
that the session may continue even if the TLS negotiation failed.

-- 
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: Ned Freed <[email-masked]>
Date: Tue, 19 Jul 2005 14:33:20 -0700 (PDT)

> that the session may continue even if the TLS negotiation failed.

That may be the theory, but it almost never works in practice, in my
experience at least.

				Ned

---

From: Ken Murchison <[email-masked]>
Date: Tue, 19 Jul 2005 18:44:36 -0400

> That may be the theory, but it almost never works in practice, in my

Ned, are you suggesting that the server should just unilaterally 
disconnect the client if TLS fails?  I know for a fact that the Cyrus 
servers (IMAP, POP3, NNTP, LMTP) simply revert back to using its own I/O 
routines rather than the OpenSSL equivalents if TLS fails.  I haven't 
tried this with any clients to see how they behave.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Jul 2005 15:50:27 -0700

> That may be the theory, but it almost never works in practice, in my

I think Ned's right here, if for no other reason than that SSL
implementations can buffer and so you've now got to figure out how to
unbuffer the data. Sorry for not catching that when Id id my
review..

-Ekr

---

From: Ned Freed <[email-masked]>
Date: Tue, 19 Jul 2005 16:16:19 -0700 (PDT)

> tried this with any clients to see how they behave.

I'm not suggesting that servers behave in any particular way, mostly because I
think any recommendation would be largely irrelevant.

My observation was and is that servers in practice leave the connection in an
unusable state. This means that the only viable behavior for a client is to
abandon the connection and either try again without TLS or give up.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 19 Jul 2005 16:22:28 -0700 (PDT)

> unbuffer the data. Sorry for not catching that when Id id my

That's an interesting observation - I hadn't thought of buffering being a
possible culprit. My experience is strictly as a TLS/SSL user, not as a TLS/SSL
developer.

			Ned

---

From: Ken Murchison <[email-masked]>
Date: Wed, 20 Jul 2005 00:48:37 -0400

> unbuffer the data. Sorry for not catching that when Id id my

No apologies nescessary, but I'm looking for guidance.  What you're both 
describing seems to be an implementation problem, not a design flaw in 
the protocol.  What do you suggest we do with NNTP that would differ 
from the other messaging protocols?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Jul 2005 06:32:05 -0700

Ken Murchison <[email-masked]> writes:
> No apologies nescessary, but I'm looking for guidance.  What you're
> both describing seems to be an implementation problem, not a design
> flaw in the protocol.  What do you suggest we do with NNTP that would
> differ from the other messaging protocols?

I'm not sure it's different. My memory was that noone actually tried
to resume after failed TLS negotiation and that if the protocol
specs suggested it they were widely ignored. :) Have I been away
too long? :)

-Ekr

---

From: Russ Allbery <[email-masked]>
Date: Wed, 20 Jul 2005 09:21:52 -0700

> I'm not sure it's different. My memory was that noone actually tried to
> resume after failed TLS negotiation and that if the protocol specs
> suggested it they were widely ignored. :) Have I been away too long? :)

I looked briefly yesterday and, at the least, the other protocols don't
have any examples showing resume after failure.  They do all allow the
server to fail STARTTLS immediately after the command, of course, but in a
quick perusal, I didn't see any provision for later failure other than the
statement that the client should close the connection.

I'll look again more thoroughly later today (if I can spring the free
time).

---

From: Ned Freed <[email-masked]>
Date: Thu, 21 Jul 2005 17:46:52 -0700 (PDT)

> specs suggested it they were widely ignored. :)

This corresponds exactly to my experience.

> Have I been away too long? :)

For that matter, it has been a couple of years since I tried this. Things
may have changed since then. OTOH, old implementations never seem to
die out completely.

				Ned

---

From: Russ Allbery <[email-masked]>
Date: Thu, 21 Jul 2005 18:35:34 -0700

>> Are there other STARTTLS specifications that allow this case?  I don't
>> remember off-hand if the TLS working group review addressed this point
>> in particular.

> that the session may continue even if the TLS negotiation failed.

I looked over RFC 2595 and didn't see any provision for a failed
negotiation one way or the other.  The only mention of a failure is
immediately in response to the command.

RFC 3207 talks about the client closing the connection (which we have) but
doesn't say anything else about failure.  The client closing the
connection is only a SHOULD, which implies that the connection could
continue, but then nothing is said about what happens then, whether
there's an error code, or the like.  I wouldn't be sure as an implementor
what to do if I didn't take the SHOULD option.

Given the subsequent discussion here, it sounds like it would be best to
just always close the connection on failure to negotiate TLS once the
negotiation has started.  I'm not sure that we buy anything by saying
anything else.