Subject: [TLS] New "Fast-Track" draft posted

From: Stefan Santesson <[email-masked]>
Date: Thu, 05 Mar 2009 00:47:44 +0100

As a result of the discussions we had around last IETF I have now posted a
new ³Fast Track² inspired draft.

The name of this draft is  draft-santesson-tls-certcache-00
It will be available in a few days from the I-D repository. Until then it
can be obtained from the staging site at:
http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.txt

I have chosen to do a completely new draft instead of updating the old
fast-track document as I have used a very simplified approach as starting
point.
My document is limited to one new TLS extension with the sole purpose of
including a hash of a cached cert path to allow this cert path to be omitted
from the server Certificate message.

I submitted this draft to inject some energy into the discussion again but
I¹m not locked on the approach if there are good reasons to expand it.
Please read and provide comments.

I would like to request a small time slot on the TLS meeting agenda in San
Francisco to discuss this if possible.

Stefan Santesson
AAA-sec.com

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 05 Mar 2009 03:40:09 +0100

They were very fast. The draft is already available:
http://tools.ietf.org/html/draft-santesson-tls-certcache-00

The name of the extension is confused in the introduction.

Stefan Santesson
AAA-sec.com

On 3/5/09 12:47 AM, "Stefan Santesson" <[email-masked]> wrote:

> As a result of the discussions we had around last IETF I have now posted a new
> ³Fast Track² inspired draft.
> 
> It will be available in a few days from the I-D repository. Until then it can
> be obtained from the staging site at:
> I submitted this draft to inject some energy into the discussion again but I¹m
> not locked on the approach if there are good reasons to expand it.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Russ Housley <[email-masked]>
Date: Thu, 05 Mar 2009 09:46:26 -0500

Stefan:

I would prefer a solution that was not tied to a single one-way hash 
algorithm.  I do not think it would add too much complexity for the 
extension to include a hash algorithm identifier followed by the hash value.

Russ

At 09:40 PM 3/4/2009, Stefan Santesson wrote:
><http://tools.ietf.org/html/draft-santesson-tls-certcache-00>http://tools.ietf.org/html/draft-santesson-tls-certcache-00 
>
>

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Mar 2009 18:17:43 +0100 (MET)

> extension to include a hash algorithm identifier followed by the hash value.

Watch out, here it comes: Hash-Agility-Poisoning.  :)

Reminds me of ekr request at the last IETF saag meeting to
use MD5 under a different name for those things that only
need a hash with low probabilistic collisions rather than
one with cryptographic strength.

The input from previous [email-masked] discussions, to which Stefan
refers, did not see a requirement for hash agility.  In fact,
I do not remember any _security_ issue being raised against
using fairly static identifiers instead, only robustness and
simplicity issues.

Stefan:  Thanks for your efforts, I really appreciate that.
I hope to find some time soon to read and provide feedback.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 06 Mar 2009 01:48:50 +0100

Russ,

You are right that it is a minor addition to add a hash algorithm
identifier. I have no strong opinion about this but I did, as Martin points
out, follow the conclusion of previous discussions on this list.

I do think that the use of hash in this protocol is comparable to use of
hash with the purpose of generating identifiers in other security protocols
where algorithm agility is not required.

Why do you feel we should expand the protocol?

/Stefan

---

From: Russ Housley <[email-masked]>
Date: Fri, 06 Mar 2009 19:54:22 -0500

At some point, I believe that we will want to use a hash function 
other than SHA-1.  We can either insert the algorithm identifier now, 
or we will use a different extension when that time comes.

Russ

---

From: Badra <[email-masked]>
Date: Sat, 7 Mar 2009 10:25:26 +0100

Hi,

I agree with Russ, it is better to use the hash identifier now, with SHA-1
as a mandatory to implement hash function.

Best regards
Badra

On Sat, Mar 7, 2009 at 1:54 AM, Russ Housley <[email-masked]> wrote:

> At some point, I believe that we will want to use a hash function other
> than SHA-1.  We can either insert the algorithm identifier now, or we will
> use a different extension when that time comes.
>
> Russ
>
>

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 07 Mar 2009 18:06:46 +0100

I think we all should agree though that there is no security requirement to
provide a strong hash here.
The only reason to allow another type of hash is so we can completely move
away from SHA-1 when there is no other reason to implement and use it.
I don¹t see that happen in any foreseeable future, but if we can make this
more pure and remove tension by adding an identifier, that is OK with me.

If this list does not strongly object, I will add an algorithm identifier in
the next draft.

Stefan Santesson
AAA-sec.com

On 3/7/09 10:25 AM, "Badra" <[email-masked]> wrote:

> Hi,
>  
> I agree with Russ, it is better to use the hash identifier now, with SHA-1 as
> a mandatory to implement hash function.
>  
> Best regards
> Badra
> 
>> At some point, I believe that we will want to use a hash function other than
>> SHA-1.  We can either insert the algorithm identifier now, or we will use a
>> different extension when that time comes.
>> 
>> Russ 
>> 
>>

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 07 Mar 2009 10:22:07 -0800

If you add hash algorithm agility, you also need to add a way for the
server to specify to the client the algorithms it knows how to compute.
Otherwise, if the client uses an unimplemented algorithm, the server
won't be able to determine that the client has the right cached cert.
and it will have to perform a normal handshake.

Technically this is unneeded complexity.  I like the idea of cloning
MD5 or SHA-1 under a different name to be used for non-security-critical
things such as this proposal.  Would that be allowed under specs such as
FIPS?

Mike

Stefan Santesson wrote:
> I think we all should agree though that there is no security requirement 
> to provide a strong hash here.
> The only reason to allow another type of hash is so we can completely 
> move away from SHA-1 when there is no other reason to implement and use it.
> I don’t see that happen in any foreseeable future, but if we can make 
> this more pure and remove tension by adding an identifier, that is OK 
> with me.
> 
> If this list does not strongly object, I will add an algorithm 
> identifier in the next draft.
> 
> *Stefan Santesson
> *AAA-sec.com

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 7 Mar 2009 10:35:47 -0800

At 7:54 PM -0500 3/6/09, Russ Housley wrote:
>At some point, I believe that we will want to use a hash function other than SHA-1.  We can either insert the algorithm identifier now, or we will use a different extension when that time comes.

We should do the latter, not the former. With the former, we then have a negotiation that must go on between the client and the server and, as usual, this will only end in tears after a long, repetitive argument.

There is essentially no exhaustion worries on the ExtensionType namespace. There is no current worry about preimage attacks on SHA-1. If someone truly wants another hash, they can define a different-yet-nearly-identical extension with a different ExtensionType.

--Paul Hoffman, Director
--VPN Consortium

---

From: Hovav Shacham <[email-masked]>
Date: Sat, 7 Mar 2009 10:52:48 -0800

> and it will have to perform a normal handshake.

I agree with this.  I'd prefer we stick to just SHA-1.  (Or just  
SHA-256?)

-hs.

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 06 Mar 2009 13:27:08 -0800

Michael and all,

  MD5 fine, SHA-1, not so fine.  Better would be SHA-2.
Just my 2 cents...

> > identifier in the next draft.

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 7 Mar 2009 22:29:47 +0200

The test of non-security critical hashes is whether they can be replaced by
CRC, right? So why not really use CRC32 (or CRC64) and avoid this discussion
altogether? The reason "because we've been using MD5 to 'sign' files for
ages" is not very good.

BTW, this seems to be Eric's conclusion in his SAAG presentation.

Thanks,
	Yaron

> -----Original Message-----
> From: Jeffrey A. Williams [mailto:[email-masked]]
> Sent: Friday, March 06, 2009 23:27
> To: Michael D'Errico
> Cc: [email-masked]
> Subject: Re: [TLS] New "Fast-Track" draft posted
> 
> Michael and all,
> 
> > > I don't see that happen in any foreseeable future, but if we can make

---

From: Yoav Nir <[email-masked]>
Date: Sun, 8 Mar 2009 09:53:52 +0200

As long as the server (and all co-located virtual servers) is expected to have less than 64K certificates, CRC32 is probably good enough.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yaron Sheffer
> Sent: Saturday, March 07, 2009 10:30 PM
> To: Jeffrey A. Williams; Michael D'Errico
> Cc: [email-masked]
> The test of non-security critical hashes is whether they can 
> be replaced by CRC, right? So why not really use CRC32 (or 
> CRC64) and avoid this discussion altogether? The reason 
> "because we've been using MD5 to 'sign' files for ages" is 
> not very good.
> 
> > > If you add hash algorithm agility, you also need to add a way for 
> > > the server to specify to the client the algorithms it 
> knows how to compute.
> > > MD5 or SHA-1 under a different name to be used for 
> > > non-security-critical things such as this proposal.  
> Would that be 
> > > allowed under specs such as FIPS?
> > >
> > > Mike
> > >
> > > Stefan Santesson wrote:
> > > > The only reason to allow another type of hash is so we can 
> > > > completely move away from SHA-1 when there is no other 
> reason to 
> > > > implement and
> > use it.
> > > > I don't see that happen in any foreseeable future, but 
> if we can 
> > > > make this more pure and remove tension by adding an identifier, 
> > > > that is OK with me.
> > > >
> > [email-masked] My Phone: 214-244-4827
> > 
> > 
> > 
> 
> 
Email secured by Check Point

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 08 Mar 2009 14:16:44 +0100

Without advocating for hash agility here, I do have to disagree that you
NEED to add hash support negotiation just because you add an identifier.

The only thing that will happen if the server is not capable of computing a
hash of the kind used by the client, is that it will be forced to decline
this optimization and send the full server cert path.

A middle way is to add an identifier and say MUST support SHA-1 and MAY
support other hash algorithms according to local policy.

I definitely would like to avoid any kind of negotiation. Both other options
are fine with me.

/Stefan

On 3/7/09 7:22 PM, "Michael D'Errico" <[email-masked]> wrote:

>> I don¹t see that happen in any foreseeable future, but if we can make

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 07 Mar 2009 14:13:39 -0800

Yoav and all,

  With all due respect, I disagree.  Again just my 2 cents...

Regards,

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 07 Mar 2009 14:19:53 -0800

Stefan and all,

  As a matter of policy and interoperability I disagree with your
choice of "Middle Way" as such would localize acceptance.  Such
is not a good thing, IMHO.

Regards,

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 9 Mar 2009 00:11:32 +0200

An explanation, based on a threat model, would be much appreciated.

Thanks,
	Yaron

> Sent: Sunday, March 08, 2009 0:14
> To: Yoav Nir
> Cc: Yaron Sheffer; Michael D'Errico; [email-masked]
> > As long as the server (and all co-located virtual servers) is expected
> to have less than 64K certificates, CRC32 is probably good enough.
> >
> Scanned by Check Point Total Security Gateway.
> 
> Scanned by Check Point Total Security Gateway.

---

From: Martin Rex <[email-masked]>
Date: Mon, 9 Mar 2009 10:36:54 +0100 (MET)

> or we will use a different extension when that time comes.

I violently disagree.

Anyone how is using that caching extension and has understood
what he is implementing will be fine with SHA-1 forever.

In the discussion that we had on the original Fast Track proposal
many month ago, there was a proposal to assign an static identifier
for the cached information.  There was no security issue raised
agains this approach (and I still don't see a security issue),

The reason why I advocated for SHA-1 over the exact data that goes
over the wire was simplicity and robustness.  If you use a static
identifier, you might not realize when the "cached" information
is no longer in sync (possible reasons: cache corruption on client,
information updated on server but not in client cache).

When a hash over the cached data is used (over the bits-on-the-wire)
rather than a static identifier, then

  - you don't have any configuration issues of synchronously
    assigning a static identifier for the same pieces of information

  - can implement it in a robust fashion so when the clients information
    gets out of sync this can be determined with very high probability
    and the server will send the full, currently valid information
    automatically, instead of having to go through a TLS handshake
    failure (which is quite difficult to recover from, because it
    cannot be done at the TLS layer).

We know exactly the probabilistic collisions of SHA-1, and no matter how
good the attacks on SHA-1 on precomputing collisions may become,
the impact on the probabilistic collisions will remain negiligible
for the purpose we're looking at here,

so NO, unless we're religious about this, we will NOT want to ever
use a different hash function here.

-Martin