<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hi Yingdi,</div>
<div><br>
</div>
<div>If the application uses a truncated key digest (e.g. the first 4 bytes of the digest), do you think we can still use the KeyDigest field? Or, if we treat the truncated key digest as a KeyId and put it in a Name, should the spec suggest a format for the
Name? </div>
<div><br>
</div>
<div>- Jeff T</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; 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>Yingdi Yu <<a href="mailto:yingdi@cs.ucla.edu">yingdi@cs.ucla.edu</a>><br>
<span style="font-weight:bold">Date: </span>Friday, June 5, 2015 at 17:58<br>
<span style="font-weight:bold">To: </span>Marc Mosko <<a href="mailto:Marc.Mosko@parc.com">Marc.Mosko@parc.com</a>><br>
<span style="font-weight:bold">Cc: </span>Jeff Thompson <<a href="mailto:jefft0@remap.ucla.edu">jefft0@remap.ucla.edu</a>>, "<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>" <<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256?<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
I would prefer to explicitly state in the spec that, for HMAC signature, validating implementation should look up keys in local symmetric key storage.
<div class=""><br class="">
</div>
<div class="">If we restrict the usage of KeyLocator of HMAC to local lookup, we can use Name as KeyId (in KeyLocator). I do not think KeyDigest would be very useful, but if a data producer really wants to use KeyDigest as a KeyLocator, the definition JeffT
made in the first mail should be fine. </div>
<div class="">
<div class=""><br class="">
</div>
<div class="">
<div apple-content-edited="true" class=""><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class="">
<div class="">Yingdi</div>
</div>
</span></span></div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jun 2, 2015, at 10:14 AM, <a href="mailto:Marc.Mosko@parc.com" class="">
Marc.Mosko@parc.com</a> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
My concern with using the Name in a KeyLocator is that some implementations will start sending an Interest for the name, which is the normal thing to do for a Name in a KeyLocator. If there is some way to clearly indicate in this case the name it is non-routable
and that its purpose is to identify a KeyId, that would be ok. I understand that should be implicit from the SignatureType being HMAC….
<div class=""><br class="">
</div>
<div class="">From the spec on SignatureInfo, one reads:</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class=""><span style="color: rgb(34, 34, 34); font-family: 'Helvetica Neue', Helvetica, Helvetica, Arial, sans-serif; line-height: 22.4000015258789px; widows: 1; background-color: rgb(255, 255, 255);" class="">The specific definition
of the usage of </span><tt class="literal docutils" style="margin: 0px; padding: 1px; box-sizing: border-box; color: rgb(34, 34, 34); line-height: 22.4000015258789px; widows: 1; background-color: rgb(238, 238, 236);"><span class="pre" style="margin: 0px; padding: 0px; box-sizing: border-box;">Name</span></tt><span style="color: rgb(34, 34, 34); font-family: 'Helvetica Neue', Helvetica, Helvetica, Arial, sans-serif; line-height: 22.4000015258789px; widows: 1; background-color: rgb(255, 255, 255);" class=""> and </span><tt class="literal docutils" style="margin: 0px; padding: 1px; box-sizing: border-box; color: rgb(34, 34, 34); line-height: 22.4000015258789px; widows: 1; background-color: rgb(238, 238, 236);"><span class="pre" style="margin: 0px; padding: 0px; box-sizing: border-box;">KeyDigest</span></tt><span style="color: rgb(34, 34, 34); font-family: 'Helvetica Neue', Helvetica, Helvetica, Arial, sans-serif; line-height: 22.4000015258789px; widows: 1; background-color: rgb(255, 255, 255);" class=""> options
in </span><tt class="literal docutils" style="margin: 0px; padding: 1px; box-sizing: border-box; color: rgb(34, 34, 34); line-height: 22.4000015258789px; widows: 1; background-color: rgb(238, 238, 236);"><span class="pre" style="margin: 0px; padding: 0px; box-sizing: border-box;">KeyLocator</span></tt><span style="color: rgb(34, 34, 34); font-family: 'Helvetica Neue', Helvetica, Helvetica, Arial, sans-serif; line-height: 22.4000015258789px; widows: 1; background-color: rgb(255, 255, 255);" class=""> field
is outside the scope of this specification. Generally, </span><tt class="literal docutils" style="margin: 0px; padding: 1px; box-sizing: border-box; color: rgb(34, 34, 34); line-height: 22.4000015258789px; widows: 1; background-color: rgb(238, 238, 236);"><span class="pre" style="margin: 0px; padding: 0px; box-sizing: border-box;">Name</span></tt><span style="color: rgb(34, 34, 34); font-family: 'Helvetica Neue', Helvetica, Helvetica, Arial, sans-serif; line-height: 22.4000015258789px; widows: 1; background-color: rgb(255, 255, 255);" class=""> names
the Data packet with the corresponding certificate. However, it is up to the specific trust model to define whether this name is a full name of the Data packet or a prefix that can match multiple Data packets. For example, the hierarchical trust model </span><a class="internal reference" href="http://named-data.net/doc/ndn-tlv/signature.html#testbed-key-management" style="margin: 0px; padding: 0px; box-sizing: border-box; color: rgb(253, 120, 0); text-decoration: none; line-height: 22.4000015258789px; font-family: 'Helvetica Neue', Helvetica, Helvetica, Arial, sans-serif; widows: 1; background-color: rgb(255, 255, 255);">[1]</a><span style="color: rgb(34, 34, 34); font-family: 'Helvetica Neue', Helvetica, Helvetica, Arial, sans-serif; line-height: 22.4000015258789px; widows: 1; background-color: rgb(255, 255, 255);" class=""> uses
the latter approach, requiring clients to fetch the latest version of the Data packet pointed by the KeyLocator (the latest version of the public key certificate) in order to ensure that the public key was not yet revoked.</span></blockquote>
</div>
<div class=""><br class="">
</div>
<div class="">So that does not really allow the third option that the Name does not specify any Data packet but rather names a KeyId.</div>
<div class=""><br class="">
</div>
<div class="">Marc</div>
<div class=""><br class="">
<div class="">
<div class="">On Jun 2, 2015, at 6:05 PM, Thompson, Jeff <<a href="mailto:jefft0@remap.ucla.edu" class="">jefft0@remap.ucla.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class="">
<div class="">Hi Marc,</div>
<div class=""><br class="">
</div>
<div class="">As I asked Gene, to avoid expanding the definition of KeyLocator, it is possible to use a local/relative sense of a Name for the Key ID?</div>
<div class=""><br class="">
</div>
<div class="">- Jeff T</div>
<div class=""><br class="">
</div>
<span id="OLK_SRC_BODY_SECTION" class="">
<div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class="">
<span style="font-weight:bold" class="">From: </span>"<a href="mailto:Marc.Mosko@parc.com" class="">Marc.Mosko@parc.com</a>" <<a href="mailto:Marc.Mosko@parc.com" class="">Marc.Mosko@parc.com</a>><br class="">
<span style="font-weight:bold" class="">Date: </span>Monday, June 1, 2015 at 14:32<br class="">
<span style="font-weight:bold" class="">To: </span>Jeff Thompson <<a href="mailto:jefft0@remap.ucla.edu" class="">jefft0@remap.ucla.edu</a>><br class="">
<span style="font-weight:bold" class="">Cc: </span>"<a href="mailto:christian.tschudin@unibas.ch" class="">christian.tschudin@unibas.ch</a>" <<a href="mailto:christian.tschudin@unibas.ch" class="">christian.tschudin@unibas.ch</a>>, "<a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a>"
<<a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a>><br class="">
<span style="font-weight:bold" class="">Subject: </span>Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256?<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
I think overloading the use of a Name to avoid overloading the use of KeyDigest is trading one thing for another. If the Name is only an SPI (32-bit integer), for example, then its not really a name either as it cannot be fetched.
<div class=""><br class="">
</div>
<div class="">I agree that if KeyDigest is defined as the SHA256 of something (as it is in the ndn spec), then its not the right container for an index, and possibly not the right container for a truncated digest. </div>
<div class=""><br class="">
</div>
<div class="">To avoid mis-using a Name and mis-using a KeyDigest, then it looks like one would need to introduce a new TLV container “KeyIndex” or something like that to accommodate negotiated key IDs in a key exchange protocol.</div>
<div class=""><br class="">
</div>
<div class="">To accomodate truncated KeyDigest, one could use a new container. However, if it is a truncated SHA256, then I think it would be obvious that it is only the “length” bytes of the SHA256, not the full 32-bytes. I could see allowing a shorter
(left truncated) SHA256 in the KeyDigest without loss of specificity.</div>
<div class=""><br class="">
</div>
<div class="">Marc</div>
<div class=""><br class="">
<div class="">
<div class="">On Jun 1, 2015, at 7:42 PM, Thompson, Jeff <<a href="mailto:jefft0@remap.ucla.edu" class="">jefft0@remap.ucla.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite" class="">
<div style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">
Hi Christian and Marc,<br class="">
<br class="">
I think we agree that we'll spell out how to get the key digest from the<br class="">
Key, but not spell out the HMAC algorithm itself (or how Key is padded to<br class="">
make the internally-used KeyValue).<br class="">
<br class="">
If the applications want to use an integer identifier for the Key, then<br class="">
the KeyLocator would need to be a Name with the integer as a name<br class="">
component, right? <br class="">
<br class="">
Also, if the "truncated key digest" (maybe as short as a byte) is used as<br class="">
an identifier, I wonder whether this should be in a Name too. This way,<br class="">
we don't mess with the semantics of KeyDigest which usually means the full<br class="">
digest. What do you think?<br class="">
<br class="">
Thanks,<br class="">
- Jeff T<br class="">
<br class="">
On 2015/6/1, 9:48, "<a href="mailto:christian.tschudin@unibas.ch" class="">christian.tschudin@unibas.ch</a>"<br class="">
<<a href="mailto:christian.tschudin@unibas.ch" class="">christian.tschudin@unibas.ch</a>> wrote:<br class="">
<br class="">
<blockquote type="cite" class="">I understood Jeff wanting to make the spec as self-contained as<br class="">
possible, but I doubt that a reference to an HMAC-internal variable is<br class="">
helping.<br class="">
<br class="">
(It translate into "Dear NDN implementor, to implement this two-line<br class="">
feature you need to read the following RFC and locate that Keyval<br class="">
variable in your favorit shrinked-wrapped library." As a probe: the<br class="">
Python hashlib API page does not reference it).<br class="">
<br class="">
So better write at least that part out?<br class="">
<br class="">
Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it<br class="">
make sense to point out the many possibilities to pick your way. At<br class="">
least an advantage of the currently discussed hashing approach would<br class="">
be to not add another document to read 8-)<br class="">
<br class="">
best, c<br class="">
<br class="">
<br class="">
On Mon, 1 Jun 2015, <a href="mailto:Marc.Mosko@parc.com" class="">Marc.Mosko@parc.com</a> wrote:<br class="">
<br class="">
<blockquote type="cite" class="">The proposed spec already defines KeyValue as the right-padded (for<br class="">
short keys) or sha256 (for long keys) of the Key. I would define the<br class="">
KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used<br class="">
to compute KeyValue.<br class="">
<br class="">
With regard to repeating the definition of HMAC, I would not do that<br class="">
but simply say that the Œtext¹ input to HMAC is {Name, MetaInfo,<br class="">
Content, SignatureInfo} TLVs.<br class="">
<br class="">
For symmetric key systems, like HMAC, I think it is also acceptable to<br class="">
use an agreed upon integer identifier for the shared secret, as<br class="">
determined by a key exchange protocol (e.g. an ISAKMP SPI). I don¹t<br class="">
think that symmetric key KeyDigests need to be derived from the key.<br class="">
That¹s different than public key systems, where the the KeyDigest is<br class="">
used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from<br class="">
the actual public key.<br class="">
<br class="">
Marc<br class="">
<br class="">
On Jun 1, 2015, at 1:45 PM, <<a href="mailto:christian.tschudin@unibas.ch" class="">christian.tschudin@unibas.ch</a>><br class="">
<<a href="mailto:christian.tschudin@unibas.ch" class="">christian.tschudin@unibas.ch</a>> wrote:<br class="">
<br class="">
<blockquote type="cite" class="">On Wed, 27 May 2015, Thompson, Jeff wrote:<br class="">
<br class="">
<blockquote type="cite" class="">Hello Christian,<br class="">
Two questions:<br class="">
1. Can you repeat your suggestion that the spec allow a truncated<br class="">
form of the key digest, for example the first 8 bytes of the key<br class="">
digest instead of the full 32 bytes?<br class="">
</blockquote>
<br class="">
Hi Jeff,<br class="">
<br class="">
This is a trick that Marc Mosko used when we presented the 1+0<br class="">
encoding at the January ICNRG interim meeting: Just reduce then number<br class="">
of KeyID-Bits (2 Bytes, in our case), if need be.<br class="">
<br class="">
The observation is that the key digest is for convenience, not<br class="">
security reasons: If you have many parties for which you have to<br class="">
maintain different symmetric keys, it is nice to quickly identify which<br class="">
key to use for validating the signature. But theoretically, you could<br class="">
just try out all symmetric keys you have for some peer. Rivest's<br class="">
"chaffing and winnowing" even relies on not sending any KeyID bits, on<br class="">
purpose.<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">2. If you want this suggestion on the spec, what is the best way to<br class="">
describe the computation of the key digest if we don't describe the<br class="">
HMAC algorithm in the spec?<br class="">
</blockquote>
<br class="">
First, it could be made optional. But then I think it would be good to<br class="">
write down how the digest is computed, as you suggest (because RFC 2104<br class="">
does not cover it, right?)<br class="">
<br class="">
Adapted from previous text of yours:<br class="">
<br class="">
"The Key must not be included in the signature but optionally a full<br class="">
or partial KeyDigest can be put in the KeyLocator block of the<br class="">
SignatureInfo field. If the byte length of Key is less than or equal to<br class="">
the SHA256 block length (64 bytes) then the full length KeyDigest is<br class="">
SHA256(Key). But if the byte length of Key is greater than 64 bytes,<br class="">
the KeyValue is already SHA256(Key) with zeros appended, so in this<br class="">
case the full length KeyDigest is SHA256(SHA256(Key)). The optional<br class="">
KeyDigest bits consist of 2 to 32 of the most-significant (=left-most)<br class="">
bytes of the full length KeyDigest. For the convenience of the<br class="">
validator and if packet size permits, it is recommended to include the<br class="">
full 32 bytes."<br class="">
<br class="">
Would that be precise enough?<br class="">
<br class="">
best, c<br class="">
<br class="">
<blockquote type="cite" class="">Thanks,<br class="">
- Jeff T<br class="">
From: Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" class="">shijunxiao@email.arizona.edu</a>><br class="">
Date: Wednesday, May 27, 2015 at 5:10<br class="">
To: Jeff Thompson <<a href="mailto:jefft0@remap.ucla.edu" class="">jefft0@remap.ucla.edu</a>><br class="">
Cc: "<a href="mailto:ndn-interest@lists.cs.ucla.edu" class="">ndn-interest@lists.cs.ucla.edu</a>" <<a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a>><br class="">
Subject: Re: [Ndn-interest] Describe the HMAC algorithm in<br class="">
SignatureHmacWithSha256?<br class="">
Dear folks<br class="">
Details about HMAC algorithm, or any other crypto algorithm, SHOULD<br class="">
NOT appear in NDN Packet Format<br class="">
spec.<br class="">
Instead, the implementer should be referred to RFC.<br class="">
Those details are duplication of RFC, and they would make the spec<br class="">
unnecessary long.<br class="">
They also increase the probability of incorrect implementations<br class="">
because the implementer is unsure<br class="">
whether it's exactly same as what she/he has in the library, and<br class="">
would have to implement it again.<br class="">
"don't have HMAC in their crypto library" is not a valid argument -<br class="">
it's easier to find an<br class="">
RFC-compliant library or snippet for most languages than to implement<br class="">
according to the (duplicate of<br class="">
RFC in) spec.<br class="">
Yours, Junxiao<br class="">
On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff<br class="">
<<a href="mailto:jefft0@remap.ucla.edu" class="">jefft0@remap.ucla.edu</a>> wrote:<br class="">
The proposed SignatureHmacWithSha256 spec (below) repeats the<br class="">
details of the HMAC<br class="">
algorithm from RFC 2104. But should the details be removed and<br class="">
just refer to RFC 2104?<br class="">
Arguments for keeping the details are that it provides details<br class="">
for the discussion of<br class="">
creating the KeyDIgest and also because some applications don't<br class="">
have HMAC in their crypto<br class="">
library and need to implement it directly. An argument against<br class="">
keeping the details is that<br class="">
the info is in RFC 2104 so an application writer can read the<br class="">
RFC if needed, and that we<br class="">
don't repeat the details of other algorithms like SHA-256.<br class="">
Any opinions on removing the algorithm details?<br class="">
- Jeff T<br class="">
<br class="">
</blockquote>
_______________________________________________<br class="">
Ndn-interest mailing list<br class="">
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a><br class="">
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a></blockquote>
</blockquote>
</blockquote>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</span></div>
</blockquote>
</div>
<br class="">
</div>
</div>
_______________________________________________<br class="">
Ndn-interest mailing list<br class="">
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a><br class="">
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
</span>
</body>
</html>