[ietf-nntp] draft-ietf-nntpext-tls-nntp-01.txt

[Ken Murchison]

Russ Allbery wrote:

> Clive D W Feather <clive at demon.net> writes:
 >
>>Section 2: it's not clear from this document why STARTTLS is forbidden
>>after a successful authentication has been organised.
> 
> 
> This is the way that STARTTLS is specified for other protocols.  I'm
> curious too why this is, and would love to hear more details, but I think
> it's important that we leave this in place.  We're trying to copy as
> closely as possible how STARTTLS has been successfully deployed elsewhere.
> 
> I'm guessing it's related to the fact that authentication before STARTTLS
> is pointless since it just has to be done again.

I believe its done this way in other protocols because SSL/TLS is mostly 
used to protect the authentication credentials, not the actual message 
data.  I don't think there isn't any technical reason why STARTTLS 
couldn't be done after authentication, but since most (if not all) 
applications are accustomed to having any SASL security layer nested 
*inside* of a SSL/TLS layer, allowing STARTTLS after authentication 
would break this paradigm.  This is also the same reason why most 
protocols don't allow reauthentication via SASL (handling of multiple 
security layers).

If the argument for allowing STARTTLS after authentication is because a 
server may require protection of private groups (after the client has 
been accessing unprotected public groups), then my answer would be that 
the client can just start another connection using TLS to access the 
private groups.  The other alternatives are to use STARTTLS initially if 
the client wishes to access private groups at some point during the 
session, or to authenticate with a SASL mechanism which provides a 
security layer (e.g. DIGEST-MD5).

-- 
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