On Wednesday, 11 July 2018 06:57:59 CEST Peter Gutmann wrote:
> Hubert Kario writes:
> >defeating two hashes, when both use use the Merkle-Damgård construction, is
> >not much harder than breaking just one of them (increase of work factor
> >less than 2)
>
> "In theory there is no difference
Hubert Kario writes:
>defeating two hashes, when both use use the Merkle-Damgård construction, is
>not much harder than breaking just one of them (increase of work factor less
>than 2)
"In theory there is no difference between theory and practice. In practice
there is".
I'm aware of this
On Tuesday, 10 July 2018 18:01:50 CEST Viktor Dukhovni wrote:
> On Tue, Jul 10, 2018 at 03:38:42PM +0200, Hubert Kario wrote:
> > The github version of the document points out that the security of TLS 1.2
> > downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1.
>
> Is this accurate? TLS
On 2018-07-10 at 00:17 -0400, Viktor Dukhovni wrote:
> More generally, as noted in RFC7435, you get more security by raising
> the ceiling than by raising the floor.
+1, including to the points about SMTP fallback to cleartext, etc.
> For example, I recently learned that current GnuTLS
>
On Tuesday, 10 July 2018 18:38:22 CEST Peter Gutmann wrote:
> David Benjamin writes:
> >EMS does not fix the ServerKeyExchange signature payload. It's still just
> >the randoms and not the full transcript.
>
> Maybe we're talking about different things here, EMS hashes the full
> transcript, for
David Benjamin writes:
>EMS does not fix the ServerKeyExchange signature payload. It's still just the
>randoms and not the full transcript.
Maybe we're talking about different things here, EMS hashes the full
transcript, for 1.0 and 1.1 with the dual SHA-1 and MD5 hash, for 1.2 with
whatever's
On Tue, Jul 10, 2018 at 11:46 AM Peter Gutmann
wrote:
> Hubert Kario writes:
>
> >but randoms in TLS 1.0 and TLS 1.1 are signed (effectively) with SHA-1...
>
> but with EMS or LTS in effect, with a lot more than that.
>
EMS does not fix the ServerKeyExchange signature payload. It's still
On Tue, Jul 10, 2018 at 03:38:42PM +0200, Hubert Kario wrote:
> The github version of the document points out that the security of TLS 1.2
> downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1.
Is this accurate? TLS 1.0 uses a combined SHA-1 + MD5 PRF. Are
there known attacks that
Hubert Kario writes:
>but randoms in TLS 1.0 and TLS 1.1 are signed (effectively) with SHA-1...
but with EMS or LTS in effect, with a lot more than that.
Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Tuesday, 10 July 2018 16:03:24 CEST Eric Rescorla wrote:
> On Tue, Jul 10, 2018 at 6:38 AM, Hubert Kario wrote:
> > On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote:
> > > On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote:
> > > > Is there any reason why we wouldn't
Viktor Dukhovni writes:
>also the private CAs using SHA-1 will need to switch to SHA-2 to regain
>interoperability, despite no actual risk from SHA-1.
Another problem with moving to SHA-2 is that when you have a lot of gear that
only does SHA-1, you need to run parallel PKIs possibly in
Foillowing up: of course this doesn't protect you from 1.2 -> 1.0 downgrade
unless you backport the mechanism to your 1.2 implementation, which I
expect many people will not do, despite the specs.
-Ekr
On Tue, Jul 10, 2018 at 7:03 AM, Eric Rescorla wrote:
>
>
> On Tue, Jul 10, 2018 at 6:38
On Tue, Jul 10, 2018 at 6:38 AM, Hubert Kario wrote:
> On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote:
> > On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote:
> > > Is there any reason why we wouldn't also consider deprecating cipher
> > > suites we don't like? For
On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote:
> On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote:
> > Is there any reason why we wouldn't also consider deprecating cipher
> > suites we don't like? For instance, RFC 5246 mandates the
> > implementation of
14 matches
Mail list logo
