NNPS / TCP port 433

[Grant Taylor]

On 10/28/21 1:24 AM, Julien ÉLIE wrote:
> Hi Grant,

Hi Julien,

> And also a less known 532 port:
> netnews    - 532 - readnews
> 
> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=10 
> 
> Still reserved for Netnews, but no longer used nowadays (it used to by a 
> Microsoft reader client decades ago, but I have no more information).

O.o???

I searched IANA's DB for "NNTP" and came up with the three ports.  I'm 
sort of glad that netnews / readnews didn't come up because it sounds 
like more of a Microsoft proprietary thing than it does an open standard 
used by anything outside of the Microsoft ecosystem.  So, baring any 
encouragement to mess with it, I'm going to ignore as opposed to being 
ignorant of it.

But thank you for the pointer to it.  #TIL....

> Because it is more detailed in RFC 4642 (defining STARTTLS) which was 
> updated by RFC 8143 (discouraging STARTTLS, in benefit to implicit TLS 
> connections, amongst other things).

ACK

The powers that be ~> industry seems to keep waffling back and forth on 
explicit vs implicit port encryption.  As I understand it, it started 
with separate implicit ports (a port was either encrypted exclusive or 
not) because STARTTLS was not yet a thing.  Then it went to combined 
explicit ports (because you explicitly stated if you wanted encryption). 
  And now we seem to be going back to separate implicit ports in an 
attempt to avoid downgrade attacks on explicit ports.

I'll have to check out RFC 8143 to see what I'm missing.  Thank you for 
the pointer.

> That's right, as Russ answered earlier.

ACK

> Nonetheless, I have another question, now that implicit TLS is the 
> preferred way to use TLS.
> 
> - For news servers with both transit and reader facilities on the same 
> daemon, port 119 can be used unencrypted, and port 563 with TLS (even 
> for the transit facility by the way).

ACK

> Port 433 remains unencrypted for the transit facility, if a separate 
> port is needed.

I would expect that the NNSP port 433 could be explicit encrypted via 
STARTTLS much like NNTP port 119.

> - For mode-switching news servers like INN, port 119 can be used 
> unencrypted for transit and reader facilities, and port 563 with TLS for 
> reader.

ACK

> Port 433 remains unencrypted for the transit facility.

I'm not sure.  (See above comment.)

> And then the question is: what should be done for transit with implicit 
> TLS?

I'm of the mind that we as the NNTP using community make a server rule 
-- a la. "house rule" -- that the NNSP port 433 be implicitly TLS 
protected much like NNTPS port 563 is.  --  I say this because the 
current industry best practices are to use implicit encryption.  So if 
the NNSP port 433 is largely unused and we want to start making use of 
it, why not impose implicit encryption.

Have NNTP port 119 be legacy mixed use, NNSP port 433 be implicit 
encryption for server-to-server, and NNTPS port 563 be implicit 
encryption for client-to-server?

For the rest of this message, I'm assuming the following:

NNTP  - 119 - c2s / s2s - unencrypted or explicit encryption
NNSP  - 433 -       s2s - implicit encryption
NNTPS - 563 - c2s       - implicit encryption

Consider this a request for comments on the above proposal.

> We cannot run 2 innd instances (one for unencrypted connections, 
> another one for implicit TLS).

I'm not yet convinced that we need a 2nd instance of INN(d) running. 
Instead, I think that what I'm experimenting with in the NNTPS pointers 
thread could be used to provide the three ports listed above via one 
instance of INN(d).

> Wouldn't we need a 4th port for that?

I'm not convinced that we do need a 4th port.  Sure, one could be 
defined for uniformity.  But I think doing so would be questionable in 
these days of opportunistic encryption ~> encrypt everything possible.

> Or say port 433 is for implicit TLS for mode-switching servers?

As indicated above, I'm inclined to say that NNSP/433 uses implicit TLS 
protection.

> (But then, separating unencrypted transit and reader cannot be done.)

I'm content separating transit and reader at the client side; NNSP/433 
and NNTPS/563 respectively.  I don't see an actual /need/ to be able to 
have encrypted transport and reader on the same port.

On the off hand chance that I wanted encrypted transport & reader on the 
same port, I could leverage a different aspect of the NNTPS pointers 
thread to differentiate known transport peers from readers via remote IP 
addresses connecting to the local server.  Or said another way, assume 
that $PORT is mode reader by default and only transport for known remote 
IPs.

P.S.  Russ, thank you for your reply.  I rolled my responses to your 
message into this longer message.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20211028/a61e969a/attachment.bin>