Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

[Martin Rex <[e-mail]>]

Brian Smith wrote:
> 
> Stefan Santesson wrote:
> > Brian,
> >
> > The use of hash functions in this draft does not require collision 
> > resistance.
> > This is actually quite easy to prove.
> 
> Nobody is questioning that at all.
> 
> My points are:
> 
> 1. As long as this web page on the NIST website says, basically, "don't 
> use SHA-1 for anything," people will want to disable SHA-1 whenever they 
> can. It doesn't matter that this page on the website isn't the official 
> NIST recommendation on the matter. It doesn't matter that NIST 
> recommendations are only binding for federal government work. It doesn't 
> matter that the official NIST recommendation (SP 800-107) is more 
> limited in its recommendations against SHA-1. People will still want to 
> disable it. Like I said many messages before, even if it isn't a  
> technical problem, it is a social problem. And, that problem can be 
> easily avoided.


There is some confusion about what problems there are with SHA-1.

But doing as you suggest, you are just adding massively to that
confusion, depicting SHA-1 as being universally bad.


My memory was, that NIST's recommendation was to no longer
issue certs with sha-1 as a signature algorithm after 2010.


I don't know what you mean by "disabling SHA-1", but most software
is likely to not have such a configuration settings -- and those
software that does is likely to no longer interoperate securely
with others if SHA-1 would be universally disabled.

What you are asking for is a policy like this:

"We can no longer let you use HTTPS because it makes use of
 TLSv1.0 with contains the universally insecure SHA-1 algorithm.
 Please use HTTP URLs instead." 


> 
> 2. It doesn't make sense to require SHA-1 support to be added to 
> implementations that don't need SHA-1 for any other purpose. TLS 1.2 
> doesn't require SHA-1 for anything, so you can build a compliant and 
> useful implementation without SHA-1 support. There are technical 
> advantages to doing so. Obviously, this isn't practical for 
> general-purpose web browsers, but it is practical for many other uses.

You are mistaken.  SHA-1 is a MUST implement for TLSv1.2.

TLS uses a SHA-256 only PRF and provides cipher suites with SHA-256,
but limiting an implmentation to that subset of TLSv1.2 is only
an option for the consumer of the technology, not an option
for the implementor.

Limiting your application to allow only protocol version TLSv1.2
and only ciphersuites with SHA-256 hash and support of Certs
with signature algorithms using sha-256 is going to make your
application non-interoperable with 99,8% of the installed base
of TLS-enables apps.  And that situation is going to change
only at a fairly slow pace in the future.

So it could be that the particular isolated environment that
you are looking at might be happy with such a configuration,
but for the average consumer of this technology it just would not
make any sense. 

And mind you, for your isolated environment, you can certainly
implement and use the caching extension with SHA-256 only,
the proposal has the necessary protocol options.


-Martin