Re: [TLS] Broken browser behaviour with SCADA TLS

2018-07-05 Thread Peter Gutmann
Martin Rex writes: >Cough, what? TLS_DHE_ was known to be a security disaster beyond fixing a >good decade ago (14-May-2007): > > https://www.ietf.org/mail-archive/web/tls/current/msg01647.html That's not DHE that's the problem, it's the use of ridiculously short toy keys that were known to b

Re: [TLS] Key agility issue in draft-ietf-tls-subcerts?

2018-07-05 Thread Ilari Liusvaara
On Fri, Jul 06, 2018 at 01:11:34AM +, Patton,Christopher J wrote: > The string over which the delegation signature is computed contains > the `SubjectPublicKeyInfo` of the DC public key. This in turn > contains an `AlgorithmIdentifier`. Does an X.509 `AlgorithmIdentifier` > determine a unique T

[TLS] Key agility issue in draft-ietf-tls-subcerts?

2018-07-05 Thread Patton,Christopher J
The string over which the delegation signature is computed contains the `SubjectPublicKeyInfo` of the DC public key. This in turn contains an `AlgorithmIdentifier`. Does an X.509 `AlgorithmIdentifier` determine a unique TLS `SignatureScheme`? If not, this might lead to key agility issues, since

Re: [TLS] Broken browser behaviour with SCADA TLS

2018-07-05 Thread Martin Thomson
On Fri, Jul 6, 2018 at 4:51 AM Martin Rex wrote: > Martin Thomson wrote: > > The problem with DHE of course being that it uses the TLS 1.0 suites > > with the SHA1 MAC and with the MAC and encrypt in the wrong order. > > I'm confused about what you are thinking here. Just that we don't implement

Re: [TLS] Broken browser behaviour with SCADA TLS

2018-07-05 Thread Martin Rex
Martin Thomson wrote: > > The problem with DHE of course being that it uses the TLS 1.0 suites > with the SHA1 MAC and with the MAC and encrypt in the wrong order. I'm confused about what you are thinking here. In TLSv1.0 through TLSv1.2 inclusive, all of the TLS handshake messages, including t

Re: [TLS] Broken browser behaviour with SCADA TLS

2018-07-05 Thread Martin Rex
Peter Gutmann wrote: > David Benjamin ? writes: > >>The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit >>minimum. (Chrome enabled far more DHE ciphers than others, so we encountered >>a lot of this.) 2048-bit was completely hopeless. At the time of removal, 95% >>of DHE nego

Re: [TLS] Broken browser behaviour with SCADA TLS

2018-07-05 Thread Adam Langley
On Thu, Jul 5, 2018 at 5:05 AM Peter Gutmann wrote: > The crazy thing is that although Chrome rejects a connection to a PFS, > relatively safe (via the DLP's hardness) 1024-bit DHE server, it's perfectly > happy connecting to a far less safe (both in terms of factorability and use of > pure RSA) 1

Re: [TLS] Broken browser behaviour with SCADA TLS

2018-07-05 Thread Peter Gutmann
Ilari Liusvaara writes: >1) Advertise DHE, accept weak groups. Vulernable to LOGJAM. Only if the weak groups you accept are 512 bits. A bigger question is, why does Chrome think it's up to it to decide whether the device user's choice of key size is appropriate or not? As I mentioned earlier,