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

[Martin Rex <[e-mail]>]

Mark Brown wrote:
> 
> After pointing out this unsolved problem for constructors of digital
> evidence, Kent then affirmed the convention of delegating this seemingly
> intractable problem to the application layer.  "Signing things for
> non-repudiation is usually an application-layer issue..."

Correct.

Choose between CMS & S/MIME, signed XML and maybe GSSAPI-IDUP
if you're looking for standards how to put digital signatures
on actual content, rather than TLS, who has a option to use
a digital signature as a proof for possession of a private
key as a method for online authentication.


> (http://www3.ietf.org/proceedings/05nov/tls.html )  Which is a pretty
> sensible approach, I think.  But to be perfectly honest, isn't "application
> layer" here a code word for "let them figure it out, we're not going to
> waste any more time on this problem"?
> 
> But now TLS Evidence can solve the "signer's intent" problems, and it
> requires two parties, implying a network protocol connecting two parties.

TLS Evidence can NOT solve the signer's intent problems, it is in the
worst possible position to do so, right above the bits-on-the-wire.

Most protocol stacks have several protocol layers in between, carrying
data that is produced by software rather rather than users and users
never get to know what amounts of protocol framing and auxiliary data
the different layers of the software stack are going to put in there.
They don't even know whether, when they are shown a popup window
with "OK" and "Cancel", what will be sent over the communication
channel -- is it "OK", or "0" or "0xff3456ab" or "button 0x200".
The signer's intent is extremely sensitive to the context,
and TLS has nothing to do whatsoever with the UIs -- which are
going to have a significant impact on the users intent.
And user shouldn't have to know or care about that.

If users are expected to digitally sign actual meaningful content
rather than producing evidence for possession/knowledge of a (private) key,
then they better know every single bit that gets signed.

IMHO TLS MUST NOT have access to keying material that vouches for
anything else than "private key present".  The purpose of TLS is online
authentication, and the users private key is used to process
arbitrary data as seen fit by the underlying authentication protocol.


I'm firmly opposed to the TLS Evidence proposal.


> 
> 2. What if in the scenario above the transmission is the acceptance of a
> relatively small contract that, in its fine print, grants a huge amount of
> intellectual property rights to the military?  And later the contractor
> wants to repudiate the signature, claiming that the transaction was a
> forgery?

If you need a contract sign, just do it.  There have been perfectly
working schemes to do contracts for centuries.  Many do not require
computers or the internet, and everyone knows how to handle them.
You certainly do not need TLS contortions in order to do contracts.

Think about what you propose: you're seriously suggesting that
click-through-licenses are a good idea.  I'm violently opposed to
this.  Fortunately German jurisdiction has been considering
click-through licenses nul and void, and I certainly do not
want that to change.


Think about the much more dangerous use of this.  Currently there
are public forums operated by big companies (Microsoft,Google,etc.)
and at least some of them have "terms of use" (subject to change
without prior notice) which is supposed to transfer your IP to
them for everything that you write/post/upload.   

Click-through licenses are evil, and I don't want to see an
IETF working group pushing click-through licensing scheme.


>
> If only the high-assurance server signed the evidence then the
> contractor can say that someone else initiated that transaction,
> and the burden of proof rests on the military.

As I mentioned, we don't have to reinvent the wheel -- the world
has been successfully doing contracts before the internet, and
with concepts every adult is accustomed to.


I don't know how you think applications are being built today,
but the application area that I know keeps adding protocol
layers between the wire-level and the presentation layer
(what the user really gets to see) like crazy.
TLS is just above the network layer, hidden under several
abstractions and resource-managed by the middleware.

When the middleware feels like it (or when there's some
network hickup) the network connection may be dropped and
the TLS connection interrupted.  Depending on the
protocol layers in the middleware and the requirements
of the application, the communication channel will
be automatically reconnected and the TLS secure channel
automatically re-established, transparent and unnoticed
by the "application" in many scenarios.


-Martin

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls