[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    RE: [SPAM] RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to
From:       "John Bito" <jwb () qpass ! com>
Date:       2007-01-11 18:18:04
Message-ID: 0275263AA36EE748891F00F36BB9563B015096FD () seamail1 ! corp ! amdocs ! com
[Download RAW message or body]

Metadata is a registered trademark of the Metadata Company.  Perhaps you
are concerned about data descriptors or attributes that are local or
specific to the system that that created the data.  I view these as the
responsibility of a data description and structuring technology (RDF,
XML, XML-Signature); not the transport (TLS).

-----Original Message-----
From: Mark Brown [mailto:mark@redphonesecurity.com] 
Sent: Thursday, January 11, 2007 10:02 AM
To: martin.rex@sap.com; tls@ietf.org
Subject: [SPAM] RE: [TLS] Please discuss:
draft-housley-evidence-extns-00 - use to

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:martin.rex@sap.com]
> Sent: Thursday, January 11, 2007 10:42 AM
> To: Mark Brown
> Cc: home_pw@msn.com; tls@ietf.org; DPKemp@missi.ncsc.mil
> 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
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls

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



[prev in list] [next in list] [prev in thread] [next in thread]