Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00

[Dave Garrett <[e-mail]>]

On Tuesday, January 27, 2015 06:25:01 pm Yuhong Bao wrote:
> > On Tuesday, January 27, 2015 03:44:36 pm Martin Thomson wrote:
> >> On 27 January 2015 at 12:11, Aaron Zauner <[e-mail]> wrote:
> >>> TLS 1.0 is only marginally different from SSLv3. I think a similar
> >>> document should exist for TLS 1.0. Yes I'm aware of the implications on
> >>> clients/servers.
> >> 
> >> I think that TLS 1.0 is nearing that point too.  But I'm not that
> >> enthusiastic about being the hitman there.  Well, not yet.
> > 
> > Is it at all practical to publish an TLS RFC stating intent to deprecate
> > TLS 1.0/1.1 within some fixed timeframe? I think everyone would rather
> > phase it out then have to "be the hitman" each time.
> > 
> > A straw man proposal would be something like:
> > 
> > 1) TLS 1.0 & 1.1 SHOULD NOT be supported by servers, effective immediately.
> > 2) TLS 1.0 & 1.1 MUST NOT be supported by servers after X months.
> > 3) TLS 1.0 & 1.1 SHOULD NOT be supported by clients after Y months.
> > 
> > I know the UTA BCP I-D deals with this area too, but a specific RFC from the
> > TLS WG might have more impact at reducing numbers before the inevitable
> > catastrophic vulnerability that warrants a diediedie RFC.
> 
> The timeframe would probably have to be in years, given that Windows Server
> 2008 R1 for example ends support in 2020.

I was thinking in the order of X=12 & Y=18, so yes, > 1 year.

The EOL date for implementations is not a barrier, however. Rather, it could be helpful. Servers could recommended to offer to comply within the "SHOULD NOT" timeframe in some minor update. If some longer "MUST NOT" timeframe could be agreed upon, it could be disabled automatically. (unless overridden by admin against the RFC, of course) This is of course the sort of thing that sounds great to some people but horrific to others. ;)

On Tuesday, January 27, 2015 06:33:56 pm Hanno Böck wrote:
> There are products on the market developed as late as 2011 that only
> support SSLv3. I think a crucial thing would be to identify and stop
> people from deploying TLS 1.0-only solutions today - so we won't have
> them tomorrow when we really need to deprecate TLS 1.0.

If there is some way to define a "new" deployment, we could state separate expectations for existing and new deployments.

This sort of thing leaves a lot up to vendors, but the point of such a proposal is to get the ball rolling rather than wait until the last second.


Dave