EKR's Comments on NNTP over TLS

| Comments (4) | TrackBacks (9) |
Comments on draft-ietf-nntpext-tls-nntp (these comments are on the very similar -05 version, rather than the current -06 version):
Subject: Comments on draft-ietf-nntp-tls-nntp-05.txt
Cc: [Authors]
Date: Tue, 24 May 2005 08:22:57 -0700
From: EKR

I just reviewed draft-ietf-nntp-tls-nntp-05.txt. I see that it's
in Last Call Requested, so consider these some early LC

S reads:

     If the NNTP client decides that the level of authentication or
     privacy is not high enough for it to continue, it SHOULD issue a
     QUIT command immediately after the TLS negotiation is complete.  If
     the NNTP server decides that the level of authentication or privacy
     is not high enough for it to continue, it SHOULD either reject
     subsequent restricted NNTP commands from the client with a 483
     response code (possibly with a text string such as "Command refused
     due to lack of security"), or reject a command with a 400 response
     code (possibly with a text string such as "Connection closing due
     to lack of security") and close the connection.

I don't understand how this happens. TLS includes a negotiation mechanism.
Implementations shouldn't offer ciphersuites that they aren't willing to
accept when they complete. If you mean that you get a certificate
that you subsequently decide you don't like, that's a slightly 
different issue and I think deserves special discussion.

     o  The client MAY check that the identity presented in the server's
        certificate matches the intended server hostname or domain.
        This check is not required (and may fail in the absence of the
        TLS server_name extension [TLS-EXT], as described above), but if
        it is implemented and the match fails, the client SHOULD either
        request explicit user confirmation, or terminate the connection
        but allow the user to disable the check in the future.
     o  Generally an NNTP server would want to accept any verifiable
        certificate from a client, however authentication can be done
        using the client certificate (perhaps in combination with the
        SASL EXTERNAL mechanism [NNTP-AUTH], although an implementation
        supporting STARTTLS is not required to support SASL in general
        or that mechanism in particular).  The server MAY use
        information about the client certificate for identification of
        connections or posted articles (either in its logs or directly
        in posted articles).

I don't understand the underlying authentication model here. Roughly
speaking, there are two ways to use certificates:

    Certs are signed by some third-party CA. This is an attestation
    that the key in the cert corresponds to the named end-entity.
    If you're relying on the certificate in this way, then you
    must verify the peer identity or there's no point in verifying
    the cert at all, since any idiot can obtain one.

Key Carrier: 
    The certificate is unsigned and is just used as a way to carry
    the key. Variants of Key carrier include "fingerprint" where you
    check that the cert matches some externally exchanged fingerprint
    and leap-of-faith" where you check that the same cert is used
    every time. In all three of these environments, it doesn't make
    any real sense to verify the peer host name, except to detect

The text you have here doesn't seem to well match either model.

S 5:
     Both the NNTP client and server must check the result of the TLS
     negotiation to see whether an acceptable degree of authentication
     and privacy was achieved.  Ignoring this step completely
     invalidates using TLS for security.  The decision about whether
     acceptable authentication or privacy was achieved is made locally,
     is implementation-dependent, and is beyond the scope of this

As noted above, it's not really sensible to ask whether a sensible
level of privacy was achieved b/c that's inherent in TLS's 
handshake. The right question is about peer identity. As an implementation
note, most TLS stacks let you force the policy rules for peer
authentication into the handshake process, so you don't even
get to this stage if the peer's credentials aren't ok.

     The client and server should also be aware that the TLS protocol
     permits privacy and security capabilities to be renegotiated mid-
     connection (see section 7.4.1 of [TLS]).  For example, one of the
     parties may desire minimal encryption after any authentication
     steps have been performed.  This underscores the fact that security
     is not present simply because TLS has been negotiated; the nature
     of the established security layer must be considered.

Yes and no. 
     1. Peers *can* renegotiate, however, this very rarely happens
	because the semantics aren't well-defined. In particular,
	there are I/O deadlock issues unless you're fairly careful.

     2. Either peer can offer renegotiation, but the other peer
	can ignore the request. The consequences here are a little
	undefined (see above).

     3. Renegotiation can't be forced by any outsider.

     4. You can guarantee that your security properties can't 
	change by only offering/accepting the same ciphersuites
	post-renegotiation as before. This may result in a 
	connection loss, but not a failure. cf. My previous 
	comments about not TLS negotiating algorithms you don't

I wanted to note this sentence in particular:

     For example, one of the parties may desire minimal encryption after
     any authentication steps have been performed.

I hear this kind of thing a lot, usually for performance reasons.
Modern computers can encrypt at a truly tremendous rate. For

FreeBSD 5.3, P4, 3GHz,
RC4		123 MB/s
MD5		308 MB/s
SHA-1		115 MB/s
AES-128		 70 MB/s

So, in practice you can saturate a GigE line with SSL/TLS traffic without
too much effort. If we assume that you use the fastest algorithm: RC4/MD5,
you see a 4x performance improvement removing RC4. However, if you
are using SHA-1 (as is current recommended practice) you only get a
factor of 2, which isn't that impressive. I would generally avoid
encouraging WGs to advise people to turn off encryption for performance


UPDATE: You can find the discussion thread resulting from this comments here.

9 TrackBacks

Listed below are links to blogs that reference this entry: EKR's Comments on NNTP over TLS.

TrackBack URL for this entry: http://www.educatedguesswork.org/cgi-bin/mt/mt-tb.cgi/274

mercedes 280sl mercedes paint mercedes shocks mercedes benz s500 mercedes benz key chain mercedes g wagon mercedes bbw new mercedes mercedes 280s mercedes pictures side step bars mercedes ml mercedes benz clothing Read More

debt negotiation from debt negotiation on August 10, 2005 12:14 PM

debt negotiation Read More

cheap ticket from cheap ticket on August 12, 2005 2:54 PM

cheap ticket Read More

star tattoo from star tattoo on August 13, 2005 5:43 AM

star tattoo Read More

thailand Read More

Japanese girls hentai free from A short hentai animation free on October 22, 2005 10:40 PM

Tortured and raped girls Free lesbian forced sex pictures and vidios Anime tentacles sex Non consensual teen gan... Read More

cingular wireless from cingular wireless on December 8, 2005 12:03 AM

cingular wireless Read More


Are your performance numbers raw numbers, or actual numbers measured on TLS connections? (According to the theoretical numbers printed by "openssl speed", we should have reached Fast Ethernet wirespeed years ago, but curiously, scp at wirespeed is a relatively recent achievement.)

On the other hand, the justification for turning off encryption (it doesn't make sense to encrypt data which is publicly available on newsservers around the world) is increasingly unsound. A growing number of ISPs use network sniffers like CopySense which report infringement (or at least store non-anonymized data which only waits for being subpoenaed). Given that NNTP is often used to transfer copyrighted material which the copyright owner has not implicitly or explicitly opened up for redistribution, it's probably better not turn off encryption on these connections.

The numbers are from "openssl speed". However, I routinely get on the order of 200 Mb/s actual SSL with much wimpier machines than the ones I measured this on, so I don't think they're too far off.

It's true that scp is really slow. However, I'm not sure the problem there is crypto performance. Section 6.2 of this paper by Peter Gutmann.
Describes a serious perf problem with sftp... I wonder if it applies to scp as well...

Let's see, assuming 1Gbps network connection costs about $45,000 per month, remind me how much a 3Ghz intel processor costs and why this is relevant.

Cullen, the $45,000 per month figure is slightly exaggerated. It might the price of 1 Gbps Internet transit in some locations, but in typical MANs or even WANs tehe cost per gigabit is much, much lower.

Leave a comment