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

[Sean Turner <[e-mail]>]

t.petch wrote:
> I see two separate issues here, trust anchor and mandatory encryption, and it is
> the latter I am absolutely against.  Just because someone, somewhere in the
> world may send confidential data in a syslog message does not mean the IETF must
> REQUIRE everyone, everywhere in the world to encrypt everything.  It's ......
> 
> The IESG had a go at SNMP over this but SNMP got its oar in decades ago by
> specifying that authnopriv(acy) was a part of SNMP, and so it has remained, as
> the mechanics of security have evolved.
> 
> If that is ok for SNMP, with all the important data it carries, I think it
> suitable for syslog ie NULL encryption is fine and we would be doing our users
> an injustice to deny them the option.
> 
> The argument based on our mention of disclosure as a threat in RFC5425 I find
> spurious; it means that encryption must be an option, not that everyone must use
> it all the time.
> 
> <mutter, mutter, mutter/>

Tom,

Ah see I'm not sure Tim was thinking along these line.  I suspect Tim 
is thinking is here's yet another protocol saying we're going to use 
TLS/DTLS and they're not saying anything about the interesting things 
that can happen with TLS/DTLS (e.g., negotiating NULL confidentiality 
algorithms).  If the WG isn't always using DTLS for confidentiality, 
then Section 4 needs to say that.  Maybe adding something like the 
following before the note:

However, confidentiality is not always required for syslog over DTLS 
because [insert reason here].

I think you'll need to add some text that says if confidentiality is 
required, the NULL cipher suites MUST NOT negotiate NULL encryption 
ciphers.

I'm hoping that we can keep the part about MUST NOT support NULL 
integrity and authentication algorithms in Section 5.3.  But, add a 
new last sentence that says something like:

When confidentiality is provided by [insert mechanism here], then NULL 
encryption algorithms MAY be negotiated.

spt

> ----- Original Message -----
> From: "Chris Lonvick" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, June 07, 2010 5:20 PM
> Subject: [Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT
> 
> 
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/syslog
> 
> _______________________________________________
> Syslog mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/syslog
>