Subject: Re: [TLS] Summarizing identity change discussion so far

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Fri, 18 Dec 2009 01:05:58 -0500

My strong conviction is that the fact of non-zero probability to get  (e.g.) PKIX identity matching wrong - does NOT invalidate the need for something more powerful and usable than memcmp. I'm not convinced that MD5 collision exploitation justifies restriction of matching to memcmp.

Again, my strong conviction.

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Fri Dec 18 00:47:28 2009
Subject: Re: [TLS] Summarizing identity change discussion so far

Kyle Hamilton wrote:
> On Tue, Dec 8, 2009 at 1:13 AM,  <[email-masked]> wrote:
>> (wearing Area Director hat)
>>
>> - We recommend that TLS libraries SHOULD provide identity matching
>> (with memcmp, abort handshake if changed) functionality to
>> applications, and SHOULD allow applications to enable/disable this
>> functionality.
> 
> No, identity matching SHOULD be done in accordance with PKIX.

Strongly disagree. If implementations try to do identity matching that
is any more complicated than memcmp then they *will* get it wrong; see
<http://www.ioactive.com/pdfs/PKILayerCake.pdf> for evidence.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: Marsh Ray <[email-masked]>
Date: Fri, 18 Dec 2009 00:44:29 -0600

Blumenthal, Uri - 0662 - MITLL wrote:
> My strong conviction is that the fact of non-zero probability to get
> (e.g.) PKIX identity matching wrong - does NOT invalidate the need
> for something more powerful and usable than memcmp.

I don't believe many participants in this discussion are thinking that
memcmp() is sufficient for general identity comparison, only that it
works a useful percentage of the time to suggest it would be useful for
TLS implementations to provide as an option to application code.

> I'm not convinced
> that MD5 collision exploitation justifies restriction of matching to
> memcmp.

I missed the email where MD5 collisions were raised.

Mainly memcmp has the advantage of simplicity in definition. If a TLS
implementer wanted to provide an option to compare with hashes they
should just document that it works that way.

- Marsh

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 19 Dec 2009 04:06:51 +0000

Blumenthal, Uri - 0662 - MITLL wrote:
> (e.g.) PKIX identity matching wrong - does NOT invalidate the need for
> something more powerful and usable than memcmp. I'm not convinced that
> MD5 collision exploitation justifies restriction of matching to memcmp.

There are numerous independent bugs related to name matching described
in that paper; I wasn't referring specifically to the MD5 issue.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 19 Dec 2009 04:46:43 +0000

[I messed up the attributions in the previous post -- fixed below.]

Blumenthal, Uri - 0662 - MITLL wrote:
> David-Sarah Hopwood wrote:
>> Kyle Hamilton wrote: