Hi,
After the SLOTH paper, we should think about starting to deprecate
TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS
1.2.
As I understand it, they estimate that both TLS 1.2 with SHA1 and
TLS 1.0 and 1.1 with MD5|SHA1 currently require about 2^77 to be
broken. They all depen
Kurt Roeckx writes:
>After the SLOTH paper, we should think about starting to deprecate TLS 1.0
>and TLS 1.1 and the SHA1 based signature algorithms in TLS 1.2.
The vulnerabilities shown in the SLOTH paper were based on the fact that
implementations still allow MD5 for authentication/integrity p
On Mon, Jan 11, 2016 at 3:09 PM, Peter Gutmann
wrote:
> The vulnerabilities shown in the SLOTH paper were based on the fact that
> implementations still allow MD5 for authentication/integrity protection,
> even
> if (for example) it's explicitly disabled in the config. So the problem
> wasn't a
In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing
around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and
it's likely that enterprise deployments are much worse.
I started gathering numbers on ServerKeyExchange hashes back in November.
The code isn't on Chro
David Benjamin writes:
>In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing
>around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and it's
>likely that enterprise deployments are much worse.
Embedded is even worse. I don't have any figures since it's mostly
TLS [mailto:tls-boun...@ietf.org] On Behalf Of Yuhong Bao
Sent: Monday, January 11, 2016 3:30 PM
To: David Benjamin ; Kurt Roeckx ;
tls@ietf.org
Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms
> (c) Servers which sign SHA-2 but fail if signature_algorithms omits
> SHA-1. The
On Mon, Jan 11, 2016 at 11:38:25PM +, Andrei Popov wrote:
> Yes, per RFC 5246:
> " If the client provided a "signature_algorithms" extension, then all
>certificates provided by the server MUST be signed by a
>hash/signature algorithm pair that appears in that extension."
Yes. Thou
> (Please let's not re-open that thread).
Indeed, let's agree to disagree on this.
Cheers,
Andrei
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Viktor Dukhovni
Sent: Monday, January 11, 2016 3:43 PM
To: tls@ietf.org
Subject: Re: [TLS] Deprecating
On 12 January 2016 at 05:30, Kurt Roeckx wrote:
> After the SLOTH paper, we should think about starting to deprecate
> TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS
> 1.2.
Let's be clear about this: TLS 1.0 represents far too high a
proportion of our usage to remove it at th
On Mon, Jan 11, 2016 at 3:09 PM, Peter Gutmann
wrote:
> Kurt Roeckx writes:
>
>>After the SLOTH paper, we should think about starting to deprecate TLS 1.0
>>and TLS 1.1 and the SHA1 based signature algorithms in TLS 1.2.
>
> The vulnerabilities shown in the SLOTH paper were based on the fact that
Sent: Monday, January 11, 2016 4:33 PM
To: Kurt Roeckx
Cc: tls@ietf.org
Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms
On 12 January 2016 at 05:30, Kurt Roeckx wrote:
> After the SLOTH paper, we should think about starting to deprecate TLS
> 1.0 and TLS 1.1 and th
On 1/11/16 at 4:32 PM, watsonbl...@gmail.com (Watson Ladd) wrote:
Do the RFCs require the relevant checks or not? And given that
implementations frequently get these sorts of things wrong, how do we
make the standard robust against it?
The best way I can think of is to test to see if the check
Watson Ladd writes:
>Do the RFCs require the relevant checks or not?
No, they just specify the algorithms and bits on the wire (with a side-order
of MTI stuff for interoperability). It's up to implementers to not do stupid
things.
>That's because real cryptographers understand that this is onl
On Mon, Jan 11, 2016 at 6:01 PM, Peter Gutmann
wrote:
> Watson Ladd writes:
>
>>Do the RFCs require the relevant checks or not?
>
> No, they just specify the algorithms and bits on the wire (with a side-order
> of MTI stuff for interoperability). It's up to implementers to not do stupid
> things
Watson Ladd writes:
>SHA-1 collisions have not yet been found. Marc Stevens has published
>algorithms he claims reduce the complexity of finding these collisions to
>feasible amounts, but they have not yet been run. However, free-start
>collisions have been found, as have ways to modify constants
On 12/01/2016 02:03, Watson Ladd wrote:
> However, free-start collisions have been found, as have ways to modify
> constants in the SHA-1 IV to get collisions.
To be clear, the research into maliciously altering SHA-1 to make collisions
easier changed the K_i constants added
during the rounds, no
> I'm aware of that (and related) work, but this is about finding
> multicollisions in MD5 || SHA1.
To be clear, there is no published collision on MD5 || SHA1 right now.
In our paper, we only say that *if SHA-1 collisions were to appear* with
complexity 2^x,
then MD5||SHA1 collisions would cos
Tony Arcieri wrote:
[ Charset UTF-8 unsupported, converting... ]
> Peter Gutmann wrote:
>
>> The vulnerabilities shown in the SLOTH paper were based on the fact that
>> implementations still allow MD5 for authentication/integrity protection,
>> even if (for example) it's explicitly disabled in th
> I'm also wondering whether it might be misleading to lump the
> (in)significance of the currently known collisions for HMAC-SHA1
> and HMAC-MD5 together with the (in)significance for
> (general, low-frequent) digital signatures and together with
> PKCS#10 & Certificate-issuance design flaw that
On Tuesday 12 January 2016 14:24:31 Martin Rex wrote:
> Tony Arcieri wrote:
> [ Charset UTF-8 unsupported, converting... ]
>
> > Peter Gutmann wrote:
> >> The vulnerabilities shown in the SLOTH paper were based on the fact
> >> that implementations still allow MD5 for authentication/integrity
> >
Karthikeyan Bhargavan writes:
>Coming back to digital signatures, all uses of weak hash functions are
>essentially broken.
Not necessarily. Use of weak hash functions where the attacker has time to do
offline precomputations/calculations are essentially broken. I'm not saying
"keep on using MD
On Monday 11 January 2016 17:28:33 Bill Frantz wrote:
> On 1/11/16 at 4:32 PM, watsonbl...@gmail.com (Watson Ladd) wrote:
> >Do the RFCs require the relevant checks or not? And given that
> >implementations frequently get these sorts of things wrong, how do we
> >make the standard robust against it
On Mon, Jan 11, 2016 at 6:17 PM David Benjamin
wrote:
> In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing
> around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and
> it's likely that enterprise deployments are much worse.
>
> I started gathering numbers on
23 matches
Mail list logo
