On Fri, Dec 15, 2017 at 2:01 AM, Hanno Böck wrote:
> On Thu, 14 Dec 2017 16:45:57 -0800
> Colm MacCárthaigh wrote:
>
> > But what would that look like? What would we do now, in advance, to
> > make it easy to turn off AES? For example.
>
> I think this is the wrong way to look at it.
>
> From wh
On Thu, Dec 14, 2017 at 05:05:37PM -0800, Colm MacCárthaigh wrote:
> But I do think the question
> is worth having an answer for. I think we *do* need to prepare for turning
> off AES, there's always a chance we might have to.
Even nastier dependency: SHA-2. If that breaks, currently both TLS 1.2
On Thu, Dec 14, 2017 at 02:58:59PM -0800, Watson Ladd wrote:
> Let's not forget defense 0: migrating away from broken algorithms
> (which means turning them off). The fact that we didn't switch MTI
> away from RSA encryption in TLS 1.1 after these attacks were
> disclosed, or even in TLS 1.2, means
Here's an attempt to define a SHA-2 alternative:
https://tools.ietf.org/html/draft-wconner-blake2sigs-01
Cheers,
Andrei
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara
Sent: Friday, December 15, 2017 6:31 AM
To: Colm MacCárthaigh
Cc: tls@ietf.org
On Fri, Dec 15, 2017 at 9:19 AM, Nikos Mavrogiannopoulos
wrote:
> On Fri, Dec 15, 2017 at 2:01 AM, Hanno Böck wrote:
>>
>> On Thu, 14 Dec 2017 16:45:57 -0800
>> Colm MacCárthaigh wrote:
>>
>> > But what would that look like? What would we do now, in advance, to
>> > make it easy to turn off AES?
On Fri, 15 Dec 2017 11:47:54 -0500
Kathleen Moriarty wrote:
> Is there a reason why a migration to PCKS #1 v2.2 doesn't help for TLS
> 1.2 and prior? I haven't noticed any discussion on that previously. Is
> it just the code base and not those using it being unwilling to
> upgrade supporting libr
On Fri, Dec 15, 2017 at 11:47:54AM -0500, Kathleen Moriarty wrote:
>
> Is there a reason why a migration to PCKS #1 v2.2 doesn't help for TLS
> 1.2 and prior? I haven't noticed any discussion on that previously. Is
> it just the code base and not those using it being unwilling to
> upgrade support
On Fri, Dec 15, 2017 at 02:57:33PM +, Andrei Popov wrote:
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara
> > Even nastier dependency: SHA-2. If that breaks, currently both TLS
> > 1.2 and 1.3 break. There are no alternatives defined.
>
> Here's an attempt to define a SH
Correct.
-Original Message-
From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com]
Sent: Friday, December 15, 2017 9:46 AM
To: Andrei Popov
Cc: Colm MacCárthaigh ; tls@ietf.org
Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in
general, and what we can do
I'm not quite following how this helps. It's true that if SHA-256 is
broken, we're in serious trouble, but that's largely because of the fact
that that's what people's certificates have, so clients really can't refuse
to support SHA-256 certificates. So, how does adding new algorithms help?
(That's
We can force a rotate of all certs in 90 days, and I don't think most
people will notice.
On Fri, Dec 15, 2017 at 10:07 AM, Eric Rescorla wrote:
> I'm not quite following how this helps. It's true that if SHA-256 is broken,
> we're in serious trouble, but that's largely because of the fact that t
On Fri, Dec 15, 2017 at 10:07:16AM -0800, Eric Rescorla wrote:
> I'm not quite following how this helps. It's true that if SHA-256 is
> broken, we're in serious trouble, but that's largely because of the fact
> that that's what people's certificates have, so clients really can't refuse
> to support
On Fri, Dec 15, 2017 at 10:12 AM, Watson Ladd wrote:
> We can force a rotate of all certs in 90 days, and I don't think most
> people will notice.
>
Unfortunately, there are plenty of longterm certificates with lifetimes >>
90 days.
-Ekr
>
> On Fri, Dec 15, 2017 at 10:07 AM, Eric Rescorla wr
On Fri, Dec 15, 2017 at 10:14 AM, Ilari Liusvaara
wrote:
> On Fri, Dec 15, 2017 at 10:07:16AM -0800, Eric Rescorla wrote:
> > I'm not quite following how this helps. It's true that if SHA-256 is
> > broken, we're in serious trouble, but that's largely because of the fact
> > that that's what peop
On Fri, Dec 15, 2017 at 10:15:23AM -0800, Eric Rescorla wrote:
> On Fri, Dec 15, 2017 at 10:12 AM, Watson Ladd wrote:
>
> > We can force a rotate of all certs in 90 days, and I don't think most
> > people will notice.
> >
>
> Unfortunately, there are plenty of longterm certificates with lifetime
It's true, the migration will be slow, but IMHO it still makes sense to define
and implement an alternative hash.
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara
Sent: Friday, December 15, 2017 10:34 AM
To: Eric Rescorla
Cc: tls@ietf.org
Subject: R
On Fri, Dec 15, 2017 at 06:41:06PM +, Andrei Popov wrote:
> It's true, the migration will be slow, but IMHO it still makes sense
> to define and implement an alternative hash.
Agreed. However, on certificates front, we need a method to perform
backward-compatible algorithm transition. Because
So, this has been discussed extensively at the CA/Browser forum, for obvious
reasons.
In my mind, it is not so important to identify and define and implement an
alternative hash.
What *is* important is that the protocol and associated software is able to
support a smooth transition period where p
> Ideally, you'd want certificates to be able to have two signatures during
> the transition period, in order to support clients who have transitioned and
> those who have not.
> Hosting multiple certificates and switching based on the client is feasible,
> but requires some technical wizardry and
Because it's easier for the client to decide what the client understands
than it is for the server to decide what the client understands. Less
complexity = less failures.
Note that this is how XP was handled for code signing. The Authenticode
spec actually made it so if you did things in the r
On Fri, Dec 15, 2017 at 07:14:00PM +, Tim Hollebeek wrote:
> So, this has been discussed extensively at the CA/Browser forum, for obvious
> reasons.
>
> In my mind, it is not so important to identify and define and implement an
> alternative hash.
Well, I would think that having ready to go b
On Fri, Dec 15, 2017 at 07:25:20PM +, Andrei Popov wrote:
> > Ideally, you'd want certificates to be able to have two signatures during
> > the transition period, in order to support clients who have transitioned and
> > those who have not.
>
> > Hosting multiple certificates and switching bas
On Fri, Dec 15, 2017 at 07:33:44PM +, Tim Hollebeek wrote:
>
> However, servers are easier to upgrade than clients, which is why you see
> some of the server side support you mention. I know CloudFlare in
> particular helped a lot of people cope with communicating with clients who
> had diffe
Tim Hollebeek wrote:
> Because it's easier for the client to decide what the client understands
> than it is for the server to decide what the client understands. Less
> complexity = less failures.
>
> Note that this is how XP was handled for code signing. The Authenticode
> spec actually mad
Ilari Liusvaara wrote:
> On Fri, Dec 15, 2017 at 07:33:44PM +, Tim Hollebeek wrote:
>>
>> However, servers are easier to upgrade than clients, which is why you see
>> some of the server side support you mention. I know CloudFlare in
>> particular helped a lot of people cope with communicatin
25 matches
Mail list logo
