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

[TLS] I-D Action: draft-ietf-tls-rfc4492bis-16.txt

2017-03-23 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier

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
On Thu, Mar 23, 2017 at 10:11 AM, Andrei Popov wrote: > Ø Note that any client which in fact supports > > Ø SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing > it, > > Ø is noncomformant. It's not clear to me how many such clients in fact >

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
Ø Note that any client which in fact supports Ø SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing it, Ø is noncomformant. It's not clear to me how many such clients in fact exist. We saw enough TLS 1.2 clients that are non-compliant in this way that I made 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 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] Review of draft-ietf-tls-rfc4492bis-15

2017-03-23 Thread joel jaeggli
On 3/23/17 9:38 AM, Yoav Nir wrote: > >> On 21 Mar 2017, at 11:04, Stephen Farrell wrote: >> >> >> Thanks Yoav, >> >> On 21/03/17 07:44, Yoav Nir wrote: >>> Some that are not addressed, I’ve answered below. Let me know if you >>> want me to merge and submit. >> >> I'd

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
Hi Steffen, You’re stepping on a sore point for this WG☺. Based on the strict interpretation of the TLS 1.2 RFC, your conclusions are correct. If a TLS1.2 client does not send the signature algorithms extension (or the extension does not include SHA256), a compliant TLS 1.2 server with a SHA256

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] Review of draft-ietf-tls-rfc4492bis-15

2017-03-23 Thread Yoav Nir
> On 21 Mar 2017, at 11:04, Stephen Farrell wrote: > > > Thanks Yoav, > > On 21/03/17 07:44, Yoav Nir wrote: >> Some that are not addressed, I’ve answered below. Let me know if you >> want me to merge and submit. > > I'd say give it a chance for one round of

Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

2017-03-23 Thread Viktor Dukhovni
> On Mar 23, 2017, at 11:53 AM, Melinda Shore > wrote: > > Thanks for the thorough review, Viktor. I'll get the straightforward > bits into the draft over the weekend and plan on discussing the ones > proposing changes to the extension or to chain construction

Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

2017-03-23 Thread Melinda Shore
Thanks for the thorough review, Viktor. I'll get the straightforward bits into the draft over the weekend and plan on discussing the ones proposing changes to the extension or to chain construction and processing in the working group session. Melinda signature.asc Description: OpenPGP digital

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