RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to

["Mark Brown" <[e-mail]>]

Martin,

Metadata is not esoteric.  Nearly every file system and storage format (from
file systems to file formats to databases) uses metadata.  "Metadata" does
include mundane things like file name, path to file,
owner/originator/author, last update, access control lists, etc.  Metadata
is increasingly (has always been?) recognized as useful in COTSs.

It is nearly universal that if you move data from one file system or format
to another, metadata gets wiped out, then recreated.  Just ftp a file.
During the ftp, original metadata gets stripped out and lost (though it is
often recreated with new values).  I'm saying that it could be valuable to
share metadata from one system to another, and TLS Evidence could be used to
provide assurance for it.  For example, party A could create a purchase
order for a system.  Party B could receive that purchase order and assemble
the ordered system from parts.  Party B might share TLS Evidence together
with party A's purchase order with suppliers C, D, E.  The suppliers might
find value in being assured that the purchase order originated with A and
has not been altered.

I see no gap between the concepts I've described and the systems we're using
today.  I think it's useful to have some assurance for metadata and/or data
in a transmission between systems (for example over an untrusted network,
which is common when using TLS).  Sometimes it's nice to know that the data
hasn't changed since you received it.  I don't think that's esoteric.

The system that creates TLS Evidence's second signature doesn't need to be
esoteric either; simple separation (i.e. the fact that the TLS client and
server don't have the same private keys) is often sufficient.  In a
commercial setting, "assurance" is more loosely defined than with the
military's EALs.  That's fine.  If someone uses a "secure" (not "highly
assured") TLS implementation to create TLS Evidence, they may be perfectly
happy with the level of assurance that the system provides.

Regarding the "secret cellar where it comes from," TLS Evidence is not dark;
I'm obviously publishing my designs.  My personal background is probably
irrelevant, but I've never worked for any part of any federal government
prior to my involvement on the US Navy contract acknowledged in the I-D.  To
date I exclusively use COTS and I interact freely on the 'net.  RedPhone
Security proposed determining "if a low-assurance encryption protocol
implementation can feasibly deliver messages while assuring system-wide
message integrity," which is not incompatible with an Open Source software
protocol implementation.  

--mark

> -----Original Message-----
> From: Martin Rex [mailto:[e-mail]]
> Sent: Thursday, January 11, 2007 10:42 AM
> To: Mark Brown
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use
> to
> 
> Thank your for your explanations.
> 
> I don't understand why this proposal is brought to the IETF.
> 
> From what I read, the IETF originally started out with government
> funding, an a large part came from the department of defense.
> The IPv4 spec says something like there was a secretive variant
> of IP(v4) with support for all the esoteric stuff that you
> are talking about for use in the military and by secretive agencies.
> The academic and public wasn't bothered with any of this.
> 
> 
> Today, the IETF is an open international forum and producing
> standards for use in COTS (commercial of the shelf) software and
> Open Source, for the masses (private and business use).
> 
> There is a huge gap between the concepts that you described
> and the software that we're using today, at home and in the office
> --it's not even in the same galaxy.
> 
> 
> I think you should carry this proposal and the concepts back down
> into the secret cellar where it comes from, and where those guys
> dwell who believe that they need it, and that they continue
> playing on their own.  They probably need multi-level security
> in order to contain the evidence why something fucked up, who was
> responsible and who else knew about it.
> 
> 
> In the IETF we should try to produce standards for the needs of
> the general public and remain on a level playing field with
> e.g. the IETF apps area.  For years they have been complaining
> that IETF security protocols are already to difficult and too
> complex for them, and there is some truth in it, they are
> already pretty secure and pretty complex.
> 
> 
> A chain is only as strong as its weakest link, and the TLS Evidence
> proposal is such an enormous and heavy link, it is going to rip
> this chain apart all alone by its own weight.
> 
> 
> -Martin


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