XPost: news.software.nntp

Hi Dieter,

When transferring articles between two news servers, are some of you currently encrypting the connection?

If that is the case, I would be interested in knowing how you achieve that:
- what NNTP sofware (INN, Diablo, CodoSoft NNTPd...)
- by what means (stunnel, TCP wrappers, IPsec, native TLS support in the
news server...)
- on what port (119, 433, 563, another port?)
- do you have both unencrypted & encrypted connections with peers, or
only encrypted connections?
==================

I use port 119 to transfer articles - no encryption, but I have my
system configured to accept IPSec compression on the port. I note in my IPsec logs that none of my peers seem to take advantage of compression,
but they may be trying to negotiate authentication (AH) and encryption
(ESP), but I have those features turned OFF for feeds - being that I
consider such posts as already "in the public domain" because they are readable elsewhere. [Or at least I think I have it set up that way.]

My reader port, 563, has TLS enabled via INN's nnrpd program. At the
IPSec level, it could be compressed if negotiated.

Thanks for your input on that subject.
The question behind was whether registering a special port for transit
using strict TLS (NNSP/TLS) would be useful.
We currently have ports 119 (NNTP), 433 (NNSP) and 563 (NNTP/TLS) but no
port for NNSP/TLS.
I believe such a use is rare, if it exists at all.


FYI, the following update to RFC 4642 (STARTTLS) is currently in Last
Call for comments. So if you have any suggestion, feel free to tell.
https://www.ietf.org/id/draft-elie-nntp-tls-recommendations-01.txt



The response to the third issue to address (Appendix E) would therefore
be to use the following wording in Appendix A:

The third and fourth paragraphs in Section 1 of [RFC4642] are
replaced with the following text:

TCP port 563 is dedicated to NNTP over TLS, and registered in the
IANA Service Name and Transport Protocol Port Number Registry for
that usage. NNTP implementations using TCP port 563 begin the TLS
negotiation immediately upon connection and then continue with the
initial steps of an NNTP session. This use of strict TLS on a
separate port is the preferred way of using TLS with NNTP.

If a host wishes to offer separate servers for transit and reading
clients, TCP port 563 SHOULD be used for strict TLS with the reading
server, and an unused port of its choice different than TCP port 433
SHOULD be used for strict TLS with the transit server. The ports
used for strict TLS should be clearly communicated to the clients,
and specifically that no plain-text communication occurs before the
TLS session is negotiated.

--
Julien ÉLIE

« – Poussez pas derrière !
– Pas si vite devant ! » (Astérix)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: news.software.nntp

"Julien ÉLIE" wrote in message news:o2n2up$emm$1@news.trigofacile.com...

When transferring articles between two news servers, are some of you currently encrypting the connection?

If that is the case, I would be interested in knowing how you achieve
that:
- what NNTP sofware (INN, Diablo, CodoSoft NNTPd...)
- by what means (stunnel, TCP wrappers, IPsec, native TLS support in the
news server...)
- on what port (119, 433, 563, another port?)
- do you have both unencrypted & encrypted connections with peers, or
only encrypted connections?
==================

I use port 119 to transfer articles - no encryption, but I have my
system configured to accept IPSec compression on the port. I note in my IPsec logs that none of my peers seem to take advantage of compression,
but they may be trying to negotiate authentication (AH) and encryption
(ESP), but I have those features turned OFF for feeds - being that I
consider such posts as already "in the public domain" because they are readable elsewhere. [Or at least I think I have it set up that way.]

My reader port, 563, has TLS enabled via INN's nnrpd program. At the
IPSec level, it could be compressed if negotiated.

Thanks for your input on that subject.
The question behind was whether registering a special port for transit
using strict TLS (NNSP/TLS) would be useful.
We currently have ports 119 (NNTP), 433 (NNSP) and 563 (NNTP/TLS) but no
port for NNSP/TLS.
I believe such a use is rare, if it exists at all.


FYI, the following update to RFC 4642 (STARTTLS) is currently in Last
Call for comments. So if you have any suggestion, feel free to tell.
https://www.ietf.org/id/draft-elie-nntp-tls-recommendations-01.txt



The response to the third issue to address (Appendix E) would therefore
be to use the following wording in Appendix A:

The third and fourth paragraphs in Section 1 of [RFC4642] are
replaced with the following text:

TCP port 563 is dedicated to NNTP over TLS, and registered in the
IANA Service Name and Transport Protocol Port Number Registry for
that usage. NNTP implementations using TCP port 563 begin the TLS
negotiation immediately upon connection and then continue with the
initial steps of an NNTP session. This use of strict TLS on a
separate port is the preferred way of using TLS with NNTP.

If a host wishes to offer separate servers for transit and reading
clients, TCP port 563 SHOULD be used for strict TLS with the reading
server, and an unused port of its choice different than TCP port 433
SHOULD be used for strict TLS with the transit server. The ports
used for strict TLS should be clearly communicated to the clients,
and specifically that no plain-text communication occurs before the
TLS session is negotiated.

============

Using INN, I've seen only one peer that even requested port 433 for NNSP (peer-to-peer) transfer. All the others use 119. Therefore, I agree that there should not be a dedicated port for NNSPS. However, I see nothing that would forbid two peers from agreeing to use TLS over their existing NNSP connection. However, is it necessary?

TLS over NNTP (port 563) is necessary because it is client-to-server operations. Clients may not want snoopers to know what they've read, and
for postings, since some places operate anonymously, what they've posted. However, peer-to-peer communications are likely to be public postings distributed worldwide (by default) which anyone can read, so do they really need protection? If inter-server communications need protection, there's always IPSec.

The one peer I have that uses port 433 is in China. Maybe that's needed to
get around their Great Firewall.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: news.software.nntp

Hi Dieter,

TCP port 563 is dedicated to NNTP over TLS, and registered in the
IANA Service Name and Transport Protocol Port Number Registry for
that usage. NNTP implementations using TCP port 563 begin the TLS
negotiation immediately upon connection and then continue with the
initial steps of an NNTP session. This use of strict TLS on a
separate port is the preferred way of using TLS with NNTP.

If a host wishes to offer separate servers for transit and reading
clients, TCP port 563 SHOULD be used for strict TLS with the reading
server, and an unused port of its choice different than TCP port 433
SHOULD be used for strict TLS with the transit server. The ports
used for strict TLS should be clearly communicated to the clients,
and specifically that no plain-text communication occurs before the
TLS session is negotiated.

============

Using INN, I've seen only one peer that even requested port 433 for NNSP (peer-to-peer) transfer. All the others use 119. Therefore, I agree
that there should not be a dedicated port for NNSPS. However, I see
nothing that would forbid two peers from agreeing to use TLS over their existing NNSP connection. However, is it necessary?

Indeed, nothing forbids two peers from using TLS over their existing
NNSP connection. They can use STARTTLS on port 433 and therefore
dynamically upgrade from unencrypted to TLS-protected traffic.
If they use strict TLS, the recommendation is not to re-use port 433 for
that. They may, but should not.

However, peer-to-peer communications are likely to be public
postings distributed worldwide (by default) which anyone can read, so do
they really need protection? If inter-server communications need
protection, there's always IPSec.

Though not frequent, two peers may also authenticate themselves (using AUTHINFO). Protecting their credentials with TLS is useful in that
case. I otherwise agree that encrypting public articles is worthless.

--
Julien ÉLIE

« – Poussez pas derrière !
– Pas si vite devant ! » (Astérix)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: news.software.nntp

On Tue, 13 Dec 2016 22:37:56 +0100, Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> wrote:

However, peer-to-peer communications are likely to be public
postings distributed worldwide (by default) which anyone can read, so do
they really need protection? If inter-server communications need
protection, there's always IPSec.

Though not frequent, two peers may also authenticate themselves (using AUTHINFO). Protecting their credentials with TLS is useful in that
case. I otherwise agree that encrypting public articles is worthless.

I do not agree that encrypting public articles is worthless.

For example, the reason for encrypting public articles can be privacy (which some people deem important) - they might not want third parties to know
exactly which articles are they retreiving (which is the same reason why
they might want to use HTTPS for accessing Wikipedia or search engine, for example).

Other reason might be that the more of the global traffic is encrypted the better - the less suspicios (and thus likely to be targeted by goverment agencies) would any person be JUST BECAUSE they are using encryption.
(If only 0.01% of global internet traffic is encrypted, everyone using it
will be suspected. However if 70% of global traffic is encrypted, it is so common so everyone can use encryption without fear of his/her life being
made hard just because they value their privacy)

--
Opinions above are GNU-copylefted.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: news.software.nntp

Hi Matija,

Though not frequent, two peers may also authenticate themselves (using
AUTHINFO). Protecting their credentials with TLS is useful in that
case. I otherwise agree that encrypting public articles is worthless.

I do not agree that encrypting public articles is worthless.

For example, the reason for encrypting public articles can be privacy (which some people deem important) - they might not want third parties to know exactly which articles are they retreiving (which is the same reason why
they might want to use HTTPS for accessing Wikipedia or search engine, for example).

Other reason might be that the more of the global traffic is encrypted the better - the less suspicios (and thus likely to be targeted by goverment agencies) would any person be JUST BECAUSE they are using encryption.
(If only 0.01% of global internet traffic is encrypted, everyone using it will be suspected. However if 70% of global traffic is encrypted, it is so common so everyone can use encryption without fear of his/her life being
made hard just because they value their privacy)

I understand your point.

Note that the draft proposal does not say that encrypting is worthless,
but instead references RFC 7258 "Pervasive Monitoring Is an Attack" <https://tools.ietf.org/html/rfc7258> and states that "even an encrypted
but unauthenticated connection might be better than an unencrypted
connection".
I hope it suits you.

--
Julien ÉLIE

« Chaque fois que je vois le nombre 1, j'ai envie de l'aider à
s'échapper… Il a constamment à ses trousses, derrière, le zéro
qui veut le rattraper et devant, toute la mafia des grands nombres qui
le guettent. » (Romain Gary)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: news.software.nntp

On Mon, 19 Dec 2016 22:47:53 +0100, Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> wrote:

Though not frequent, two peers may also authenticate themselves (using
AUTHINFO). Protecting their credentials with TLS is useful in that
case. I otherwise agree that encrypting public articles is worthless.

I do not agree that encrypting public articles is worthless.

I understand your point.

Note that the draft proposal does not say that encrypting is worthless,
but instead references RFC 7258 "Pervasive Monitoring Is an Attack" <https://tools.ietf.org/html/rfc7258> and states that "even an encrypted
but unauthenticated connection might be better than an unencrypted connection".
I hope it suits you.

Ah, that is good - indeed it does reference it. I was commenting just
on the news post, not the draft at https://tools.ietf.org/html/draft-elie-nntp-tls-recommendations-01
(to which I sadly didn't yet have time to give my full attention)

on a semi-quick read of draft, in section 2.4, the wording in parentheses
seems unclear to me in "Be warned if a given server stops advertising the STARTTLS capability label in response to the CAPABILITIES command (of course when a security layer is not already in place) whereas it advertised the STARTTLS capability label during the previous connection."

I think its intent is to indicate that CAPABILITIES should be issued before STARTTLS commands, but the wording is confusing (to me, at least).

Also, in section 3, "CERT vulnerability ID #555316" maybe should have a reference?

--
Opinions above are GNU-copylefted.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: news.software.nntp

Hi Matija,

on a semi-quick read of draft, in section 2.4, the wording in parentheses seems unclear to me in "Be warned if a given server stops advertising the STARTTLS capability label in response to the CAPABILITIES command (of course when a security layer is not already in place) whereas it advertised the STARTTLS capability label during the previous connection."

I think its intent is to indicate that CAPABILITIES should be issued before STARTTLS commands, but the wording is confusing (to me, at least).

The intent is to prevent "SSL stripping" (Section 2.1 of RFC 7457), not
to send CAPABILITIES (that should anyway be sent by clients when they
connect).
Note that I reworded the paragraph in the -02 version, to take into
account a remark from the security directorate during Last Call:

https://tools.ietf.org/html/draft-elie-nntp-tls-recommendations-02

o When a security layer is not already in place, be warned if a
given server stops advertising the STARTTLS capability label in
response to the CAPABILITIES command (Section 2.1 of [RFC4642])
whereas it advertised the STARTTLS capability label during any
previous connection within a (possibly configurable) time frame.
(Otherwise, a human might not see the warning the first time, and
the warning would disappear immediately after that.)


Maybe I should add an explicit reference to "SSL stripping". I'll do
that in the next revised version of the document.
Thanks for your remark!

Also, in section 3, "CERT vulnerability ID #555316" maybe should have a reference?

It now points to RFC 7547 (that defines CVE stuff):

NNTP servers need ensure that they are not vulnerable to the STARTTLS
command injection vulnerability (Section 2.2 of [RFC7457]).

--
Julien ÉLIE

« J'ai le pied gauche qui est jaloux du pied droit. Quand j'avance le
pied droit, le pied gauche, qui ne veut pas rester en arrière…
passe devant… le pied droit en fait autant… et moi… comme un
imbécile… je marche. » (Raymond Devos)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)