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
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
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
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: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
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
> 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
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
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
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 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
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: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: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
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
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
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
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
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, 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 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?
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 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
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 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
25 matches
Mail list logo
