[NNTP] NNTP working group status

[Ken Murchison]

ned.freed at mrochek.com wrote:

>> ned.freed at mrochek.com wrote:
> 
> 
>> > I agree with this assessment, although I have yet to review the 
>> STARTTLS
>> > draft to see if it meets all of the newer things the security folks 
>> want
>> > out of TLS in more recent protocols.
> 
> 
>> Ned, do you have a reference to these "newer things" so I can get a jump
>> on them?
> 
> 
> 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?  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.

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.

Thanks,
Ken
-- 
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