<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML dir=ltr><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 11.00.9600.17842"></HEAD>
<BODY
style="WORD-WRAP: break-word; FONT-SIZE: 18px; FONT-FAMILY: Calibri,sans-serif; COLOR: rgb(0,0,0)"
fpstyle="1" ocsi="0">
<DIV dir=ltr align=left><SPAN class=163340313-01072015><FONT size=2
face=Arial>I've been playing with ECDSA for signing, using the NIST 256-bit
curve.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=163340313-01072015><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=163340313-01072015><FONT size=2
face=Arial>With the certificate included in the CMS data: The overhead is 961
bytes. Without it, the overhead is 487 bytes, a small improvement, but an
improvement nonetheless.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=163340313-01072015><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=163340313-01072015><FONT size=2
face=Arial>Thanks,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=163340313-01072015><FONT size=2
face=Arial>Jeremy</FONT></SPAN></DIV><BR>
<DIV lang=en-us class=OutlookMessageHeader dir=ltr align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> sis-dtn-bounces@mailman.ccsds.org
[mailto:sis-dtn-bounces@mailman.ccsds.org] <B>On Behalf Of
</B>Jeremy.Mayer@dlr.de<BR><B>Sent:</B> Dienstag, 30. Juni 2015
21:24<BR><B>To:</B> kscott@mitre.org; Howard.Weiss@parsons.com;
sis-dtn@mailman.ccsds.org; stephen.farrell@cs.tcd.ie;
Edward.Birrane@jhuapl.edu<BR><B>Subject:</B> RE: [Sis-dtn] Bundle Signing And
Encryption With CMS<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV
style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma; COLOR: #000000; DIRECTION: ltr"><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><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><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-SIZE: 16px; FONT-FAMILY: Times New Roman; COLOR: #000000">
<HR tabIndex=-1>
<DIV id=divRpF466517 style="DIRECTION: ltr"><FONT size=2
face=Tahoma><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>allows for per-block granularity
<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>‘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>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="BORDER-TOP: medium none; BORDER-RIGHT: medium none; BORDER-BOTTOM: medium none; PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px 0px 0px 40px; BORDER-LEFT: medium none; PADDING-RIGHT: 0px">
<DIV><IMG src="cid:163340313@01072015-29EF" width=618 height=388
type="image/png"></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-SIZE: 12pt; BORDER-TOP: #b5c4df 1pt solid; FONT-FAMILY: Calibri; BORDER-RIGHT: medium none; BORDER-BOTTOM: medium none; COLOR: black; PADDING-BOTTOM: 0in; TEXT-ALIGN: left; PADDING-TOP: 3pt; PADDING-LEFT: 0in; BORDER-LEFT: medium none; PADDING-RIGHT: 0in"><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="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma; COLOR: #000000; DIRECTION: ltr">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-SIZE: 13px; FONT-FAMILY: Tahoma">
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: Tahoma">
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: Tahoma">
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: Tahoma">
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: Tahoma">
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: Tahoma">
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: Tahoma">
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: Tahoma">
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: Tahoma">
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: Tahoma"><FONT
style="FONT-FAMILY: Verdana" size=2><SPAN
style="FONT-WEIGHT: bold"><BR></SPAN></FONT>
<HR style="HEIGHT: 2px; WIDTH: 100%">
<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-SIZE: 16px; FONT-FAMILY: Times New Roman; COLOR: #000000">
<HR tabIndex=-1>
<DIV id=divRpF275448 style="DIRECTION: ltr"><FONT color=#000000 size=2
face=Tahoma><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 size=2 face=Arial>Hey Everyone,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>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 size=2 face=Arial></FONT> </DIV>
<DIV><STRONG><FONT size=2 face=Arial>Software
Implementation:</FONT></STRONG></DIV>
<DIV><FONT size=2 face=Arial>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 size=2 face=Arial>For
future testing, it should be possible</FONT> <FONT size=2 face=Arial>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 size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>I ran two tests, signing and
verification...</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><STRONG><FONT size=2 face=Arial>Measurement
Methodology:</FONT></STRONG></DIV>
<DIV><STRONG><FONT size=2 face=Arial></FONT></STRONG> </DIV>
<DIV><FONT size=2 face=Arial>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 size=2 face=Arial></FONT> </DIV>
<DIV><STRONG><FONT size=2 face=Arial>Results -
Signing:</FONT></STRONG></DIV><IMG src="cid:163340313@01072015-29F6">
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>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 size=2 face=Arial></FONT> </DIV>
<DIV><STRONG><FONT size=2 face=Arial>Results - Encryption:</FONT></STRONG></DIV>
<DIV><FONT size=2 face=Arial>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:163340313@01072015-29FD"></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Once again, the overhead isn't awful, at
<STRONG>349</STRONG> bytes.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><STRONG><FONT size=2 face=Arial>Where Do We Go From
Here:</FONT></STRONG></DIV>
<DIV><FONT size=2 face=Arial>I have no idea, though I'm tempted to say that this
is a discussion for Darmstadt.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2
face=Arial></FONT> </DIV></DIV></DIV></DIV></DIV></DIV></SPAN></DIV></DIV></DIV></BODY></HTML>