[TLS] key sizes in TLS.

"Dang, Quynh" <quynh.dang@nist.gov> Mon, 10 June 2013 14:08 UTC

Return-Path: <quynh.dang@nist.gov>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208E721F8B35 for <tls@ietfa.amsl.com>; Mon, 10 Jun 2013 07:08:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWfj5L9j86Mp for <tls@ietfa.amsl.com>; Mon, 10 Jun 2013 07:08:50 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 785C021F848E for <tls@ietf.org>; Mon, 10 Jun 2013 07:08:43 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 10 Jun 2013 10:08:17 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 10 Jun 2013 10:08:40 -0400
From: "Dang, Quynh" <quynh.dang@nist.gov>
To: "tls@ietf.org" <tls@ietf.org>
Date: Mon, 10 Jun 2013 10:08:37 -0400
Thread-Topic: key sizes in TLS.
Thread-Index: Ac5l5AI+ssUui/A4RZyD97r3UOf27w==
Message-ID: <CDDB5625.2EB5B%qdang@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.4.130416
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CDDB56252EB5Bqdangnistgov_"
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 10 Jun 2013 07:22:39 -0700
Subject: [TLS] key sizes in TLS.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Jun 2013 14:08:56 -0000

Currently (as I understand it), client has no mechanism (or extension) to let the server know what DH-sizes are acceptable (for security reason) when doing DH-RSA and DH-DSS key exchanges and what RSA and DSS key sizes are acceptable for server authentication.

Also, there is no extension or mechanism for which the server can tell the client which key sizes it will accept for client's authentication (in a certificate request the server can tell the client which algorithm(s) it would accept for the client's authentication, but not key sizes).

If I understand it correctly, the client just generates DH parameters comparable with the DH parameters, which the client receives from the server. (I suppose the client could terminate the connection using its local policy when the DH parameters don't meet its security strength requirement). So, I guess it would be nice if the client could let the server know what key size(s) will be acceptable to the client.


I don’t know if it would make sense to specify (1) a method for which the client can use to let the server know what key size(s) (DSS or RSA and DH) are acceptable and (2) a method for which the server can let the client know what key size(s) is/are acceptable to the server for the client's authentication.

Even with some (or proposed) ECC-based cipher suites, there is similar issue about key sizes for client’s authentication.


I would appreciate if you share what you think about the issues.

Regards,
Quynh.