Re: IDS> Min_Cipher_Suite and Min_Cipher_Key_Length attributes

From: Randy Turner (rturner@amalfisystems.com)
Date: Sun Feb 01 2009 - 19:16:19 EST

  • Next message: Ira McDonald: "Re: IDS> Min_Cipher_Suite and Min_Cipher_Key_Length attributes"

    Scratch my comment about IKE (and IPSEC) below, as RFC 4308 seems to
    suggest that IKE(and V2) use a multi-valued negotiation type which
    indicates more than just encryption strength....

    R.

    On Feb 1, 2009, at 2:06 PM, Randy Turner wrote:

    >
    > The "model" that we've discussed in the past is having a "scale" of
    > cryptographic protection, from weak to strong.
    > And based on the model, I think the idea of these attributes was to
    > be able to specify a "minimum" cryptographic
    > requirement for the device.
    >
    > The "model" that was originally referenced was that using SSL/TLS,
    > and the corresponding TLS/SSL IANA enumerations.
    >
    > If we're going to stick to the SSL/TLS enumerations, then the
    > minimum key-size wouldn't be needed because they offer no
    > benefit to implementers - TLS/SSL only negotiates based on the
    > enumerations and not a separate parameter called "key length". I
    > believe
    > (don't quote me on this) that IKE does the same thing when
    > negotiating IPSEC security associations.
    >
    > If we're going to just have a "minimum" key length for encryption,
    > then you wouldn't need to reference the enumerations.
    >
    > I think there are 4 alternatives:
    >
    > 1. Just use a minimum key length, and we don't worry about a
    > particular "model" for levels of encryption, such as SSL/TLS
    >
    > 2. Just use the enumerations from the TLS/SSL IANA registry, and
    > dump the minimum key length.
    >
    > 3. Dump both and move on
    >
    > 4. Come up with a new proposal based on another set of enumerations
    > describing cryptographic algorithms
    >
    > My preference would be 2 or 3, since the guidance and direction for
    > implementers is very straightforward and unambiguous (being an
    > OpenSSL implementer myself)
    >
    > Randy
    >
    >
    > On Feb 1, 2009, at 10:52 AM, Ira McDonald wrote:
    >
    >> Hi,
    >>
    >> Just my two cents, but, I'd urge that either:
    >>
    >> (1) Both attributes stay REQUIRED; or
    >> (2) Both attributes are deleted entirely from IDS.
    >>
    >> Having said that, the FIRST principal of security
    >> audits is that EVERY network protocol has to be
    >> secured on a device and the weakest security
    >> configured for any of those network protocols is
    >> the security rating of the entire device.
    >>
    >> Secure devices do NOT send or receive unsecured
    >> email over SMTP (for example).
    >>
    >> MFDs shouldn't claim to be secure if they aren't.
    >>
    >> Cheers,
    >> - Ira
    >>
    >> Ira McDonald (Musician / Software Architect)
    >> Chair - Linux Foundation Open Printing WG
    >> Blue Roof Music/High North Inc
    >> email: blueroofmusic@gmail.com
    >> winter:
    >> 579 Park Place Saline, MI 48176
    >> 734-944-0094
    >> summer:
    >> PO Box 221 Grand Marais, MI 49839
    >> 906-494-2434
    >>
    >>
    >>
    >> On Sat, Jan 31, 2009 at 7:08 PM, Randy Turner <rturner@amalfisystems.com
    >> > wrote:
    >>>
    >>> I think so....when you actually code TLS connections using
    >>> OpenSSL, you can
    >>> specify a minimum cipher suite to be negotiated...only the cipher
    >>> suite
    >>> enumeration is specified, so I think it's ok to use just the
    >>> enumerations.
    >>> R.
    >>> On Jan 31, 2009, at 4:03 PM, Brian Smithson wrote:
    >>>
    >>> Thanks, Randy.
    >>>
    >>> So is our key length attribute redundant?
    >>>
    >>> --
    >>> Regards,
    >>> Brian Smithson
    >>> PM, Security Research
    >>> PMP, CISSP, CISA, ISO 27000 PA
    >>> Advanced Imaging and Network Technologies
    >>> Ricoh Americas Corporation
    >>> (408)346-4435
    >>>
    >>> Randy Turner wrote:
    >>>
    >>> Hi Brian,
    >>> I think the IANA registry actually has the key length specified as
    >>> part of
    >>> the suite enumeration.
    >>> Examples are:
    >>> TLS_RSA_WITH_AES_128_CBC_SHA256
    >>> TLS_RSA_WITH_AES_256_CBC_SHA256
    >>> There are other suites that don't specify numeric key sizes, but
    >>> in these
    >>> cases, the algorithm itself
    >>> (3DES for example) work with a specific key size that doesn't vary.
    >>> In this case, we may be able to just specify that we're talking
    >>> about a
    >>> minimum suite, with a reference to RFC 5246 and
    >>> the IANA registry itself.
    >>> Randy
    >>>
    >>> On Jan 30, 2009, at 6:26 PM, Brian Smithson wrote:
    >>>
    >>> I am still wondering how these two attributes can be used in
    >>> practice. I
    >>> know that we can uniquely identify cipher suites using the IANA
    >>> registry, but is there an authoritative source to specify that one
    >>> suite
    >>> is "more minimum" than another? And if you consider different key
    >>> lengths that might be acceptable for a given suite, then can we
    >>> really
    >>> say that suite X is more minimum than suite Y even if an HCD
    >>> supports a
    >>> relatively long key length for X but only supports a relatively
    >>> short
    >>> one for Y?
    >>>
    >>> --
    >>> Regards,
    >>> Brian Smithson
    >>> PM, Security Research
    >>> PMP, CISSP, CISA, ISO 27000 PA
    >>> Advanced Imaging and Network Technologies
    >>> Ricoh Americas Corporation
    >>> (408)346-4435
    >>>
    >>>
    >>>
    >>>
    >>>
    >>
    >



    This archive was generated by hypermail 2.1.4 : Sun Feb 01 2009 - 19:16:26 EST