<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body ocsi="0" fpstyle="1" style="word-wrap:break-word; color:rgb(0,0,0); font-size:18px; font-family:Calibri,sans-serif">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;"><font size="2"><font face="Arial">Thanks everyone!<br>
<br>
First off, sorry that I wasn't clear, yes, this implementation ingests the block content and leaves the headers in the clear. I wanted to work with something simple and standard (MD5/AES), but it should certainly be possible to use ECDSA or some other ECC.
<b>Please give me suggestions for new digests, encryptions, etc to try out, I would be happy to do so</b>.<br>
<br>
I also want to say right off of the get-go that there is an opportunity for interoperability between CMS and SBSP, the exact interaction between these things is an undefined topic. We certainly can dig into the block processing trenches. Other possible implementations
include:<br>
</font></font>
<ul>
<li><font size="2"><font face="Arial">the use of SBSP as a method to define CMS - This lends itself to the idea of interoperability.<br>
</font></font></li><li><font size="2"><font face="Arial">A protected range of EID's (ipn:x.443, anyone!) - This is technically simple, but may be a political maelstrom.<br>
</font></font></li><li><font size="2"><font face="Arial">BiB - To steal Keiths phrasing, at the liberty of punctuation: "tunneling and we're done."<br>
</font></font></li></ul>
<p><font size="2"><font face="Arial">or some combination of these.Going back to the overhead concern for a minute, I propose looking towards IP, in the sense that there are multiple security-related protocols and encapsulations, each with unique strengths and
weaknesses. For example, CMS, while it has higher overhead, also allows nested operations, is readily supported by CryptLib and OpenSSL, and may be appropriate for non-bandwidth-constrained environments, and/or those with heavy-duty PKI infrastructures, such
as the smartcard users. Meanwhile SBSP is extremely lean and well-suited to sensor networks, or deep-space. I am 110% of the opinion that it should be possible to bridge CMS and SBSP, allowing bundles signed or encrypted in one to get verified or decrypted
in another, at least with a baseline level of functionality. Also, I don't want to throw away everyones work on SBSP; we have more to bring to the table this way.
<br>
</font></font></p>
<p><font size="2"><font face="Arial"><br>
</font></font></p>
<p><font size="2"><font face="Arial">I can't think of anything else off of the top of my head, but keep 'em coming and thanks again,</font></font></p>
<p><font size="2"><font face="Arial">Jeremy<br>
</font></font></p>
<p><font size="2"><font face="Arial"><br>
</font></font></p>
<p><font size="2"><font face="Arial"><br>
</font></font></p>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF466517"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Scott, Keith L. [kscott@mitre.org]<br>
<b>Sent:</b> Tuesday, June 30, 2015 7:48 PM<br>
<b>To:</b> Weiss, Howard; Mayer, Jeremy; sis-dtn@mailman.ccsds.org; Stephen Farrell; Edward Birrane<br>
<b>Subject:</b> Re: [Sis-dtn] Bundle Signing And Encryption With CMS<br>
</font><br>
</div>
<div></div>
<div>
<div>
<div>Seconded, thanks Jeremy!</div>
<div><br>
</div>
<div>I think our big question is how to structure the security encapsulation(s), in particular where the CMS ‘wrapper’ bits show up w.r.t. the block header and block content. As I understand it, your payload implementation is essentially the ‘CMS wraps block
content’ approach and you just know at the receiver to undo that on receipt. Ed had some concerns about the ‘XXX eats block’ approach and in particular what happens when I want to assign the integrity value HERE and implement confidentiality over THERE. I’d
like to fully understand those, especially in light of CMS’ explicit ability to allow nested operations.</div>
<div><br>
</div>
<div>Just to suggest an approach, what if we go with the ‘CMS Eats block content’ approach and (as I think Scott suggested) snag a bit in the block processing control flags (ok, thereby increasing it to two bytes, ugh!) to indicate that the block content is
‘security-enabled’ (i.e. A CMS-wrapped thing). The CMS structure has an object identifier that identifies the content information type, and the intro to the RFC explicitly talks about nested operations, so we could impose integrity and security separately;
we use Bundle-in-bundle-encapsulation (pronounced ‘tunneling’) to decouple routing and we’re done except for the primary bundle block (because it needs its own separate bit flag definition, and because we need to deal with mutability there).</div>
<div><br>
</div>
<div>Pros</div>
<ul>
<li>overall bundle block structure left alone</li><li>allows for per-block granularity</li><li>Could implement ‘outer’ signatures of all blocks for BAB-like service?</li></ul>
<div>Cons</div>
<ul>
<li>per-block overhead
<ul>
<li>It seems like it would be worth investigating a CMS implementation / cipher suite so that multiple CMS-protected blocks referenced some sort of common block containing key material, but such a block type would be easy enough to define, I’d think.</li></ul>
</li><li>‘BAB-like’ signature applied separately to all blocks would increase overhead (even with a ‘common key material’ block type) — argues for ‘secure CL’ approach?</li><li>Content types are OIDs in the 1.2.840.113549.1 space (overhead)</li></ul>
<div><br>
</div>
<div>If we were to like this (or, more specifically, whatever we DO end up liking) I think we then need to try real hard to sell that to the IETF, and preferably before they get too far down the path of security protocol definition. Either we’re right and
they’ll like it too or we’re missing something…</div>
<div><br>
</div>
<div><br>
</div>
<div>I found <a href="http://www.vocal.com/secure-communication/cryptographic-message-syntax-cms/" target="_blank">
this link</a> (with the pictures below) sort of helpful.</div>
<div><br>
</div>
<blockquote style="margin:0 0 0 40px; border:none; padding:0px">
<div><img src="cid:AD041825-176D-4A51-A66D-AA86CB16F0BC" type="image/png" height="388.000000" width="618.000000"></div>
<div><br>
</div>
</blockquote>
<div><span class="Apple-tab-span" style="white-space:pre"></span>—keith</div>
<div><br>
</div>
<div>
<div id="MAC_OUTLOOK_SIGNATURE"></div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:12pt; text-align:left; color:black; border-bottom:medium none; border-left:medium none; padding-bottom:0in; padding-left:0in; padding-right:0in; border-top:#b5c4df 1pt solid; border-right:medium none; padding-top:3pt">
<span style="font-weight:bold">From: </span>"<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a>" on behalf of Howie Weiss<br>
<span style="font-weight:bold">Date: </span>Tuesday, June 30, 2015 at 8:34 AM<br>
<span style="font-weight:bold">To: </span>Jeremy Pierce-Mayer, "<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>"<br>
<span style="font-weight:bold">Subject: </span>RE: [Sis-dtn] Bundle Signing And Encryption With CMS<br>
</div>
<div><br>
</div>
<div dir="ltr"><style id="owaParaStyle" type="text/css">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
BODY {direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;}P {margin-top:0;margin-bottom:0;}BODY {scrollbar-base-color:undefined;scrollbar-highlight-color:undefined;scrollbar-darkshadow-color:undefined;scrollbar-track-color:undefined;scrollbar-arrow-color:undefined}BODY {scrollbar-base-color:undefined;scrollbar-highlight-color:undefined;scrollbar-darkshadow-color:undefined;scrollbar-track-color:undefined;scrollbar-arrow-color:undefined}BODY {scrollbar-base-color:undefined;scrollbar-highlight-color:undefined;scrollbar-darkshadow-color:undefined;scrollbar-track-color:undefined;scrollbar-arrow-color:undefined}BODY {scrollbar-base-color:undefined;scrollbar-highlight-color:undefined;scrollbar-darkshadow-color:undefined;scrollbar-track-color:undefined;scrollbar-arrow-color:undefined}BODY {scrollbar-base-color:undefined;scrollbar-highlight-color:undefined;scrollbar-darkshadow-color:undefined;scrollbar-track-color:undefined;scrollbar-arrow-color:undefined}BODY {scrollbar-base-color:undefined;scrollbar-highlight-color:undefined;scrollbar-darkshadow-color:undefined;scrollbar-track-color:undefined;scrollbar-arrow-color:undefined}BODY {scrollbar-base-color:undefined;scrollbar-highlight-color:undefined;scrollbar-darkshadow-color:undefined;scrollbar-track-color:undefined;scrollbar-arrow-color:undefined}BODY {scrollbar-base-color:undefined;scrollbar-highlight-color:undefined;scrollbar-darkshadow-color:undefined;scrollbar-track-color:undefined;scrollbar-arrow-color:undefined}</style>
<div>
<div style="direction:ltr; font-family:Tahoma; color:#000000; font-size:10pt">Jeremy<br>
<br>
This is very cool! Thanks for spinning this up so quickly. Its very neat that you could use an off-the-shelf standard and open source software to provide bundle security services in such an expedited manner. And the fact that the overheads are not bad makes
it even nicer.<br>
<br>
Regards<br>
<br>
howie<br>
<div><br>
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px"><font style="font-family:Verdana" size="2"><span style="font-weight:bold"><br>
</span></font>
<hr style="width:100%; height:2px">
<font style="font-family:Verdana" size="2"><span style="font-weight:bold"></span></font><span style="font-weight:bold">Howard Weiss</span><br>
<font size="1">Technical Director</font><br>
<br>
<font size="1"><font size="2"><span style="font-weight:bold">PARSONS</span></font><br>
7110 Samuel Morse Drive<br>
Columbia, MD 21046<br>
443-430-8089 (office)<br>
410-262-1479 (cell)<br>
443-430-8238 (fax)<br>
<a href="mailto:howard.weiss@parsons.com" target="_blank">howard.weiss@parsons.com</a><br>
www.parsons.com<br>
<br>
<span style="color:rgb(51,153,102)">Please consider the environment before printing this message</span></font><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div style="font-family:Times New Roman; color:#000000; font-size:16px">
<hr tabindex="-1">
<div id="divRpF275448" style="direction:ltr"><font color="#000000" face="Tahoma" size="2"><b>From:</b>
<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a> [<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a>] on behalf of Jeremy Pierce-Mayer [<a href="mailto:jeremy.mayer@dlr.de" target="_blank">jeremy.mayer@dlr.de</a>]<br>
<b>Sent:</b> Tuesday, June 30, 2015 6:02 AM<br>
<b>To:</b> <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> [Sis-dtn] Bundle Signing And Encryption With CMS<br>
</font><br>
</div>
<div></div>
<div>
<div><font face="Arial" size="2">Hey Everyone,</font></div>
<div><font face="Arial" size="2"></font> </div>
<div><font face="Arial" size="2">During the Bundle Security telecom last week, I took the action to wedge the Cryptographic Message Syntax (CMS) into BP, for use in signing and encryption. Here are the results:</font></div>
<div><font face="Arial" size="2"></font> </div>
<div><strong><font face="Arial" size="2">Software Implementation:</font></strong></div>
<div><font face="Arial" size="2">For this testing, I used a random payload, passed that through the CMS implementation (OpenSSL), using a pre-shared 1024b RSA key in an X509 certificate. The enveloped data was outputted in DER encoding (Base64)<strong>.
</strong>It is important to note that this is not S-MIME. The DER-ified data was added as a bundle payload.
</font><font face="Arial" size="2">For future testing, it should be possible</font> <font face="Arial" size="2">to update (or dynamically generate) the X509 stuff, where we can set the FROM/TO addressed to the src/dest EID's.
</font></div>
<div><font face="Arial" size="2"></font> </div>
<div><font face="Arial" size="2">I ran two tests, signing and verification...</font></div>
<div><font face="Arial" size="2"></font> </div>
<div><strong><font face="Arial" size="2">Measurement Methodology:</font></strong></div>
<div><strong><font face="Arial" size="2"></font></strong> </div>
<div><font face="Arial" size="2">All of the numbers below were taken from the receiver side. In other words, the "pre-signing/encryption" sizes were based upon successfully decrypting or verifying the data at the end of the pipe.</font></div>
<div><font face="Arial" size="2"></font> </div>
<div><strong><font face="Arial" size="2">Results - Signing:</font></strong></div>
<img src="cid:788143909@30062015-3797">
<div><font face="Arial" size="2"></font> </div>
<div><font face="Arial" size="2">There are two subtests here, one where I carried the CMS signer cert within the data, and one where I didn't. As you can see, the overhead isn't terrible, especially when you consider that (in some of the tests) I was carrying
the cert down the wire. You can also stack signer certificates within a single CMS message, though I opted to not do that (for simplicity) until we have a further plan for CMS.</font></div>
<div><font face="Arial" size="2"></font> </div>
<div><strong><font face="Arial" size="2">Results - Encryption:</font></strong></div>
<div><font face="Arial" size="2">I'm going to prefix this by saying that I really didn't need a graph for this one, but graphs are cool, and if I write enough here, it will look like a proper headline... So, graphs:</font></div>
<div><img src="cid:788143909@30062015-379E"></div>
<div><font face="Arial" size="2"></font> </div>
<div><font face="Arial" size="2">Once again, the overhead isn't awful, at <strong>
349</strong> bytes.</font></div>
<div><font face="Arial" size="2"></font> </div>
<div><strong><font face="Arial" size="2">Where Do We Go From Here:</font></strong></div>
<div><font face="Arial" size="2">I have no idea, though I'm tempted to say that this is a discussion for Darmstadt.</font></div>
<div><font face="Arial" size="2"></font> </div>
<div><font face="Arial" size="2"></font> </div>
</div>
</div>
</div>
</div>
</div>
</span></div>
</div>
</div>
</body>
</html>