IETF Logo Mail Archive

Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Wed, 08 July 2015 16:12 UTC

Return-Path: <prvs=463194be81=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 7F2241A01AE for <tls@ietfa.amsl.com>; Wed, 8 Jul 2015 09:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, 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 Qj1I8DWFlBkh for <tls@ietfa.amsl.com>; Wed, 8 Jul 2015 09:12:06 -0700 (PDT)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id A0E811A017A for <tls@ietf.org>; Wed, 8 Jul 2015 09:12:06 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t68GC4mv028996; Wed, 8 Jul 2015 12:12:04 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Salz, Rich" <rsalz@akamai.com>
Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
Thread-Index: AQHQuMqHM/L4/ZIBKEisF6Kbx4+pEp3QcEqAgAAI+QCAAAQ1gIAADWmAgAA2FYCAACIggIAAML+AgADssAD//71kgIAAQ62A//++d4A=
Date: Wed, 08 Jul 2015 16:12:04 +0000
Message-ID: <D1C2C301.1BAA9%uri@ll.mit.edu>
References: <CABcZeBOWK_WnHAefsZUBr4UyEkyiZqi1mhoZH8ZeGFftdOqTTw@mail.gmail.com> <CABcZeBMPsopxV=mu+MJAwJC6w=iuytA3ueyXKpg1QFdV=JWirw@mail.gmail.com> <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <CABcZeBNxW6jaf=HZFvm56K5pKeLD4GyNXOimUHUCt34r_76Vzw@mail.gmail.com> <20150707205858.GH21534@mournblade.imrryr.org> <CABkgnnXZ9HmW2BHrda3s9LMVUzZbdbdD2yKU84w2W8roycJ-xg@mail.gmail.com> <a774e57216864bbebefa3b38bb65c183@ustx2ex-dag1mb2.msg.corp.akamai.com> <CABkgnnXpboFmkgr37aWsNdm-OfvVwyd0jW4HHYuGMXht6=CjRA@mail.gmail.com> <D1C2C216.1BAA0%uri@ll.mit.edu> <d7b48bbb16e2425cb2e97c9f4daf170a@ustx2ex-dag1mb2.msg.corp.akamai.com>
In-Reply-To: <d7b48bbb16e2425cb2e97c9f4daf170a@ustx2ex-dag1mb2.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.2.150604
x-originating-ip: [172.25.177.187]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3519202319_4633163"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-08_08:2015-07-08,2015-07-08,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-1506180000 definitions=main-1507080250
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/qcx81x5lwqoisZEc0j1E6posRYw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
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: <https://mailarchive.ietf.org/arch/browse/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, 08 Jul 2015 16:12:08 -0000

On 7/8/15, 12:06 , "Salz, Rich" <rsalz@akamai.com> wrote:

>> I do too - we do mutual certificate-based authentication.
>
>So let me rephrase Viktor's question:  do many client-side TLS apps care
>need to care about which certificate to present?

Probably not, at least not now. Usually our clients have one cert per
purpose, and are well-aware of what cert to use when (if one client has
more than one purpose and therefore more than one credential). Maybe it’s
because our usage model is still young and unsophisticated…?


>  Or is it a choose from a list of one type of thing?

<puzzled look> :-)

v2.23.0 | Report a Bug | By Email