Re: [TLS] Summarizing identity change discussion so far

[Marsh Ray <[e-mail]>]

[e-mail] wrote:
> (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.

There are probably some actively using it.

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

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 
> (whatever "by default" means in your API), at least in this draft.

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

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

OK

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

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.

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

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?

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

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