Issue 9 - Tim Polk COMMENT
Comment:
Given that disclosure is one of the primary threats described in Section
4, shouldn't the security considerations prohibit the use of cipher suites
with NULL encryption?
Prpposed resolution by Sean:
vvv
A.5 of RFC 5246, which is where the cipher suites for both TLS and
DTLS end up pointing and is included in this I-Ds security
considerations, includes the following:
TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
TLS connection during the first handshake on that channel, but MUST
NOT be negotiated, as it provides no more protection than an
unsecured connection.
I could see how this might be worth repeating, but waned to make you
aware it was in RFC 5246.
^^^
Tim responded:
vvv
Thanks for pointing out that text; that is helpful but not sufficient,
though. I am actually worried about cipher suites that have
authenticatio=
n
& integrity but NULL encryption as well. There are a bunch of those:
CipherSuite TLS_RSA_WITH_NULL_MD5 =3D { 0x00,0x01 };
CipherSuite TLS_RSA_WITH_NULL_SHA =3D { 0x00,0x02 };
CipherSuite TLS_RSA_WITH_NULL_SHA256 =3D { 0x00,0x3B };
0x00,0x2C TLS_PSK_WITH_NULL_SHA [RFC4785]
0x00,0x2D TLS_DHE_PSK_WITH_NULL_SHA [RFC4785]
0x00,0x2E TLS_RSA_PSK_WITH_NULL_SHA
0xC0,0x06 TLS_ECDHE_ECDSA_WITH_NULL_SHA [RFC4492]
...among others.
(Pardon the formatting, pulled some from 5246 and others from the iana
registry...)
^^^
Sean responsed:
vvv
Ah! I see your point now. How about we tweak the last paragraph in
section 5.3 (obviously I'd like author input on this):
OLD:
Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the
mandatory to implement cipher suite, which is
TLS_RSA_WITH_AES_128_CBC_SHA.
NEW:
Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a
minimum support the mandatory to implement cipher suite, which is
TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are
supported, then implementations MUST NOT negotiate a cipher suite
that employs NULL encryption, integrity, or authentication
algorithms.
^^^
Sean's proposed resolution:
vvv
#3) Tim's point about restricting NULL cipher suites. At the end of
section 5.3:
OLD:
Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the
mandatory to implement cipher suite, which is
TLS_RSA_WITH_AES_128_CBC_SHA.
NEW:
Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a
minimum support the mandatory to implement cipher suite, which is
TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are
supported, then implementations MUST NOT negotiate a cipher suite
that employs NULL encryption, integrity, or authentication
algorithms.
^^^
Tom Petch responded:
vvv
I disagree. The threat of disclosure comes from RFC5425 s2
"Some data in syslog messages is sensitive and may be
useful to an attacker, such as the password of an authorized
administrator or user."
but the fact that someone, somewhere may put a password in a syslog
message I do not see as grounds for requiring everyone else in the world
to encrypt everything. Encryption is a pain, it costs, and we should not
require it
unless it can be justified; these are remote, low-powered network boxes
we are talking about, not enterprise servers.
So while I agree we should require authentication, I see no
justification for encryption.
^^^
Action: I'd like to get some additional discussion going on this.
==============================================
issue 9A -
Sean also suggested this:
vvv
#3) Tim's point about restricting NULL cipher suites. At the end of
section 5.3:
OLD:
Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the
mandatory to implement cipher suite, which is
TLS_RSA_WITH_AES_128_CBC_SHA.
NEW:
Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a
minimum support the mandatory to implement cipher suite, which is
TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are
supported, then implementations MUST NOT negotiate a cipher suite
that employs NULL encryption, integrity, or authentication
algorithms.
^^^
ACTION: Waiting on discussion for Issue 9.
===============================================
Issue 9B -
Sean also suggests:
#6) Section 9. Tim pointed out that because this I-D relies on
self-signed certificates it needs to say something about certificates
(I looked in DTLS/TLS and they don't point to 5280), keeping the
private key private, generating good random #s, and taking care when
installing trust anchors. Most of this is in RFC 5280 so if we add it
to the first line of the security considerations we're good except for
the make a good private key and installing the trust anchor.
Suggested text below:
OLD:
The security considerations in [RFC5425], [RFC5246] and [RFC4347]
apply to this document.
NEW (yes I reordered them so Alfred won't complain later):
The security considerations in [RFC4347], [RFC5246], [RFC5425], and
[RFC5280] apply to this document.
and we should add two new paragraphs:
9.2 Private Key Generation
Transport receiver and transport sender implementations
generate their own key pairs. An inadequate random number
generator (RNG) or an inadequate pseudo-random number generator
(PRNG) to generate these keys can result in little or no security.
See [RFC4086] for random number generation guidance.
9.3 Trust Anchor Installation and Storage
Trust anchor installation and storage is critical. Transmission of
a trust anchor, especially self-signed certificates used as trust
anchors, from transport receiver to transport sender for
installation requires an out-of-band step(s). Care must be taken to
ensure the installed trust anchor is in fact the correct trust
anchor. The fingerprint mechanism in Section 5.3.1 can be
used by the transport sender to ensure the transport receiver's
self-signed certificate is properly installed. Trust anchor
information must be securely stored. Changes to trust anchor
information can cause acceptance of certificates that should
be rejected.
ACTION: I'm also going to ask for more discussion on this.
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
