Re: [TLS] Controlling use of SHA-1

On Thursday 22 October 2015 14:49:47 Bill Frantz wrote: > On 10/23/15 at 2:02 PM, ynir.i...@gmail.com (Yoav Nir) wrote: > >That is true only if your application’s client component and > >server component are using the same library. That is not > >guaranteed in a protocol. Specifically that is not t

Re: [TLS] Controlling use of SHA-1

Martin Thomson wrote: > On 21 October 2015 at 12:56, Viktor Dukhovni wrote: >> Each peer MUST try to send a chain that matches an advertised >> signature algorithm if it has a choice of chains, but otherwise >> MUST send whatever it has. > > Do, or do not. There is no try. > > It's not like any

Re: [TLS] Controlling use of SHA-1

Viktor Dukhovni wrote: > On Thu, Oct 22, 2015 at 06:40:25PM +, Salz, Rich wrote: >>> >>> Most applications want a simple API that hides all the complexities of >>> TLS. If OpenSSL had done that, then it would be easy to see how enabling >>> 1.2 won't cause problems for those apps which said "y

Re: [TLS] Controlling use of SHA-1

According to the CA/Browser Forum Baseline Requirements after 1 January 2016 CAs MUST NOT issue any new Subscriber or Subordinate CA certificates using SHA-1, so we shouldn't see any new certificates with SHA-1 after this date. Another thing

Re: [TLS] Controlling use of SHA-1

Fundamentally, it is up to the client (or server when doing Client Authentication) to choose whether or not to trust a received certificate chain. I am all for deprecating SHA-1 (and MD-5 and MD-2, and other weaker message digests), but “I’m not sure it’s a good idea” (SM) to force the issue in a

Re: [TLS] Controlling use of SHA-1

On Thu, Oct 22, 2015 at 06:40:25PM +, Salz, Rich wrote: > > Most applications want a simple API that hides all the complexities of > > TLS. If OpenSSL had done that, then it would be easy to see how enabling > > 1.2 won't cause problems for those apps which said "you take care of it". > > As

Re: [TLS] Controlling use of SHA-1

On Thursday, October 22, 2015 02:18:30 pm Andrei Popov wrote: > What if we just made an explicit exception for root cert hash algorithms and > not constrained them by the client's alg list? +1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mail

Re: [TLS] Controlling use of SHA-1

On 10/23/15 at 2:02 PM, ynir.i...@gmail.com (Yoav Nir) wrote: That is true only if your application’s client component and server component are using the same library. That is not guaranteed in a protocol. Specifically that is not the case with the web. There are some version intolerant serv

Re: [TLS] Controlling use of SHA-1

On 22 October 2015 at 11:17, Watson Ladd wrote: > Ideally, yes. Applications never cared about what was happening, but wanted > a "secure this channel" magic call. I think that this is conditionally true. If you are using TLS 1.2 with reasonably modern practices, then getting TLS 1.3 should be

Re: [TLS] Controlling use of SHA-1

> On 22 Oct 2015, at 9:26 PM, Watson Ladd wrote: > > > On Oct 22, 2015 2:20 PM, "Salz, Rich" > wrote: > > > > > If we (okay, not "we", library implementors) require explicit application > > > opt- > > > in to TLS 1.3, the adoption rate is probably not going to be very

Re: [TLS] Controlling use of SHA-1

> On Oct 22, 2015, at 2:18 PM, Andrei Popov wrote: > > What if we just made an explicit exception for root cert hash algorithms and > not constrained them by the client's alg list? Yes, that would be substantially less bad. I still don't see any compelling reason to shift chain validation po

Re: [TLS] Controlling use of SHA-1

On Thu, Oct 22, 2015 at 11:20 AM, Salz, Rich wrote: > > If we (okay, not "we", library implementors) require explicit > application opt- > > in to TLS 1.3, the adoption rate is probably not going to be very good. > So, yes, > > I think applications should start using TLS 1.3 without any changes.

Re: [TLS] Controlling use of SHA-1

On Thu, Oct 22, 2015 at 11:00 AM, Salz, Rich wrote: > > That is, the library update can be transparent to the end-user, who will > > continue to expect normal functionality and expect everything to work. > > Should all applications suddenly start using TLS 1.3 without any changes? > Really? Or s

Re: [TLS] Controlling use of SHA-1

> Most applications want a simple API that hides all the complexities of TLS. > If OpenSSL had done that, then it would be easy to see how enabling 1.2 won't > cause problems for those apps which said "you take care of it". As someone with a long history of building, influencing, and using libra

Re: [TLS] Controlling use of SHA-1

On Thu, Oct 22, 2015 at 01:18:37PM -0500, Benjamin Kaduk wrote: > On 10/22/2015 01:00 PM, Salz, Rich wrote: > >> That is, the library update can be transparent to the end-user, who will > >> continue to expect normal functionality and expect everything to work. > > Should all applications suddenly

Re: [TLS] Controlling use of SHA-1

On Oct 22, 2015 2:20 PM, "Salz, Rich" wrote: > > > If we (okay, not "we", library implementors) require explicit application opt- > > in to TLS 1.3, the adoption rate is probably not going to be very good. So, yes, > > I think applications should start using TLS 1.3 without any changes. > > And w

Re: [TLS] Controlling use of SHA-1

> If we (okay, not "we", library implementors) require explicit application opt- > in to TLS 1.3, the adoption rate is probably not going to be very good. So, > yes, > I think applications should start using TLS 1.3 without any changes. And what about 0RTT? Removed support for some crypto? Var

Re: [TLS] Controlling use of SHA-1

On 10/22/2015 01:00 PM, Salz, Rich wrote: >> That is, the library update can be transparent to the end-user, who will >> continue to expect normal functionality and expect everything to work. > Should all applications suddenly start using TLS 1.3 without any changes? > Really? Or should what *th

Re: [TLS] Controlling use of SHA-1

What if we just made an explicit exception for root cert hash algorithms and not constrained them by the client's alg list? From: Viktor Dukhovni Sent: 10/22/2015 11:12 AM To: tls@ietf.org Subject: Re: [TLS] Controlling use of SHA-1 On Thu, Oct 22, 2015 at

Re: [TLS] Controlling use of SHA-1

On Oct 22, 2015 2:00 PM, "Salz, Rich" wrote: > > > That is, the library update can be transparent to the end-user, who will > > continue to expect normal functionality and expect everything to work. > > Should all applications suddenly start using TLS 1.3 without any changes? Really? Or should w

Re: [TLS] Controlling use of SHA-1

On Thu, Oct 22, 2015 at 10:30:33AM -0700, Martin Thomson wrote: > > % a certificate that specifies a trust anchor MAY be omitted from the chain > > > > The client cannot decide that the signature on the root cert the server > > sent is bad, if the server does not send the root cert. > > Yes, that

Re: [TLS] Controlling use of SHA-1

> That is, the library update can be transparent to the end-user, who will > continue to expect normal functionality and expect everything to work. Should all applications suddenly start using TLS 1.3 without any changes? Really? Or should what *they used to do* just work as it was? If that?

Re: [TLS] Controlling use of SHA-1

On 10/22/2015 12:45 PM, Salz, Rich wrote: >> Maybe it would help if Victor could describe the situation in which he thinks >> that it would be appropriate to send a certificate that is signed by MD5. > Or where an application upgrades to a new library and expects EVERYTHING to > work exactly as it

Re: [TLS] Controlling use of SHA-1

> Maybe it would help if Victor could describe the situation in which he thinks > that it would be appropriate to send a certificate that is signed by MD5. Or where an application upgrades to a new library and expects EVERYTHING to work exactly as it used to, with no changes. ___

Re: [TLS] Controlling use of SHA-1

On 22 October 2015 at 09:19, Benjamin Kaduk wrote: > > % a certificate that specifies a trust anchor MAY be omitted from the chain > > The client cannot decide that the signature on the root cert the server > sent is bad, if the server does not send the root cert. Yes, that was my thinking. I ex

Re: [TLS] Controlling use of SHA-1

On 10/22/2015 09:24 AM, Viktor Dukhovni wrote: > >> Why would it make sense to prohibit the sending of PKIX trust anchor >> certificates that have sha1WithRSAEncryption signatures? > It makes no sense to restrict the signatures of trust-anchors. It > makes little sense to restrict the signatures c

Re: [TLS] Controlling use of SHA-1

Viktor Dukhovni writes: > On Thu, Oct 22, 2015 at 08:42:51AM +0100, Rob Stradling wrote: > > > IINM this also changes the fallback for servers that choose to include a > > PKIX trust anchor certificate in the Server Certificate message. > > The signatures of trust-anchor (i.e. self-signed) cert

Re: [TLS] Controlling use of SHA-1

On Thu, Oct 22, 2015 at 08:42:51AM +0100, Rob Stradling wrote: > IINM this also changes the fallback for servers that choose to include a > PKIX trust anchor certificate in the Server Certificate message. The signatures of trust-anchor (i.e. self-signed) certificates MUST NOT be constrained by th

Re: [TLS] Controlling use of SHA-1

On 22/10/15 00:52, Dave Garrett wrote: I'm in favor of this change as well. It annoys Viktor, as it changes the fallback in a way that isn't ideal for some cases that trust the cert directly or with OE, IINM this also changes the fallback for servers that choose to include a PKIX trust ancho

Re: [TLS] Controlling use of SHA-1

I am also in favor of this change: it prohibits the server to send SHA-1 certs when signature_algorithms does not include SHA-1. Russ On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson wrote: The current draft permits the use of SHA-1 in the certificate chain, which gives SHA-1 a free pass ind

Re: [TLS] Controlling use of SHA-1

On Wed, Oct 21, 2015 at 08:14:19PM -0400, Dave Garrett wrote: > On Wednesday, October 21, 2015 03:56:09 pm Viktor Dukhovni wrote: > > Whether SHA-1 in the chain is used to make trust decisions is only > > known to the client, and the server MUST NOT preempt that by denying > > the client access to

Re: [TLS] Controlling use of SHA-1

On Wednesday, October 21, 2015 03:56:09 pm Viktor Dukhovni wrote: > Whether SHA-1 in the chain is used to make trust decisions is only > known to the client, and the server MUST NOT preempt that by denying > the client access to whatever chain it has on hand. Can we please just fix this issue prop

Re: [TLS] Controlling use of SHA-1

I'm in favor of this change as well. It annoys Viktor, as it changes the fallback in a way that isn't ideal for some cases that trust the cert directly or with OE, but I think it's better than the alternative. Dave On Wednesday, October 21, 2015 03:17:44 pm Eric Rescorla wrote: > I think this

Re: [TLS] Controlling use of SHA-1

On 21 October 2015 at 12:56, Viktor Dukhovni wrote: > Each peer MUST try to send a chain that matches an advertised > signature algorithm if it has a choice of chains, but otherwise > MUST send whatever it has. Do, or do not. There is no try. It's not like any of this is ambiguous in any way.

Re: [TLS] Controlling use of SHA-1

On Wed, Oct 21, 2015 at 12:15:25PM -0700, Martin Thomson wrote: > The current draft permits the use of SHA-1 in the certificate chain, > which gives SHA-1 a free pass indefinitely. Forbidding the sending of SHA-1 chains was wrong last time we discussed this at length, and remains wrong now. Whet

Re: [TLS] Controlling use of SHA-1

right direction. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Wednesday, October 21, 2015 12:18 PM To: Martin Thomson Cc: tls@ietf.org Subject: Re: [TLS] Controlling use of SHA-1 I think this is the right answer and parallels what we are doing with PSS

Re: [TLS] Controlling use of SHA-1

I think this is the right answer and parallels what we are doing with PSS. -Ekr On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson wrote: > The current draft permits the use of SHA-1 in the certificate chain, > which gives SHA-1 a free pass indefinitely. Since we expressly forbid > the use of SH