Re: [TLS] Deprecating more (DSA?)
Alyssa Rowan <akr@akr.io> Wed, 16 April 2014 22:36 UTC
Return-Path: <akr@akr.io>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF931A03CA for <tls@ietfa.amsl.com>; Wed, 16 Apr 2014 15:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.998
X-Spam-Level: **
X-Spam-Status: No, score=2.998 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_24=0.6, J_CHICKENPOX_35=0.6, MANGLED_BACK=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnTf8RWidF0W for <tls@ietfa.amsl.com>; Wed, 16 Apr 2014 15:36:14 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id F1A071A03C1 for <tls@ietf.org>; Wed, 16 Apr 2014 15:36:13 -0700 (PDT)
Message-ID: <534F05DD.5010906@akr.io>
Date: Wed, 16 Apr 2014 23:36:13 +0100
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: tls@ietf.org
References: <CABcZeBOvxL7Zws0UNowViBWGaVBgfm3zXt8=dNPKffGfN3q2gA@mail.gmail.com> <20140415153435.7f82b3a0@hboeck.de>
In-Reply-To: <20140415153435.7f82b3a0@hboeck.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/amdgCjyFdxsylaj6JYMbF9SLHPU
Subject: Re: [TLS] Deprecating more (DSA?)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Apr 2014 22:36:15 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It looks like RC4 is rapidly heading for the chopping block, with basically unanimous consensus. Good. In the meantime... On 15/04/2014 14:34, Hanno Böck wrote: > What other algorithms exist in the TLS spec that should see > deprecation? […] E.g. what about deprecating DSA? I actually favour, for reasons of complexity and weakness, potentially deprecating pretty much everything that falls in the following lists, if of course it isn't already deprecated, subject to discussion: • Anything with NULL anything - An accident waiting to happen (on purpose). • Anything EXPORT - Bad old days. Kill them with fire. TLSv1.1 deprecated them but didn't forbid them in TLSv1.0; if they're not already a MUST NOT somewhere, I think they should be. • DES is already deprecated. [RFC5469] - What about 3DES now? • IDEA's already deprecated. [RFC5469] - Little traction in the wild, due to the (now-expired) patents. • Anything using MD5 - Collided. Kill it off. I'd feel highly uncomfortable keeping this around. • Anything using DSS/DSA certs - The Nonce Problem. RFC 6979 fixes this, but... - A live DSA certificate, now, in 2014, that isn't ECDSA? Really? ¬_¬ • ECDSA without RFC6979? - Because of The Nonce Problem. - Remember to avoid timing attacks in RFC6979. - I don't know where that stands regarding FIPS-compliance, for those that need it: but as far as I'm concerned, if FIPS is incompatible with RFC6979, FIPS needs fixing because it's encouraging extremely fragile implementations. - ECDSA makes me uneasy now. It shares DSA's characteristics of being fragile as hell. I can't help but worry it was intentionally designed that way. - We will need a new scheme soon; EdDSA or a very similar Schnorr-style derivative? I'd like EdDSA swapping SHA-256 for SHA-3, perhaps? A discussion for the future (and/or CFRG, etc). • Anything using SHA-1? - Already deprecated by NIST, and by CAs and vendors in certificates due to ~2^61 being expensive but practical. - An attack is harder in a MAC scenario - but it's only a matter of time; it's downhill all the way from here. - Thoughts? - Forbid negotiation in TLSv1.3, maybe, but allow in TLSv1.2 and down? • DH_anon? - Subject to thoughts about possible opportunistic encryption, although this definitely isn't the way you _want_ to do that. • Do we really want to keep DH|ECDH as opposed to DHE|ECDHE? Why? • RSA without forward security - Seems like we're heading broadly in the direction of requiring forward-security, which means deprecating plain old RSA in TLSv1.3 negotiations? Thoughts? • DHE - Given the complexities noted surrounding DHE parameters and lack of ability to negotiate them, would we be better off dropping conventional DHE for TLSv1.3? - Favour ECDHE over secp256r1 and/or Curve25519 (where the latter is not forbidden by FIPS-compliance, with 25519 being preference) as baseline instead? I do realise that's a strongly aggressive proposed unused-feature or not-best-practice cull, largely for reasons of complexity reduction. Perhaps others will be able to moderate my opinions. :-) - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTTwXdAAoJEOyEjtkWi2t6fGkP/3C1+/o7QOSU2Gu0wdiYnsZ7 6zKCszf954w0mYIugZdwkKI6ZxlgjcybWz9ZFRPoXaf9XFlJgFRK+YysgmGFlmmO qJNsv/ur14JSWMClUuD/BH5EKpDlY9jOAFt44k6RIf8dZN7B1CO9yhjUMnlwdh8J MZuGLywu7She9JfIbhcBGVfXMYlExy7nI857K7YkbAu0LZdWNNV3Ut0VEYBq2feB tyMuuSq3Jdv00A52PfMjT5INEAHZGOH3yKbaY0yPY7HDhpcMGjD1YmeVN++wHD8X 1jOlxS6wWWP59ifRmsLIRH7oZvCGXs4oM0RO0T22Ou2424g73Uwccmqhc9jDebdz 0E/srZ3W4gan4kkvBgNwAEBxiQ/rxg0Haab6vnvusBpkO4n78Dy41dt046V/tEWn 1W44nVZ+wNRM+78xlKD+72k2BG3k3nOpszQfS+b024PaIhLGMLAbd3no/V9EQVsc vvN3tMM4wTVQm3ZyUHetxn1BqBrxRYeydsnGiGjDKWA7YLTC79S2E6ADLYv7OeT8 6cc33QLKogoSlm/KfUqH7FAZKr0uNbkf3zKVwuKLSlqFAl6l6AMlGhnP+FyekXIQ vp27MxZyFX1V8PLjHFzUlrRfeg02GrsXjl3wcsh4/OTftGA3clPw5GH0U9Apy3Zr F4DoDtMHy88ukdTKybKc =gD5B -----END PGP SIGNATURE-----
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Matt Caswell
- [TLS] Deprecating RC4 (was: draft-ietf-tls-encryp… Eric Rescorla
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Martin Thomson
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Kurt Roeckx
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Daniel Kahn Gillmor
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Peter Yee
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Andrei Popov
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Stephen Checkoway
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Yoav Nir
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Geoffrey Keating
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Jim Schaad
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Manuel Pégourié-Gonnard
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Johannes Merkle
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Stephen Farrell
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Richard Hartmann
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Yoav Nir
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Warren Kumari
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Eric Rescorla
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Martin Rex
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Martin Thomson
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Martin Rex
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Watson Ladd
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Bill Frantz
- [TLS] Deprecating more (DSA?) (was Re: Deprecatin… Hanno Böck
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Yoav Nir
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Hanno Böck
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Daniel Kahn Gillmor
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Hanno Böck
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Tom Ritter
- Re: [TLS] Deprecating more (DSA?) Alyssa Rowan
- Re: [TLS] Deprecating more (DSA?) Joseph Salowey (jsalowey)
- Re: [TLS] Deprecating more (DSA?) Watson Ladd
- Re: [TLS] Deprecating more (DSA?) Alyssa Rowan
- Re: [TLS] Deprecating more (DSA?) Johannes Merkle
- Re: [TLS] Deprecating more (DSA?) Brian Sniffen
- Re: [TLS] Deprecating more (DSA?) Bill Frantz
- Re: [TLS] Deprecating more (DSA?) Watson Ladd
- Re: [TLS] Deprecating more (DSA?) Samuel Neves
- Re: [TLS] Deprecating more (DSA?) Bill Frantz