Re: LYNX-DEV problem with 'news' url draft

David Woolley wrote:
> 
> >
> > Are snews URLs used?  Is news+ssl offered with any regularity?
> > Is port 563 generally used for this?
> 
> My understanding is that it was invented by Netscape at the same time
> as https and that they use it for their support newsgroups, although
> I don't know to what extent they do this for lock in/demonstration reasons
> and to what extent to protect the information from non-paying customers.

It's for demonstration purposes. We're not using NNTP over SSL to
authenticate users using their certificate, but merely to encrypt the
traffic between client and server. There are password-protected groups
on secnews.netscape.com, but those use NNTP's normal AUTHINFO command.

> My impression from various things I've seen on USENET is that quite
> a lot of commercial users of their products have started using it
> as well, although I'm not sure if that is for closed, external services,
> or for internal company services.  I think you can assume that Netscape
> have been trying to create this market, although their original
> competitive edge will have been considerably blunted by time.
> 
> My impression is that it is generally used in a context where snntp would
> have been a more appropriate URL name, 

If snntp were adopted as a standard URL scheme we would adopt that in
about two minutes. I'm not sure why anyone would dislike snews as a name
(although I understand why having a separate port would not be the
preferred mechanism if NNTP/SSL were being invented in 1998).

> but Netscape destroyed the distinction
> between nntp and new and I think that has now been officially sanctioned.

I don't understand what distinction we destroyed. Would you care to say
more about that?

> There may be some ISPs offering it to give customers a false sense that
> their newsreading habits are kept private.

Certainly no one's newsreading habits are kept private using NNTP/SSL. I
have not heard any Netscape users express that misconception.

We promote SSL-enabled protocols as a way to prevent attacks on
communications across an insecure channel. For example, companies using
internal newsgroups can allow authenticated access from outside the
firewall without exposing either plaintext passwords or message
contents. While plaintext passwords can be avoided in other ways, it's
our experience that not everyone is chomping at the bit to deploy
Kerberos or public key certificate infrastructure.

> > Should this be discouraged?  Actively or passively, by failing to
> > bless this usage with a Proposed Standard?
> 
> I doubt that a standard will have much influence in this market area.
> SSL is much more of a marketing phenomena than a technical one; my
> impression is that the traditional users of secure communications could
> have implemented it a long time ago, but didn't for reasons that haven't
> changed, and may even have gone against it, namely a distrust in the
> security of software implementations.
>
> Incidentally from the port space pollution point of view, I think you will
> find that the nature of SSL is such that it requires a doubling of the
> number of privileged ports.  You can't just autodetect it on the standard
> port, because the nature of the thing is such that it is very likely that
> people will want to permit it across a firewall, but not the raw protocol.
> You could define an SSL multiplexor port, with the sub-protocol carried in
> the data; it is even possible that this is in the latest version, however,
> again there may be a demand to discriminate at firewalls.

There is, as Keith Moore suggested, a trend towards negotiating TLS
using the protocol itself. An implementation has been suggested for SMTP
in draft-hoffman-smtp-ssl-05.txt. While our NNTP/SSL support predates
this trend, it seems to me that TLS can be autodetected and does not, in
general, require more ports to pass through the firewall. This requires
additional syntax in each protocol, and maybe the NNTPEXT group will
consider that for NNTP.

-- Phil.

--
Phil Peterson
Netscape mail/news client engineering

Received on Saturday, 7 March 1998 14:27:09 UTC