« Fischer Black and external memories | Main | Physical advantages »
May 28, 2005
EKR's Comments on NNTP over TLS
Comments on draft-ietf-nntpext-tls-nntp (these comments are on the very similar -05 version, rather than the current -06 version):
To: IESG
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
comments:
S 2.2.2.1 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:
PKIX:
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
misconfiguration.
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
document.
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
like.
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
background
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
reasons.
-Ekr
UPDATE: You can find the discussion thread resulting from this comments here.
Posted by ekr at May 28, 2005 9:03 AM | Filed under:
Comments
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.
Posted by: Florian Weimer at May 28, 2005 11:20 AM
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.
http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf
Describes a serious perf problem with sftp... I wonder if it applies to scp as well...
Posted by: EKR at May 28, 2005 11:44 AM
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.
Posted by: Cullen Jennings at May 29, 2005 10:22 AM
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.
Posted by: Florian Weimer at May 29, 2005 11:02 AM