Subject: [TLS] Summarizing identity change discussion so far

From: <[email-masked]>
Date: Tue, 8 Dec 2009 10:13:20 +0100

(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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Dec 2009 13:01:04 +0000

Hi Pasi,

I think that all sounds ok, except I don't see any mention
in your summary of the fact that a bunch of people (incl. me)
said that this just shouldn't be part of the re-negotiation
fix. Maybe some of those have changed their minds as a result
of the discussion though, I've not checked.

If the consensus ends up being to include some text about
this, then your approach below sounds ok to me, (though
I'd be a bit worried it might take a while to get the
right text), but I'd still rather leave it out entirely
and have some other document address the identity-change
issue in a more considered manner.

S.

[email-masked] wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: <[email-masked]>
Date: Tue, 8 Dec 2009 14:12:07 +0100

The security considerations section of this draft has to describe the
fact that even with this fix, renegotiation does things that will
surprise application developers, and can cause security
vulnerabilities for some of them.

That part we cannot avoid -- some text has to be included.

It's not absolutely required that the text makes recommendations how
to avoid those vulnerabilities, but IMHO it would be a bit strange to
just describe the security problem without saying anything how to
avoid it...

Best regards,
Pasi

> -----Original Message-----
> From: ext Stephen Farrell [mailto:[email-masked]]
> Sent: 08 December, 2009 15:01
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [TLS] Summarizing identity change discussion so far
> 
> 
> Hi Pasi,
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 08 Dec 2009 07:32:21 -0800

I'm fine with this general approach, but I'd also be fine with
(a slightly modified version of) Stephen's suggestion, namely to
to leave out any normative text but provide some descriptive
text.

-Ekr

At Tue, 8 Dec 2009 13:01:04 +0000,

---

From: Marsh Ray <[email-masked]>
Date: Tue, 08 Dec 2009 09:30:44 -0600

[email-masked] wrote:
>  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):
> 
> - We mostly seem to agree that some applications could not just
> handle certificate/identity changes correctly, but would actually
> benefit from them.

There are probably some actively using it.

> library to offer the applications an option where the TLS library 

Are there other actual accepted RFCs that provide recommendations for
libraries? In a quick search, I could only find one or two uses of the
term in the sense we use it here. Most were something like:

RFC 4589 Location Types Registry:
> library:  Library or other public place in which literary and
> artistic materials, such as books, music, periodicals, newspapers,
> pamphlets, prints, records, and tapes, are kept for reading,
> reference, or lending.

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

There are lots of things a TLS library could do. Some of them are
absolutely essential for correctness, but we are not addressing them here.

> - We have much less support for requiring that every TLS library MUST
> implement this functionality and/or MUST enable it by default 

My guess is that such wording would largely be ignored.

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

+1

> does (it seems many people found the current text somewhat unclear).

OK

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

Do we know that this is the correct way to compare certificates for most
applications?

Isn't this the first time TLS has recommended something that wouldn't
work on a perpetual connection? After all, certificates update a lot
more often than record sequence numbers wrap but the spec suggests a
solution for that (renegotiation) rather than breaking the connection.

> recommend any particular default value.

I'm not convinced that we understand the pros and cons well enough to be
making recommendations. If we can't even recommend a default value, what
business do we have making recommendations at all?

> application_data byte(s) correspond to which identity" question (or
> it may not -- the answer may depend a lot on the application
> protocol).

To some extent, this fix addresses it by ensuring that it's the same
part on the other end for the entire connection. To the extent it does
not, it remains a deep problem (e.g., it breaks printf/scanf() over TLS.)

> Does this sound like a reasonable approach?

Yes, but there are lots of reasonable things we could say. Putting
something in when it does not need to be there, however
well-intentioned, will have side effects. If nothing else, implementors
have to read it and decide its implications internally.

The need is immediate for a one-bug-fix document, so I feel we must be
vigilant about keeping it minimal.

* Is there a compelling need for this? I.e., is any of this worth
risking delay for the remainder of the document?

* Does it mandate any specific behavior relevant to the primary goal of
the document?  Would there be a loss to the rest of the document if
it were removed?

* Is it within the scope of the current related standards? Looks to me
like library interfaces are new territory.

* Are the people who need to know IETF's recommendations for TLS library
interfaces going to look for them in this document?

* Is this document the best place for it? (or does this document just
happen to be the next train leaving the station)

If the answer to some of these is 'no' then couldn't some of it be
eliminated?

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Tue, 08 Dec 2009 10:01:46 -0600

[email-masked] wrote:
> surprise application developers,

Does it? This fix ensures that the same party is on each end for the
entire connection.

This rules out a MitM switching connections around. So the only
remaining issues must involve a client or server being able to switch
between certificates that he actually does have the private key for.
Clients are already expected to validate the server cert for any protection.

My impression is that the most surprising thing about renegotiation for
most app developers is that it can happen at all, and that their TLS
library may be silently handling it by default. If we make any
recommendations for TLS libraries it should be to not do renegotiation
unless the application asks for it by registering a callback.

> and can cause security

Do we know of any examples? I can only think of some very subtle and
hypothetical ones that require client and server apps that are already
coded for switching identities intentionally.

> just describe the security problem without saying anything how to

Any security problems which remain after MitM renegotiation is fixed
will be interesting to research, but I just don't think we understand
them well enough yet to describe them in an official document.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Dec 2009 17:11:26 +0100 (MET)

> just describe the security problem without saying anything how to

I agree with this reasoning.

Given the contention on this topic, I would prefer the guidance
to be:

 - non-normative on default behaviour

 - normative (SHOULD) on specific options a TLS implementation
   should offer to applications

Two options where identifying the exact location of renegotiation
in app-data is not necessary and interleaving of app-data and
renegotiation handshake is not a security problem:
  - no renegotiation
  - renegotiation only for identical certificate (chain)  = memcmp()
    (allowing authentication of a previously un-authenticated party)

Defining constraints for changes in identity where the application
has to deal with these changes becomes complex very quickly.

When there is some signaling between TLS implementation and application
(like a callback), and application data that arrives during the
renegotiation handshake is either dropped or leads to failed hanshake,
then a change of identity--even for something as "insignificant" as
a certificate renewal is manageable for the application.

There are issues in the existing SSL & TLS protocol specs that
cause a problem for such semantics: (a) the TLS spec explicitly allows
transfer of application messages interleaved with renegotiation
handshake messages, and (b) the TLS spec indicates that handshake
messages have precedence over application data, without saying
what this means.  Since this precedence is _not_ about processing
at the record layer (in TLS, all messages must be processed in order),
so it can only be about delivery to application.  But here, it
creates a confusion in the wrong direction.  Application data delivered
interleaved with the renegotiation handshake is protected under the
original cipher suite and under the original authentication.
Delaying that data until after authentication seems unreasonable,
because it would require an additional facility to tell the application
at what point in the application data stream the identity change
happened, long after the signaling of the new identity.

When application data delivery is allowed during renegotiation handshake
and the identity change signaling is _NOT_ after successful verification
of the peer's finished messsage, but instead is performed much earlier
in the handshake (such as during processing of the Certificate
handshake message), then this may easily create additional security
problems for an application.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 20:11:41 +0100

Pasi,

> just describe the security problem without saying anything how to

Following the BCP on how to write security considerations it seems perfectly
valid to point out a security issue and to declare it out of scope for the
present document to handle.

/Stefan

---

From: <[email-masked]>
Date: Tue, 8 Dec 2009 20:45:49 +0100

> unless the application asks for it by registering a callback.

I think the fact that "getPeerCertificate()" and similar API calls
can return a different value each time they're called would be a
surprise to most app developers.

> > and can cause security vulnerabilities for some of them.
> 

Well, although the example in James Manger's email is not real (in the
sense that it's not from real code), I think it's plausible, and it
doesn't involve an app already coded for switching identities
intentionally.

I guess an even worse example would be something like this:

  conn = openTlsConnection(host, port)
  if not verifyCertChain(conn.getPeerCert()):
     raise "Not a valid cert"
  if conn.getPeerCert().getName() != expected_name:
     raise "Name in certificate doesn't match"
  # continue...

Most TLS libraries seem to support both callback and get() style
functions for accessing/checking certificates.

Although using the callback-style APIs might be more common (and in
some sence nicer, since it allows you to abort the handshake 
a bit earlier -- but an app developer might not care about this very 
much), I think it would be a surprise to most app developers that 
using the get-style APIs might not be secure.

(And I wouldn't be surprised at all if real applications using
those get() style APIs are found...) 

Best regards,
Pasi

---

From: <[email-masked]>
Date: Tue, 8 Dec 2009 21:00:20 +0100

> term in the sense we use it here. Most were something like:

Plenty, starting from the TLS specification itself (RFC 5246).
For example:

   "These cipher suites MUST NOT be used by TLS 1.2 implementations
   unless the application layer has specifically requested to allow
   anonymous key exchange."

(It's basically saying the TLS library MUST NOT enable this feature by
default, unless the application explicitly asks for it via an API.)

But I agree that the word "library" is very rarely used; it's much
more common to talk about "implementation" or something like that. 

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Dec 2009 21:44:41 +0100 (MET)

> > > surprise application developers,

I fully agree.

> > entire connection. This rules out a MitM switching connections around.

The secure TLS renegotiation _ONLY_  assures that the TLS endpoint
can not be tranferred among different peers without their _consent_
during renegotiation.  An MitM attacker is someone acting without consent.

As long as switching of the identity is permitted during renegotiation
(which it currently is), there is only a vague concept of
"party" at the other end.

> 
> > If we make any recommendations for TLS libraries it should be to
> > not do renegotiation unless the application asks for it by
> > registering a callback.

Clients usually do _not_ want renegotiation, but they have no say
in the TLS handshake.  It is the Server which decides whether to
ask for a certificate on the initial handshake or whether the
server wants to make up his mind only after having seen the clients
request.

The issue is often usability / user-experience.  If you ask a Browser
for a certificate on the initial connect, it will result in a popup
windows to the user, even if that user has no certificate.  It
is possible to configure the browser to suppress this popup,
but often the browser has only a single configuration option
that says "select automatically", and that does actually two
different things, i.e. use a client certificate when the request
from the server matches exactly one client cert -- an the latter
is something one might want _not_ to happen automatically--in
contrast to automatic reply that no client cert is available.

> surprise to most app developers.

Definitely.

> those get() style APIs are found...) 

The get-style API is _the_only_ API that I provide to our applications.
Besides, I'm coming from the GSS-API world, and there never was
a callback API.

If you think that get-style API is dangerous, then you seem to be
quite unaware about the risks involved with some of the callback APIs
(besides being difficult to use in distributed architectures).

TLS peers should check the peer's ID before they start sending
or receiving any data over the newly established TLS session.

Apps protocols that infer from a successful TLS handshake that
previously received plaintext data is authenticated suffer from
a serious apps-level design flaw.

Abusing GSS-API or TLS as an OTP plaintext authentication scheme
is IMHO a severe APPS design flaw.  The ability to complete a
TLS handshake (or to establish a gssapi security context)
does not, by itself, convey any kind of intent.
Apps that infer intent from this, should really rethink their
flawed architecture.

-Martin

---

From: Michael Gray <[email-masked]>
Date: Wed, 9 Dec 2009 09:13:36 +1000

> just describe the security problem without saying anything how to

I support the current wording in section 7 related to identity checking.
However I think it would be preferable to replace MUST with SHOULD in that
section.

- Mick Gray
- IBM

---

From: Marsh Ray <[email-masked]>
Date: Tue, 08 Dec 2009 17:26:53 -0600

> during renegotiation.  An MitM attacker is someone acting without consent.

"Consent" isn't relevant, unless you're suggesting there are systems
intentionally handing out secret key material.

> "party" at the other end.

The remote party may be a physically hardened and tamper-resistant
crypto module, or it may be some set of shared processes operating
across a "cloud". In that sense it is nebulous, but that is outside the
scope of the protocol.

After this fix, the TLS concept of "remote party identity" becomes
maximally "the identity established by the union of all valid and
correct credentials validated during the establishment of a connection
state on this connection, and transitively to all connections sharing at
least one master_secret".

For example, given the basic assumptions about the remote endpoint (it
isn't pwned), you can believe all those credentials came from the same
web browser.

An application protocol is free to require its clients and servers to
apply credentials more conservatively, of course.

I suspect you would prefer application protocols to use a more minimal
sense interpretation of identity, such as "the credentials validated
during the establishment of just this one connection state". But this
isn't sufficient for some uses of https and it is ambiguous for
application data interleaved with handshake messages, so the maximal
interpretation is actually better defined than yours.

> Clients usually do _not_ want renegotiation, but they have no say

Some clients prefer renegotiation because they believe it lends
confidentiality to the "public" client certificate.

> server wants to make up his mind only after having seen the clients

Really it should be defined as part of any application protocol using TLS.

> contrast to automatic reply that no client cert is available.

A. Yes, that's how browsers work.

B. The number of applications which are "browsers" pop-up "choose a
client cert" dialogs is small, I can think of four or five (actively
maintained). This has got to be a tiny fraction of TLS client
applications, even if it is the most visible and familiar for most people.

> (besides being difficult to use in distributed architectures).

Then you can call the TLS library in a loop to invert the call.

> or receiving any data over the newly established TLS session.

For current (pre-fix) https servers, the client's Finished message can
be the most important thing it sends.

> does not, by itself, convey any kind of intent.

It's up to the app layer to define 'intent' the events exposed by the
API, based on the stated and implied guarantees of the protocol spec.

> Apps that infer intent from this, should really rethink their

No, the design flaw was in SSLv3. It regressed on a fundamental security
guarantee of SSLv2 and no one (including the spec writers) realized it
at the time.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 9 Dec 2009 01:02:59 +0100 (MET)

> intentionally handing out secret key material.

It is very relevant.  Consenting communication peers can very
well pass around TLS endpoints without the third communication party
realizing that.

Wait a minute -- the finished messages are _NOT_ secrets for the
communication peers, and they are _NOT_ keying material.
The MitM attacker knows perfectly well which Finished messages
would be necessary to make a secure renegotiation work -- but
he can not coerce unsuspecting TLS peers to uses these finished
messages in the fashion that would be required to make a successful
TLS handshake and deceive the third communication peer.

The finished messages are "secure and unique session identifiers",
and something that Nico wants to get his hands on for channel bindings.

> isn't pwned), you can believe all those credentials came from the same

You do not know where that TLS endpoint is.  What you do know is
that with the secure TLS renegotiation, the TLS endpoint may no
longer be transfered to unsuspecting communication peers.

> be the most important thing it sends.

You mean for the old TLS renegotiation when using client certificates?

Yes, I believe so.

> guarantee of SSLv2 and no one (including the spec writers) realized it

This comment was _not_ about TLS renegotiation.

I was refering to concepts such as the HTTP-Negotiate authentication,
which abuses GSS-API as a plaintext OTP-authentication scheme.

-Martin

---

From: <[email-masked]>
Date: Wed, 9 Dec 2009 14:35:31 +0100

> happened, long after the signaling of the new identity.

Even if application data and handshake messages were not interleaved
over-the-wire, the application could still be confused.

Let's assume some application data arrives just before the handshake
(no interleaving over-the-wire); the TLS library reads it, decrypts
it, and stores it in a buffer.  But then the handshake starts before
the application had a chance to read the data from the buffer (perhaps
it's busy doing some else).  After the handshake is done, the APIs
may not really tell the application when exactly the data arrived...

(This situation doesn't necessarily occur in all TLS libraries, and
may depend on what the APIs look like, how threads are used, etc...)

Best regards,
Pasi
(not wearing any hats)

---

From: <[email-masked]>
Date: Wed, 9 Dec 2009 14:39:32 +0100

> (besides being difficult to use in distributed architectures).

I did not intend to imply that callback-style APIs are somehow 
better; clearly both can have cases where what the app developer
expects the library to do could be quite different from what
TLS actually does...

Best regards,
Pasi
(not wearing any hats)

---

From: <[email-masked]>
Date: Wed, 9 Dec 2009 14:42:08 +0100

Marsh Ray wrote:

> correct credentials validated during the establishment of a
> connection state on this connection, and transitively to all
> connections sharing at least one master_secret".

If this was what the TLS libraries present to applications in their
APIs, all would be fine. But clearly the current APIs lead app
developers to expect quite different concept of "remote party
identity"...

Best regards,
Pasi

---

From: Marsh Ray <[email-masked]>
Date: Wed, 09 Dec 2009 16:59:25 -0600

Hello all,

I'm wearing a warm red and gray hat today.

>> coded for switching identities intentionally.
[...]
>      raise "Name in certificate doesn't match"

_After_ renegotation is fixed (and/or disabled by default) though, how
is this a problem? RI proves the data has come from the same remote
endpoint. That same remote endpoint has proven that he can supply an
acceptable cert, too.

In order for this example to be a problem, the legitimate client would
have to renegotiate specifically for the purpose of dropping certain
cert credentials. This would seem to imply that the application code was
expecting cert changes.

This is not to say that there's no application that could be confused by
such a change, only that I haven't seen any real examples. Nelson
suggested a test tool used internally with NSS might do something
agressive with certs and renegotiation like that.

I don't think it's inherently broken. It seems reasonable to me for one
party to say "By the initial handshake and two subsequent renegotiations
I have proven posession of the private keys for these three certificates".

With renegotiation fixed, credentials supplied on different handshakes
may legitimately be treated as additive. This is how https client
certificates often work: an initial anon-client connection adds a client
cert to the connection by renegotiating.

The actual credentials policy should be documented as part of the app
protocol on top of TLS. Most of them would document "no renegotiation"
and I think that should be the default for implementations.

> functions for accessing/checking certificates.

Most script-language bindings to OpenSSL seem not to support the
callback mechanism very well. Just a data point.

> those get() style APIs are found...) 

You know they exist when all example code for some very popular
implementations and languages does it that way.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Dec 2009 01:04:27 +0100 (MET)

> cert credentials. This would seem to imply that the application code was

The above code sample provide by Pasi is about client-side code,
as indicated by "openTlsConnection" and the comparison
"conn.getPeerCert().getName() != expected_name"

So this is more about server certificates changing then clients
using different credentials.  And it is about apps coding above TLS,
and not about details of TLS implementations.

Since a non-negligible amount of clients will need allow old renegotiation
for a little while, one might want to think about mitigating unexpected
changes the server certificate.

> I have proven posession of the private keys for these three certificates".

There are a lot of applications scenarios where this either doesn't
make any sense or will cause endless problems, support calls and confusion.

Would you want your browser to send *ALL* your WWW-authenticate
credentials to every server and let the server pick (AFAIK the
protocol doesn't even allow that).

In most Audit log facilities, you can only log *ONE* identity for
which an operation was attempted (and failed or succeeded), and not
an arbitrary set of identites.

As soon as you have larger distributed systems, your TLS endpoint
might be a reverse proxy at the perimeter of the backend server farm.

The reverse proxy is going to forward the initially authenticated cert
to the backend application, the backend application will perform an
authentication, create a backend session and issue a session identifier.
>From that point on, all requests carrying that session ID will be
processed under this backend session context, and the reverse proxy
will often forward all requests with that session identifier to the
same backend host (because of the backend state identified by
the session id).  To the backend server, it is entirely irrelevant
how many TCP connections there are established between a client
and the revers proxy -- and for protocols like HTTPS, these will
be terminated quite often.  For HTTPS, a client that shows a
different cert after renegotiation just doesn't make any sense
most of the time.  If the client wants to use a different cert,
he should open a new network connection.

If the reverse proxy or the backend wants to mitigate session-id-stealing
it might employ a memcmp() on the certificates forwarded by the
reverse proxy, and will rightfully abort if that changes.

A client architecture which allows the use of different client
certificates on different connects and does not reliably distinguish
TLS sessions established with different client properties
(anonymous, client cert A, client cert B, ...) is probably broken.

> cert to the connection by renegotiating.

Nope, that is not how it works.
A client that has not been previously authenticated
performs a client cert authentication.  That is a highlander operation.
Which of the TLS implementation actually keeps a set of certs/cert-chains 
for a TLS peer crowd created through renegotiation and has API calls
to iterate through them?  The implementations that I know have
only APIs to request "THE" peer certificate.

So if there actually are apps today that can handle a multitude
of client identites on a SSL/SecurityContext handle, they will likely
have to implement that at the app layer, because very few, if any
TLS implementations provide "a set of TLS peers".

-Martin

---

From: <[email-masked]>
Date: Mon, 14 Dec 2009 09:25:11 +0100

> endpoint. That same remote endpoint has proven that he can supply an

Ah -- I now see that my example was not very clear. The intent was
that renegotiation happens after the first "if" statement but before
the second one. So the certificate that gets used (in the 2nd "if") 
isn't actually the one that was validated (by the 1st "if").
That would obviously be a huge security vulnerability...

Best regards,
Pasi
(not wearing any hats)

---

From: <[email-masked]>
Date: Thu, 17 Dec 2009 22:28:47 +0100

Here's proposed text for the Security Considerations section about the
identity changes. The discussion on the list seemed to favor keeping
the normative parts quite mild, so much of this is worded as advice
for people to consider (or ignore, if they so choose), not as strict 
requirements:

   While this extension mitigates the man-in-the-middle attack
   described in the overview, it does not resolve all possible
   problems an application may face if it is unaware of renegotiation.
   In particular, either the client or the server can during
   renegotiation present a different certificate than was used
   earlier, and this may become as a surprise to application
   developers (who might have expected, for example, that a
   "getPeerCertificates()" API call returns the same value if called
   twice), and might be handled in an insecure way.
   
   TLS implementers are encouraged to clearly document how
   renegotiation interacts with the APIs offered to applications (for
   example, which API calls might return different values on different
   calls, or which callbacks might get called multiple times).

   To make life simpler for applications that do not expect the peer's
   certificate to change once it's been authentication, TLS
   implementations MAY offer the applications the option abort the
   renegotiation if the peer tries to authenticate with a different
   certificate and/or different server name (in the server_name
   extension) than was used earlier. However, enabling this option by
   default for all applications could break existing applications that
   depend on using renegotiation to present multiple certificates.
   TLS implementations SHOULD also offer the applications the option
   to disable renegotiation completely.

   Finally, designers of applications that depend on renegotiation are
   reminded that many TLS APIs represent application data as a simple
   octet stream; applications may not be able to determine exactly
   which application data octets were received before, during, or
   after renegotiation. Especially if the peer presents a different 
   certificate during renegotiation, care is needed when specifying
   how the application should handle the data.

Comments (and especially concrete proposals for improving the text)
are welcome.

Best regards,
Pasi

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Eronen Pasi (Nokia-NRC/Helsinki)
> Sent: 08 December, 2009 11:13
> To: [email-masked]
> Subject: [TLS] Summarizing identity change discussion so far
> 
> provides

---

From: Kyle Hamilton <[email-masked]>
Date: Thu, 17 Dec 2009 13:37:15 -0800

> 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: Martin Rex <[email-masked]>
Date: Thu, 17 Dec 2009 22:45:13 +0100 (MET)

> Comments (and especially concrete proposals for improving the text)

Sounds good to me.  (I leave two typos I think to have noticed to
the native speakers).

Maybe we should at least mention one valid reason for why a certificate
may change in the Security Considerations: certificate update/renewal.

There were two scenarios mentioned where this seems to be a
regular use case IIRC.  Was it gaming where they were using quite
short-lived certificates and then XMPP, where they were using
quite long-lived connections?

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 17 Dec 2009 16:01:36 -0600

Looks great to me.

A few edit suggestions inline.

- Marsh

>    In particular, either the client or the server can during
     For example, during renegotiation either the client
     or the server can present...
>    earlier, and this may become as a surprise to application
     earlier.     This may   come as a surprise
>    implementations MAY offer the applications the option abort the
how about: "are encouraged to offer" ?

>    to disable renegotiation completely.
Consider moving this sentence above the MAY, perhaps in its own paragraph.

- Marsh

---

From: <[email-masked]>
Date: Thu, 17 Dec 2009 23:06:10 +0100

> the identity, implementations MUST abort the handshake with a fatal

Well, the text I proposed just said "different certificate", not
"memcmp". I know that's a bit vague, but "in accordance with PKIX
[PKIX]" is not very precise either, and would need a more specific
reference to where exactly the details are (for example, it can't mean
comparing the Subject field, since PKIX allows leaving it empty).

And the certificate might have extensions (certificate policies,
subject directory attributes, extended key usage, etc.) where changes
between API calls could surprise the application.

Here's another shot at that paragraph (also including suggestions
from Marsh's email):

   TLS implementations SHOULD offer the applications the option to
   disable renegotiation completely.

   To make life simpler for applications that do not expect the peer's
   certificate to change once it's been authenticated, TLS
   implementations may also wish to offer the applications the option
   abort the renegotiation if the peer tries to authenticate with a
   different certificate and/or different server name (in the
   server_name extension) than was used earlier. However, enabling
   this option by default for all applications could break existing
   applications that depend on using renegotiation to change from one
   certificate to another. (For example, long-lived TLS connections
   could change to a renewed certificate; or renegotiation could
   select a different cipher suite that requires using a different
   certificate.)

Best regards,
Pasi

---

From: Michael Gray <[email-masked]>
Date: Fri, 18 Dec 2009 08:16:29 +1000

> the identity, implementations MUST abort the handshake with a fatal

I am also in favour of this wording or wording to that effect.

- Mick

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Dec 2009 23:18:21 +0100 (MET)

> the identity, implementations MUST abort the handshake with a fatal

The way the TLS specifications are currently archtected, this is
a service that is _not_ available from TLS.

Although there is likely some PKI(X)-Software available to the
TLS implementation for the X.509 stuff and certificate path validation
processing, but it can easily be that it is a completely different
module.

If an application currently wants to look at the contents of
the certificates exchanged and authenticated during the TLS handshake,
then this is explicitly declared out-of-scope for TLS in the base spec
(RFC-5246, section 1. last paragraph).  I would strongly recommend
to leave the code slicing (modularization) between application,
PKI-Software and TLS-implementation outside the scope of this spec.

-Martin

---

From: Michael Gray <[email-masked]>
Date: Fri, 18 Dec 2009 08:39:25 +1000

> PKI-Software and TLS-implementation outside the scope of this spec.

Yes the problem is defining what an identity change is precisely.  We know
that CA's load all sorts of stuff in to certificates as part of the DN etc
and the same identify could have multiple certificates, and could be
identified by multiple CAs.  If we say that in TLS we are going to check
identity then it has to be very precisely defined, or extremely vaguely
defined so that the implementation can not be accused of non compliance or
invalid/suspect identity matching.  Perhaps it needs to be a vague as
possible so that TLS implementation can simply push it back to the
application layer in practice

- Mick

---

From: Marsh Ray <[email-masked]>
Date: Thu, 17 Dec 2009 16:53:15 -0600

> application layer in practice

It does seem that in many cases a memcmp() of the certificates is
entirely appropriate. It's certainly a well-defined comparison and it
avoids getting the TLS spec overly wrapped up in the details of PKIX.

As long as people don't start claiming memcmp() is some "official TLS
definition of identity".

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 00:11:42 +0100 (MET)

> As long as people don't start claiming memcmp() is some "official TLS

memcmp() is the TLS method to check that the TLS connection parameter
"peer certificate" is still the same after renegotiation.

Simililarly, memcmp() is the TLS extension RI method to check that
the client and the servers notion of the enclosing TLS session
is the same during renegotiation.

-Martin

---

From: Michael Gray <[email-masked]>
Date: Fri, 18 Dec 2009 09:13:04 +1000

> As long as people don't start claiming memcmp() is some "official TLS

Yes I think I will flip-flop on this as on second thought I do not see how
identify matching can be -simply- precisely defined in this case with PKIX
and what many will feel is a notion of identity.  If we stick to simply
matching the TLS Session Parameter of “peer certificate” as Pasi has
suggested then that might be the best we can do.

Anything that involves [PKIX] would be an appropriate place to use the term
-magic-  :-)

- Mick

---

From: Kyle Hamilton <[email-masked]>
Date: Thu, 17 Dec 2009 15:15:59 -0800

> comparing the Subject field, since PKIX allows leaving it empty).

PKIX allows (and, actually, encourages) Subject to be empty, but only
in the case where subjectAlternativeName isn't.  There are also cases
where subjectAlternativeName can contain the old Subject, and a new
Subject nym is included in the certificate.

> between API calls could surprise the application.

Then, for those applications, they should be rewritten to terminate
the active session when the policies associated with the certificate
change (more specifically, when a particular eKU that the application
requires in the certificate associated with the connection is no
longer asserted by the peer, when the certificate policies change, or
whenever some condition set by the application developer is no longer
met).  Or, the underlying libraries should enforce this (if asked).
Either way, terminating the connection and invalidating the session is
the easiest way to enforce that all certificate changes come through
the "initial request authenticator/authorizer" code path, which is
where all of those policies are verified.

>   select a different cipher suite that requires using a different

I'd agree with that, if it were simply a matter of "certificate" or
"server name".  But, it's not.  This is a matter of identity, and the
identity matching rules of PKIX -- since PKIX is what defines the
content and schema of the X.509 certificates presented by both pairs
-- are what must control, not simply any arbitrary decision by the TLS
WG.  Nor can even any decision made by the TLS WG chair control.

(Certificate type 0 is X.509/PKIX.  Certificate type 1 is OpenPGP --
oh, but wait, we don't have anyone here to advocate the matching rules
for its particular IANA assignment... Each type, 0 and 1, has
different matching rules.  The rule for verifying the token that is
presented MUST be defined, in TLS, as the rule defined by the document
that defines the format of the token, or else the TLS WG is once again
putting a policy decision into a technical specification, restricting
the kinds of authentication which can be used.)

-Kyle H

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 17 Dec 2009 18:46:43 -0500

> the kinds of authentication which can be used.)

Actually, i'm interested in proposing some concrete matching rules for
certificate type 1 (OpenPGP) at some point, though i haven't seen any
attempts to formalize them yet in the context of TLS.

I don't think that this particular draft (covering TLS renegotiation) is
the place to do it, though.

But if folks want to talk about OpenPGP certs for TLS as part of another
conversation, i'm interested.  I might be taking over 5081bis from Nikos
Mavrogiannopoulos as well, and i'd really like feedback from the
knowledgeable and experienced people here here on it.  But i thought i'd
let the current situation get sorted out first (and do a bit more of the
background work i need to do) before moving that project up in visibility.

Just wanted to register that there actually *are* folks who are invested
in OpenPGP certs for TLS.

Btw, thanks to everyone for the thoughtful discussion here.  I don't
intend my sudden de-lurking as an interruption of the work at hand.

Regards,

	--dkg

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 00:47:29 +0100 (MET)

> quite long-lived connections?

Thinking about the "valid reason" scenarios for certificate change,
I'm slightly concerned about a potential disconnect between the
original and the later certificates if the application designer
is a little sloppy.

If a design expects certificate renewal to be necessary
(either short lived-certs or long-lived connections) then it is
imperative that the application performs a full re-authentication
when the identity changes during renegotiation.
A simple certificate path validation could in some situations
subvert a limited-time access restriction.

Normally, you will need a specific certificate for initial authentication,
because it is used for some kind of app-level logon-operation
or ACL-check.  When a renegotiation needs to be performed because of
the expiration of the users cert, and the app does _not_ re-do the
authentication logon/ACL-check, but relies blindly on the
certificate path validation, then the user could simply use
an entirely different certificate with a longer validity during
renegotiation, succeed certificate path validation and keep
using the resource beyond the expiration of the original
access credential/certificate.

-Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 17 Dec 2009 19:49:27 -0700

> quite long-lived connections?

Correct, in XMPP we have long-lived connections, where by "long-lived"
we mean connections that might be up for days or weeks or months. We
recently worked to clarify the handling of certificates in the context
of such connections (section 14.2.2.3 of draft-ietf-xmpp-3920bis-04).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 17 Dec 2009 19:50:22 -0700

> application layer in practice

As previously expressed, I think this belongs at the application layer.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 17 Dec 2009 19:54:22 -0700

> when the identity changes during renegotiation.

Agreed. FWIW, our text about this in draft-ietf-xmpp-3920bis currently
reads as follows (this does not yet talk about identity changes, so
we'll need to address that case as well -- e.g., the certificate might
have been replaced by a new one before the old one expired, but the data
in the cert might be different):

###

14.2.2.3. Checking of Certificates in Long-Lived Streams

   Because XMPP uses long-lived XML streams, it is possible that a
   certificate presented during stream negotiation might expire or be
   revoked while the stream is still live (this is especially relevant
   in the context of server-to-server streams).  Therefore, each party
   to a long-lived stream SHOULD:

   1.  Cache the expiration date of the certificate presented by the
       other party and any certificates on which that certificate
       depends (such as a root or intermediate certificate for a
       certification authority), and terminate the stream when any such
       certificate expires.
   2.  Periodically query the Online Certificate Status Protocol [OCSP]
       responder listed in the Authority Information Access (AIA)
       extension of the certificate presented by the other party and any
       certificates on which that certificate depends (such as a root or
       intermediate certificate for a certification authority), and
       terminate the stream if any such certificate has been revoked.

###

/psa

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 18 Dec 2009 05:47:28 +0000

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 17 Dec 2009 23:27:16 -0800

I share the opinion that identity checking belongs in the application,
performed according to whatever mechanism is appropriate.  We should not
be mandating any particular PKIX processing in the TLS specs. 

I also think if an application is not prepared to be aware of
renegotiation and handle any identity change associated with it then
renegotiation should be disabled.  This implies that renegotiation
should be disabled by default and specifically enabled by an
application.  So I would say

"TLS implementations SHOULD disable renegotiation by default and offer
the applications the option to enable renegotiation.  When an
application enables renegotiation it must handle identity processing for
each handshake."

I don't think binary certificate comparison is necessarily the most
valid comparison for applications to use.  I'm not convinced it will
make life simpler for applications.  

Joe

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Thursday, December 17, 2009 2:06 PM
> To: [email-masked]
> Cc: [email-masked]
> Well, the text I proposed just said "different certificate", 
> not "memcmp". I know that's a bit vague, but "in accordance 
> with PKIX [PKIX]" is not very precise either, and would need 
> a more specific reference to where exactly the details are 
> (for example, it can't mean comparing the Subject field, 
> since PKIX allows leaving it empty).
> 
> And the certificate might have extensions (certificate 
> policies, subject directory attributes, extended key usage, 
> etc.) where changes between API calls could surprise the application.
> 
> Here's another shot at that paragraph (also including 
> suggestions from Marsh's email):
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 18 Dec 2009 12:20:01 +0000

Text like this is much better and would remove the
concern I expressed before (that this spec is not
the place to do more than just fix the renegotiation
bug).

Adding positive examples (games/XMPP) as Martin
suggested would be a fine addition to this.

Delving into details of PKIX or other identity
matching would not be fine IMO.

S.

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 18 Dec 2009 11:49:00 -0800

> application enables renegotiation it must handle identity processing for

With my Idealist hat on, I agree with that 100%.  But after 13.25 years
of working on SSL/TLS libraries, I know that 98+% of the app developers
who use TLS have no idea what that means or how to do it.  IMO, they are
likely to just call a function for each handshake that does the same
thing as for the first handshake, validating the cert chain and (if we're
lucky) checking that some aspect of the cert contains some expected name,
without any regard to what prior certificates may have contained.

So, IMO, it makes sense of TLS implementations to offer some sort of
"default" handling of certs to attempt to ensure continuity of identity
in the absence of something much better from the application.  I'd
suggest that, unless the applications direct them to do otherwise, perhaps
by registering some callback, TLS implementations should check that the
cert in a renegotiation is the same one as in the previous full handshake,
either by memcmp of the entire cert, or by memcmp of the subject name and
subjectAltName (if any).   Anything less will ensure that most apps continue
to get this wrong, IMO.

---

From: Nasko Oskov <[email-masked]>
Date: Fri, 18 Dec 2009 21:30:32 +0000

Peter Saint-Andre wrote:
>> Yes the problem is defining what an identity change is precisely.  We 
>> know that CA's load all sorts of stuff in to certificates as part of 
>> the DN etc and the same identify could have multiple certificates, and 
>> could be identified by multiple CAs.  If we say that in TLS we are 
>> going to check identity then it has to be very precisely defined, or 
>> extremely vaguely defined so that the implementation can not be 
>> accused of non compliance or invalid/suspect identity matching.  
>> Perhaps it needs to be a vague as possible so that TLS implementation 
>> can simply push it back to the application layer in practice
>

I also agree that identity should be handled by the application layer, as it
is not something TLS is best positioned to handle.

Nasko

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 18 Dec 2009 22:03:12 -0800

> Behalf Of Nelson B Bolyard
> Sent: Friday, December 18, 2009 11:49 AM
> To: IETF TLS Working Group
> > performed according to whatever mechanism is appropriate.  
> We should 
> > not be mandating any particular PKIX processing in the TLS specs.
> > 
> > application enables renegotiation it must handle identity 
> processing 
> > for each handshake."
> 
> With my Idealist hat on, I agree with that 100%.  But after 
> 13.25 years of working on SSL/TLS libraries, I know that 98+% 
> of the app developers who use TLS have no idea what that 
> means or how to do it.  IMO, they are likely to just call a 
> function for each handshake that does the same thing as for 
> the first handshake, validating the cert chain and (if we're
> lucky) checking that some aspect of the cert contains some 
> expected name, without any regard to what prior certificates 
> may have contained.
>
>
> So, IMO, it makes sense of TLS implementations to offer some 
> sort of "default" handling of certs to attempt to ensure 
> continuity of identity in the absence of something much 
> better from the application.  I'd suggest that, unless the 
> applications direct them to do otherwise, perhaps by 
> registering some callback, TLS implementations should check 
> that the cert in a renegotiation is the same one as in the 
> previous full handshake, either by memcmp of the entire cert, 
> or by memcmp of the subject name and

[Joe] So ideally renegotiation would be disabled (perhaps after the
client is authenticated in a TLS handshake) unless application enables
it.   The TLS implementation can implement some policy on how to match
identity from on handshake to the next, but I'm not confident that any
single specific policy  will be the right policy for different
applications and deployments.

---

From: <[email-masked]>
Date: Wed, 23 Dec 2009 08:35:05 +0100

Based on earlier discussions, I don't think we have consensus for this
strong change ("SHOULD disable renegotiation by default"). If you ship
an updated TLS library with that change, it will break all existing
applications that use renegotiation (since they are not aware of the
API call to re-enable it, which was probably added in the same update).

I think we have rough consensus for "SHOULD have an API to disable/enable
renegotiation (depending on which is the default setting)", but not
for what the default setting should be.

Best regards,
Pasi
(wearing AD hat)

> ext Joseph Salowey (jsalowey)
> Sent: 19 December, 2009 08:03
> To: Nelson B Bolyard; IETF TLS Working Group

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 28 Dec 2009 14:20:39 -0800

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, December 22, 2009 11:35 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: [TLS] Summarizing identity change discussion so far
> 
> Based on earlier discussions, I don't think we have consensus 
> for this strong change ("SHOULD disable renegotiation by 
> default"). If you ship an updated TLS library with that 
> change, it will break all existing applications that use 
> renegotiation (since they are not aware of the API call to 
> re-enable it, which was probably added in the same update).
> 
[Joe] I agree. 

> I think we have rough consensus for "SHOULD have an API to 
> disable/enable renegotiation (depending on which is the 
> default setting)", but not for what the default setting should be.
> 
[Joe] I'm OK with text along those lines.  How about replacing the 3rd
paragraph with:

"TLS implementations SHOULD provide a mechanism to disable and enable
renegotiation. "

I would also favor adding something like the following to the 5th
paragraph, but I could live without it:

"To make life simpler for applications that do not expect the
certificate to change once it's been authenticated, TLS implementations
may also wish to offer the applications the option abort the
renegotiation if the peer tries to authenticate with a different
certificate and/or different server name (in the server_name extension)
than was used earlier.  TLS implementations may alternatively offer the
option to disable renegotiation once the client certificate has be
authenticated.  However, enabling these options by default for all
applications could break existing applications that depend on using
renegotiation to change from one certificate to another.  (For example,
long-lived TLS connections could change to a renewed certificate; or
renegotiation could select a different cipher suite that requires using
a different certificate.)

> Behalf Of 
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of Nelson B Bolyard
> > > 13.25 years of working on SSL/TLS libraries, I know that 
> 98+% of the 
> > > app developers who use TLS have no idea what that means 
> or how to do 
> > > it.  IMO, they are likely to just call a function for 
> each handshake 
> > > that does the same thing as for the first handshake, 
> validating the 
> > > cert chain and (if we're
> > > lucky) checking that some aspect of the cert contains 
> some expected 
> > > name, without any regard to what prior certificates may have 
> > > contained.
> > >
> > >
> > > "default" handling of certs to attempt to ensure continuity of 
> > > identity in the absence of something much better from the 
> > > application.  I'd suggest that, unless the applications 
> direct them 
> > > to do otherwise, perhaps by registering some callback, TLS 
> > > implementations should check that the cert in a 
> renegotiation is the 
> > > same one as in the previous full handshake, either by 
> memcmp of the 
> > > entire cert, or by memcmp of the subject name and