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

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Tue, 8 Dec 2009 07:43:38 -0500

IMHO - Yes.

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Tue Dec 08 04:13:20 2009
Subject: [TLS] Summarizing identity change discussion so far

(wearing Area Director hat)

Although the IETF Last Call is still underway, here's a short attempt
to summarize the discussion regarding identity changes (Section 7) so
far:

- We seem to agree that changing the certificate/identity 
during secure renegotiation (so there's no man-in-the-middle, just two
parties) could confuse some applications.  James Manger's email provides 
IMHO a good example of what that confusion could be (in this particular 
example, the confusion has security implications, too):

http://www.ietf.org/mail-archive/web/tls/current/msg05122.html

- We mostly seem to agree that some applications could not just handle
certificate/identity changes correctly, but would actually benefit
from them. 

- We seem to agree that it would be a reasonable idea for the TLS
library to offer the applications an option where the TLS library
checks that the certificate doesn't change during renegotiation. 
This is an *option* -- an application could decide not to use it, 
and e.g. do more complex comparisons.

- We have much less support for requiring that every TLS library 
MUST implement this functionality and/or MUST enable it by default
(whatever "by default" means in your API), at least in this draft.

Unless I'm badly misreading the situation, or it significantly changes
during the rest of the IETF Last Call, my proposal here would be as
follows:

- We do NOT require (with "MUST") any changes to TLS libraries in this
regard.

- We describe the situation a bit more clearly than the current text
does (it seems many people found the current text somewhat unclear).

- 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.

- We include a sentence or two describing the pros and cons of
enabling/not enabling this feature by default, but don't require or
recommend any particular default value.

- The text probably needs to note that if the applications wants to
deal with identity changes, it may need to consider the "which
application_data byte(s) correspond to which identity" question (or it
may not -- the answer may depend a lot on the application protocol).

Does this sound like a reasonable approach?

Best regards,
Pasi
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Tue, 8 Dec 2009 07:43:38 -0500

IMHO - Yes.

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Tue Dec 08 04:13:20 2009
Subject: [TLS] Summarizing identity change discussion so far

Best regards,
Pasi

---

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Thu, 17 Dec 2009 19:50:34 -0500

I'm jumping in late (what would you expect from somebody on vacation :-), but most of what I may want to say is already eloquently put by Kyle. 

I agree with him points - including (and especially!) those made about WG defining & hard-coding inflexible policies (stated in subsequent postings).

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Thu Dec 17 16:37:15 2009
Subject: Re: [TLS] Summarizing identity change discussion so far

> applications, and SHOULD allow applications to enable/disable this

No, identity matching SHOULD be done in accordance with PKIX.  memcmp
is not at all sufficient.

However, I would support the following:

- TLS libraries SHOULD provide identity matching services between and
throughout renegotiation handshakes.  Libraries SHOULD implement this
in accordance with PKIX [PKIX], but MAY do so with a direct memory
comparison.  Implementors are cautioned that this latter approach does
not provide for changing the cipher parameters -- such as a
renegotiation with an EC or DH certificate after identification with
an RSA certificate.  If the identity matching service fails to match
the identity, implementations MUST abort the handshake with a fatal
bad_certificate alert.

-Kyle H

---

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:
> 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