[NNTP] NNTP working group status

[ned.freed at mrochek.com]

> > They came up in the MSGTRK group and ended up in RFC 3887. Basically what was
> > called for was a parameter on STARTTLS specifying the domain name of the server
> > the client believes it is talking to. In the words of RFC 3887:

> >   The parameter MUST be a fully qualified domain name (FQDN).  A client
> >   MUST specify the hostname it believes it is speaking with so that the
> >   server may respond with the proper TLS certificate.  This is useful
> >   for virtual servers that provide message tracking for multiple
> >   domains (i.e., virtual hosting).

> Doh!  My co-author originally had such a parameter for NNTP STARTTLS,
> but I told him that it was unnecessary given the "Server Name
> Indication" TLS extension (RFC 3546, section 3.1).  We mention
> implementation of this as a SHOULD in the draft.  Is this not
> sufficient?

I honestly don't know.

> It seems to make more sense to me to handle TLS specific
> stuff within TLS itself, but I could be wrong.  I'm curious why MSGTRK
> was forced to do this at the application level rather than within TLS.

I agree. I don't recall a justification being given for MSGTRK doing it
this way.

> One problem with the wording in RFC 3887 as far as NNTP is concerned is
> that there already is existing deployment of STARTTLS without such an
> argument.  At the very least, if we add a domain argument to STARTTLS it
> would probably have to be optional for backwards compatibility.

> I realize you're probably busy at IETF, but would you be able to query a
> couple of security guys on this and let me know if we are going to have
> to change the doc?  I'd prefer to do it before we send it off to IESG
> and ultimiately have it bounced.

I agree, however, since I'm not in DC someone else will have to do it.
Any volunteers? If memory serves the pushback on this in MSGTRK came
from Eric Rescorla so you might try him.

				Ned