IETF Logo Mail Archive

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

Yoav Nir <ynir.ietf@gmail.com> Wed, 08 July 2015 18:08 UTC

Return-Path: <ynir.ietf@gmail.com>
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 32A6E1A6EE6 for <tls@ietfa.amsl.com>; Wed, 8 Jul 2015 11:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 m_VGbGVubVsM for <tls@ietfa.amsl.com>; Wed, 8 Jul 2015 11:08:50 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C454D1A6EE8 for <tls@ietf.org>; Wed, 8 Jul 2015 11:08:47 -0700 (PDT)
Received: by wibdq8 with SMTP id dq8so220482007wib.1 for <tls@ietf.org>; Wed, 08 Jul 2015 11:08:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4GT5puyTQ5c4rXiK23kp6hCvoy6ynSF6E4f3VXRQaU4=; b=NM1WpWffW012dMNPVxDUwAmJb3a80dE4lleYlm9UCCjyaOYceBa3crtKsd9CgDcqFt 4bg7OliPlEw95zVO2pqB9okDy3SYhDEpHL+mpvFtkCloRf0wYpZ2RP8qFwvYZu3T7wfd GB9dfLDnx8dSVCyv76E3MMddt6M9/mVs7ZOi3YI4fAUSwUjUq5Vf7Mvtyw4ISOHgVbff 1zxXDzqYfy/WPgSlol0g6VT0j2NmiRtp2IkTOdsWDATn4fRJKsfv3jjcAOSvSjOZtBty cdWbtZiVhaa9+FBdRo4rqZ1GgBNeXkuMUFUUe2UWI8EFVgszgdcHJsg8MOVQzvp46Z3v xvmQ==
X-Received: by 10.194.110.100 with SMTP id hz4mr22351616wjb.6.1436378926557; Wed, 08 Jul 2015 11:08:46 -0700 (PDT)
Received: from [192.168.1.15] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id b4sm4118322wic.7.2015.07.08.11.08.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jul 2015 11:08:45 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <d7b48bbb16e2425cb2e97c9f4daf170a@ustx2ex-dag1mb2.msg.corp.akamai.com>
Date: Wed, 08 Jul 2015 21:08:39 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4BEE033-F214-450A-A8BC-BA1C4A8CDE14@gmail.com>
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>
To: Rich Salz <rsalz@akamai.com>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/UBWBkajL3CdgWTHNRWF1MJBPfhE>
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 18:08:51 -0000

> On Jul 8, 2015, at 7:06 PM, 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?  Or is it a choose from a list of one type of thing? 

I believe it is never an issue. The use case I care about is “SSL VPNs” and corporate portals. In both of them the organization running the web server rolls out a CA. They hardly ever use a public CA. It’s either a CA that comes bundled with the portal software or a corporate CA. Such a CA will issue the user exactly one certificate, because that certificate is meant to be used to access the portal or the SSL VPN, and the portals are meant to look up the identity in the certificate in the corporate LDAP server or RADIUS or DIAMETER.

It’s possible that a single user might be issued multiple certificates, but they will be from different CAs, and choosing a client certificate based on CA will work. I don’t see any use case for a corporate CA to issue multiple certificates to the same user or device with different algorithms. This is at least true for my use cases.

Yoav

v2.23.0 | Report a Bug | By Email