Re: [TLS] Please discuss: draft-housley-evidence-extns-00

Eric Rescorla <ekr@networkresonance.com> writes:
> SPEAKING AS CHAIR:
> Mark Brown and Russ Housley have requested that the TLS WG
> adopt draft-housley-evidence-extns-01 as a WG item. This
> work was presented at San Diego to a generally positive
> response but it needs to be discussed on the list. Please
> use this thread to start that discussion.

SPEAKING AS MYSELF
I'm quite negative on this proposal. Review attached.

Note: the following review was based on the -00 version of the
document but a quick skim suggests that the -01 has the same
weaknesses.

BACKGROUND
TLS provides for public key authentication of both client and server
but this only provides for proof of the existence of the handshake
(and this only in limited circumstances). It doesn't provide for
any proof of the contents of the data messages. This draft
extends TLS to provide signatures over the data.

ARCHITECTURAL COMMENTS
I'm not particularly enamored of this general approach. The 
signatures in question are fundamentally an application-level
construct: they're requested by the applications and
ultimately consumed by them. The only real reason to do
this at the TLS layer is the sense that it's easier to deploy.
I'm not actually convinced that that's so, since this approach
still requires modifying the applications to request security
the signature/evidence services.

In addition, putting this functionality at the TLS layer embodies
some not-so-attractive tradeoffs, in particular, that the
binding of application-layer messages to the actual evidence
provided isn't particularly tight, since the signatures cover extents
of the traffic rather than messages. This introduces a number of
race conditions which are only partially solved by the
interlocking alerts used here. Among these are:

 - The sender of the start1 alert has only minimal 
   information/control over when the peer will start signing traffic.
 - It's quite likely that one side will have to process messages
   without knowing whether the peer will actually sign his 
   section of the traffic. This is obviously a problem if you
   are producing side effects. You can mitigate this problem
   only by doing two evidence collections in lockstep.
 - Applications need a bunch of new logic to detect the evidence
   request but hold their response to application-layer boundaries.
   This cannot be implemented at the TLS layer.
 - If you want to condition your application-layer responses 
   to whether the peer provided a signature you need some way
   to provide application-layer "please resend with signature".
   This is a common case but can only be dealt with very
   clumsily here.

This seems like a fairly large architectural change to TLS to
make it do something it was never designed to do and which
can be done better in the application.

DETAILED COMMENTS
S 1.
It looks like the evidence creation has to involve signatures by
both parties. Why not have it be one-way.

S 1.2.
   Generating evidence is not compatible with Diffie-Hellman Ephemeral
   (DHE) key exchanges.  DHE does not permit the same keying material to
   be generated for validation of the evidence after the TLS session is
   over.  Persistent evidence requires the use of a digital signature so
   that it can be validated well after the TLS session is over.

Why not just store the traffic keys?

Figure 1 would be better with some markers about the traffic
segments that are signed.

S 2.
I'm uncomfortable with the idea if "evidence suites" and later
of new certificates and certificate negotiation. This seems
like you're layering an entirely new protocol over TLS.

S 3.
This consumes 4 new alerts. The space isn't that big.
Since you're already defining a new protocol type, these
messages might as well be part of that protocol.

S A.
Defining cipher suites with key lengths attached to them
isn't hte TLS way.

-Ekr

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls