[Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT

[Chris Lonvick <[e-mail]>]

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.