Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-24 Thread Martin Rex
Michael StJohns wrote: > Martin Rex wrote: >> oops, typo: >> >> Martin Rex wrote: >>> Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com >>> I'm a little confused. >>> >>> This is the cert chain (as visualized by Microsoft CryptoAPI): >>> >>>server-cert:

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-24 Thread Ryan Sleevi
On Fri, Mar 24, 2017 at 1:10 PM, Martin Rex wrote: > If Chrome really does AIA-fetching (*shudder*), how can it be disabled? > I can understand and appreciate your viewpoint, although we disagree. I'll save the rest of the list from rehashing that discussion, since the topic at

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-24 Thread Ryan Sleevi
On Fri, Mar 24, 2017 at 1:23 AM, Viktor Dukhovni wrote: > > > On Mar 24, 2017, at 1:08 AM, Martin Thomson > wrote: > > > >> I've never seen > >> a TLS server that has multiple chains to choose from for the same > >> server identity. > > Both

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-24 Thread Martin Rex
oops, typo: Martin Rex wrote: > > Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com > I'm a little confused. > > This is the cert chain (as visualized by Microsoft CryptoAPI): > > server-cert: CN=cloudflare.com, ... > contains ECDSA P-256 public key >

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-24 Thread Martin Rex
Viktor Dukhovni wrote: > > > On Mar 24, 2017, at 1:08 AM, Martin Thomson > > wrote: > > > >> I've never seen > >> a TLS server that has multiple chains to choose from for the same > >> server identity. > [ https://www.cloudflare.com/ ] > > Both chains of course

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-24 Thread Martin Rex
Viktor Dukhovni wrote: > > The net effect is that in practice you simply ignore the signature > algorithms when it comes to the certificate chain. Essentially correct. This is the only reasonable, highly backwards compatible and perfectly secure choice. > > I've never seen a TLS server that

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-24 Thread Eric Rescorla
On Thu, Mar 23, 2017 at 10:23 PM, Viktor Dukhovni wrote: > > > On Mar 24, 2017, at 1:08 AM, Martin Thomson > wrote: > > > >> I've never seen > >> a TLS server that has multiple chains to choose from for the same > >> server identity. > > Both

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-24 Thread Salz, Rich
> Sorry I meant to say multiple digest algorithms for otherwise identical chains > (same public key algorithm and server name). We used to have to do this, during the MD5-deprecation days. ___ TLS mailing list TLS@ietf.org

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-24 Thread Fries, Steffen
Peter Gutmann [pgut...@cs.auckland.ac.nz] writes Andrei Popov writes: >Unfortunately, in practice there are TLS 1.2 clients that support >SHA256, but don't advertise it via the signature algorithms extension. It's actually pretty safe to just automatically assume

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Viktor Dukhovni
> On Mar 24, 2017, at 1:08 AM, Martin Thomson wrote: > >> I've never seen >> a TLS server that has multiple chains to choose from for the same >> server identity. Both chains of course use SHA256. Sorry I meant to say multiple digest algorithms for otherwise

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Martin Thomson
On 24 March 2017 at 12:29, Viktor Dukhovni wrote: > I've never seen > a TLS server that has multiple chains to choose from for the same > server identity. I didn't have to look far. www.cloudflare.com will switch hit and pick RSA or ECDSA on demand: $ ./tstclnt -h

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Viktor Dukhovni
> On Mar 23, 2017, at 9:00 PM, Peter Gutmann wrote: > > See several previous discussions on the rationale behind > this (hmm, if you can find them :-). See, for example, the thread that contains: https://www.ietf.org/mail-archive/web/tls/current/msg17977.html I

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Peter Gutmann
Fries, Steffen writes: >I looked through the mailing list but did not find an immediate answer to my >question, but I guess, it must have been discussed already. It's been discussed several times, but I'm not sure which search terms you'd have to apply to find the

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Eric Rescorla
On Thu, Mar 23, 2017 at 10:24 AM, Martin Rex wrote: > Eric Rescorla wrote: > >> > >> based on your reply my conclusion is that > >> > >> - there is no (standard compliant) way for a server to use a > >> SHA256 based certificate for server side authentication in cases where

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Eric Rescorla
Of *Eric Rescorla > *Sent:* Thursday, March 23, 2017 9:58 AM > *To:* Fries, Steffen <steffen.fr...@siemens.com> > *Cc:* TLS WG <tls@ietf.org> > *Subject:* Re: [TLS] Enforcing stronger server side signature/hash > combinations in TLS 1.2 > > &

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Martin Rex
Eric Rescorla wrote: >> >> based on your reply my conclusion is that >> >> - there is no (standard compliant) way for a server to use a >> SHA256 based certificate for server side authentication in cases where the >> client does not provide the signature_algorithm extension > > Not quite.

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Andrei Popov
Rescorla Sent: Thursday, March 23, 2017 9:58 AM To: Fries, Steffen <steffen.fr...@siemens.com> Cc: TLS WG <tls@ietf.org> Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2 On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen <steffen.fr

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Eric Rescorla
On Thu, Mar 23, 2017 at 9:44 AM, Martin Rex wrote: > Fries, Steffen wrote: > > > > based on your reply my conclusion is that > > > > - there is no (standard compliant) way for a server to use a SHA256 > > based certificate for server side authentication in cases where the > >

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Eric Rescorla
On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen wrote: > Hi Erik, > > > > based on your reply my conclusion is that > > - there is no (standard compliant) way for a server to use a > SHA256 based certificate for server side authentication in cases where the >

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Andrei Popov
: Thursday, March 23, 2017 8:37 AM To: TLS WG <tls@ietf.org> Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2 Hi Erik, based on your reply my conclusion is that - there is no (standard compliant) way for a server to use a SHA256 based certi

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Martin Rex
Fries, Steffen wrote: > > based on your reply my conclusion is that > > - there is no (standard compliant) way for a server to use a SHA256 > based certificate for server side authentication in cases where the > client does not provide the signature_algorithm extension The statement quoted by

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Fries, Steffen
Hi Erik, based on your reply my conclusion is that - there is no (standard compliant) way for a server to use a SHA256 based certificate for server side authentication in cases where the client does not provide the signature_algorithm extension - clients should always use

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Fries, Steffen
Hi Viktor, thanks for the response, I replied inline. > According to TLS 1.2 section 7.4.1.4.1. a client may use the > signature_algorithm extension to signal any combinations the client > supports, listed in the order of preferences. The signature algorithm is primarily about signatures made

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Eric Rescorla
On Thu, Mar 23, 2017 at 7:39 AM, Viktor Dukhovni wrote: > > > On Mar 23, 2017, at 10:31 AM, Fries, Steffen > wrote: > > > > According to TLS 1.2 section 7.4.1.4.1. a client may use the > > signature_algorithm extension to signal any

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Viktor Dukhovni
> On Mar 23, 2017, at 10:31 AM, Fries, Steffen > wrote: > > According to TLS 1.2 section 7.4.1.4.1. a client may use the > signature_algorithm extension to signal any combinations the > client supports, listed in the order of preferences. The signature algorithm

[TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

2017-03-23 Thread Fries, Steffen
Hi all, according to TLS 1.2 section 7.4.1.4.1. a client may use the signature_algorithm extension to signal any combinations the client supports, listed in the order of preferences. If the client does not use this extension, the server must use the signature algorithm in combination with