IETF Logo Mail Archive

Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die)

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Mon, 13 April 2015 17:35 UTC

Return-Path: <prvs=1545aa22f0=uri@ll.mit.edu>
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 0D7C21ACEAB for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 10:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 22CCmh2Oktov for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 10:35:50 -0700 (PDT)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 319511A0389 for <tls@ietf.org>; Mon, 13 Apr 2015 10:35:49 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t3DHZhok009198; Mon, 13 Apr 2015 13:35:43 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Thread-Topic: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die)
Thread-Index: AQHQda9cnU9ktJlHUU27K74Bjjn7bp1KyriAgACSwQCAAA3ngIAACfEAgAABowD//74rAA==
Date: Mon, 13 Apr 2015 17:35:42 +0000
Message-ID: <D1517606.23FD5%uri@ll.mit.edu>
References: <CAK9dnSyKf7AY11h1i1h+SudRc-NmTZE5wC682YKhNsxnfV5ShQ@mail.gmail.com> <201504131200.00384.davemgarrett@gmail.com> <874mokug5y.fsf@alice.fifthhorseman.net> <201504131325.20590.davemgarrett@gmail.com> <871tjoue8v.fsf@alice.fifthhorseman.net>
In-Reply-To: <871tjoue8v.fsf@alice.fifthhorseman.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [172.25.177.187]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3511776934_272022"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-13_04:2015-04-10,2015-04-13,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504130148
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/QCC92yzigl7OJ2aYxVkqwrKOnEU>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die)
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: Mon, 13 Apr 2015 17:35:52 -0000

On 4/13/15, 13:31 , "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote:

>On Mon 2015-04-13 13:25:20 -0400, Dave Garrett wrote:
>>> So if we have to have non-(EC)DHE PSK, what would it mean if a TLS peer
>>> were to try to negotiate:
>>> 
>>>   key agreement: PSK
>>>  authentication: RSA-PSS
>>> 
>>> Do we just say "don't do that"?
>>
>> SGTM
>
>……...
>Once the full cartesian explosion is available by multidimensional
>enumeration, we have to mark out which corners of the space are actually
>bad ideas, and we have to make sure our implementations don't stumble
>into those corners by accident.
>
>This isn't impossible to do, but it seems ripe for subtle implementation
>bugs.

Cryptographically sound algorithms and protocols should be immune to this
concern. And we should accept only cryptographically sound algorithms &
protocols. :-)

v2.23.0 | Report a Bug | By Email