Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails)

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 3 Jan 2014 14:43:14 +0000

Hello all and Happy New Year!

I wanted to revisit this old thread and bring closure to Dave's question since we're tracking it as Issue #29 (http://trac.tools.ietf.org/wg/mile/trac/ticket/29).  Any thoughts?

Roman

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Waltermire, David A.
> Sent: Thursday, August 08, 2013 3:36 PM
> To: Moriarty, Kathleen; Neil Hare-Brown; Panos Kampanakis (pkampana)
> Cc: [email-masked]
> Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails)
> 
> RFC6545 assumes encapsulation of IODEF in RID.  What if IODEF is used
> outside of RID? How would the "seal" get addressed then?
> 
> Dave
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Moriarty, Kathleen
> > Sent: Wednesday, August 07, 2013 6:44 PM
> > To: Neil Hare-Brown; Panos Kampanakis (pkampana)
> > Cc: [email-masked]
> > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails)
> >
> > Hi Neil,
> >
> > Thanks for chiming in.  The 'seal' is covered in RID RFC6545 section
> > 9.1 through the use of object level security triggered by the
> > restriction attribute setting.  If you want to discuss that more, we
> > can start a new thread so folks can continue on the hash information in the
> data model.
> >
> > Thanks!
> > Kathleen
> > ________________________________________
> > From: Neil Hare-Brown [[email-masked]]
> > Sent: Wednesday, August 07, 2013 6:13 PM
> > To: Panos Kampanakis (pkampana)
> > Cc: Harrington, Christopher; Moriarty, Kathleen; Roman D. Danyliw;
> > [email-masked]
> > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails)
> >
> > Agreed
> >
> > There should also be a feature that is a sealing hash (of hashes) so
> > that an evidential bundle is maintained as inviolate.
> >
> > Rgds
> >
> > Neil HB
> >
> > On 7 Aug 2013, at 21:48, "Panos Kampanakis (pkampana)"
> > <[email-masked]> wrote:
> >
> > >> Can this be applied more than once per file depending on which type
> > >> of
> > hash you are checking?  I can have a digitally signed executable where
> > the
> > MD5 hash of the file is Valid but the signing cert (or CA) is revoked.
> > Another common scenario is to attach digital signature from a
> > legitimately signed file to a malicious file hoping that the receiving
> > party will just see a signature from a trusted CA and not re-compute
> > the signature. There is one threat actor we track who uses this fairly
> frequently. How would those be handled?
> > >
> > > Agreed. I think the schema currently can support multiple signatures
> > > per
> > file. So, IMO that can be done. Put MD5 and PKI sigs for the same
> > filename in the same IODEF. Using the watchlist attricbutes the
> > predicate AND logic can be enforced also.
> > >
> > >> Another area of possible concern is required fields. If the
> > >> indicator is a file
> > hash then the hashing algorithm (MD5, SHA-1, etc.) should be required.
> > > I've never seen a file hash provided as an indicator without the hash type.
> > > For any ds:Signature references there should be a ds:Reference, when
> > these are file hashes. I don't think the hash type would be required
> > for ds:KeyInfo as this never used as an indicator by itself, unlike file hash.
> > >
> > > I agree. I think type should be required in the HashSigDetails.
> > >
> > > Panos
> > >
> > >
> > > -----Original Message-----
> > > From: Harrington, Christopher
> > > [mailto:[email-masked]]
> > > Sent: Wednesday, August 07, 2013 10:03 AM
> > > To: Moriarty, Kathleen; Panos Kampanakis (pkampana); Roman D.
> > > Danyliw; [email-masked]
> > > Subject: RE: Clarity on HashInformation (or HashSigDetails)
> > >
> > > * PGP - S/MIME Signed by an unverified key: 8/7/2013 at 10:03:29 AM
> > >
> > > To me this is a bit confusing when HashInformation is used to
> > > describe both
> > the hash of a file (MD5, SHA-1, etc.) and the PKI / PGP hashes. I see
> > there is a Boolean for Valid:
> > >
> > > | BOOL valid               |<>--{0..*}--[ds:Signature]
> > >
> > > Can this be applied more than once per file depending on which type
> > > of
> > hash you are checking?  I can have a digitally signed executable where
> > the
> > MD5 hash of the file is Valid but the signing cert (or CA) is revoked.
> > Another common scenario is to attach digital signature from a
> > legitimately signed file to a malicious file hoping that the receiving
> > party will just see a signature from a trusted CA and not re-compute
> > the signature. There is one threat actor we track who uses this fairly
> frequently. How would those be handled?
> > >
> > > Another area of possible concern is required fields. If the
> > > indicator is a file
> > hash then the hashing algorithm (MD5, SHA-1, etc.) should be required.
> > > I've never seen a file hash provided as an indicator without the hash type.
> > > For any ds:Signature references there should be a ds:Reference, when
> > these are file hashes. I don't think the hash type would be required
> > for ds:KeyInfo as this never used as an indicator by itself, unlike file hash.
> > >
> > >
> > > Thanks,
> > >
> > > --Chris
> > >
> > > Christopher Harrington
> > > Consulting Security Engineer
> > > GSO - Critical Incident Response Center EMC - Where Information
> > > Lives
> > > 174 Middlesex Turnpike
> > > Bedford, MA 01730
> > > 781-515-5862 (work)
> > > 603-583-1585 (cell)
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On Behalf
> > > Of Moriarty, Kathleen
> > > Sent: Wednesday, August 07, 2013 9:16 AM
> > > To: Panos Kampanakis (pkampana); Roman D. Danyliw; [email-masked]
> > > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails)
> > >
> > > Thanks, Panos!
> > >
> > > Others - please chime in on the questions for this message and the
> > > scope
> > message for IODEF v2.
> > >
> > > Thank you!
> > > Kathleen
> > > ________________________________________
> > > From: Panos Kampanakis (pkampana) [[email-masked]]
> > > Sent: Wednesday, August 07, 2013 9:15 AM
> > > To: Moriarty, Kathleen; Roman D. Danyliw; [email-masked]
> > > Subject: RE: Clarity on HashInformation (or HashSigDetails)
> > >
> > > Thanks Katheleen.
> > >
> > > Two quick answers.  Agreed on the rest.
> > >
> > > KM> I am not following why the ContactMeansType is part of this
> > > KM> question
> > > PK> I put it in there as an example of an existing place in 5070
> > > PK> were the
> > > same methodology is used. Just to make cleared that what we had in
> > > there
> > seemed correct as it is in other places.
> > >
> > > KM> do we need to have filename outside of the container in case
> > > KM> there is no
> > > signature?
> > > PK> Sound good.
> > >
> > > Panos
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Moriarty, Kathleen [mailto:[email-masked]]
> > > Sent: Wednesday, August 07, 2013 9:06 AM
> > > To: Panos Kampanakis (pkampana); Roman D. Danyliw; [email-masked]
> > > Subject: RE: Clarity on HashInformation (or HashSigDetails)
> > >
> > > Hi Roman, Panos, & others,
> > >
> > > Thanks for starting this discussion.  I'll answer below with KM> and
> > > with my
> > chair hat off as a participant.
> > >
> > > Others - please chime in and a +1 on sections if appropriate is good
> > > to let us
> > know there is agreement - or providing more detailed input otherwise.
> > >
> > > Thank you,
> > > Kathleen
> > > ________________________________________
> > > From: [email-masked] [[email-masked]] On Behalf Of
> > > Panos Kampanakis (pkampana) [[email-masked]]
> > > Sent: Tuesday, August 06, 2013 11:28 PM
> > > To: Roman D. Danyliw; [email-masked]
> > > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails)
> > >
> > > Hi Roman,
> > >
> > > Comments inline, search for PK>
> > >
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On Behalf
> > > Of Roman D. Danyliw
> > > Sent: Tuesday, August 06, 2013 4:33 PM
> > > To: [email-masked]
> > > Subject: [mile] Clarity on HashInformation (or HashSigDetails)
> > >
> > > Hello!
> > >
> > > I had a few questions about the HashInformation (HashSigDetails)
> > > class that
> > I wanted to discuss.
> > >
> > > (1) What's the correct name of the class?
> > >
> > > The diagram and text in 3.19.1, RecordData, calls it HashInformation.
> > > There is no such class further defined in the text.  However, there
> > > is a Section
> > > 3.21 named Hash Sig Details.  Section 4.4 of
> > > draft-ietf-mile-iodef-guidance-01 refers to a HashInformation class of
> type
> > > HashSigDetails.    As an aside, the draft-ietf-mile-iodef-guidance-01 also
> > > references that this class was derived from RFC5901 but only
> > > ds:Reference
> > is.
> > >
> > > The schema, the authoritative source, says "<xs:element
> > name="HashInformation" type="HashSigDetails" minOccurs="0"
> > > maxOccurs="unbounded"/>".
> > >
> > > Unless someone disagrees, I think there are a few typos in Section
> > > 3.21 and
> > HashInformation is the class name.
> > >
> > > PK> I think this class is like the ContactMeansType or IncidentID
> > > PK> class in
> > > 5060.
> > > HashInformation is of type HashSigDetails... the text should be corrected.
> > >
> > > KM> I would follow the schema and correct the text of the document.
> > > KM> There
> > > are 3 interoperable implementations (may be more) that use this
> > > schema
> > and the schema was authoritative.
> > >
> > > <xs:element name="Email" type="iodef:ContactMeansType"/>
> > <xs:complexType name="ContactMeansType">
> > >      <xs:simpleContent>
> > >
> > > The class ContactMeansType is of type ContactMeansType which can
> > consist of attributes and elements.
> > >
> > > I understand that the extra type " HashSigDetails " can be removed
> > > and the
> > "HashInformation" class contain the attributes and elements though.
> > > In other words I think it would indeed simplify the chema a little.
> > >
> > > KM> I am not following why the ContactMeansType is part of this
> > question?
> > >
> > > =====
> > > (2) What is the purpose of HashInformation@valid?
> > >
> > > There is no text in the document on this attribute.  Comments in the
> > schema read as follows:
> > >
> > > <!-- Adding a boolean yes/no, 0/1option to indicate if the
> > >        signature or hash is valid --> <xs:attribute name="valid"
> > > type="xs:boolean"
> > > use="optional"></xs:attribute>
> > >
> > > What's the scope of this validity?  A subset of possible items includes:
> > > ** the ds:Signature is valid on the HashInformation/FileName?
> > > ** The certificate chain in a given instance
> > > HashInformation/ds:KeyInfo is correct
> > >
> > > PK> I am not sure about the point of the validity since I don't see
> > > PK> why an
> > > invalid sig would be carried in IODEF.
> > > KM> If you have an incident that involves a digital signature that
> > > KM> does not
> > > validate, you will want to mark it as not validating or not being valid.
> > > Take for instance recent problems with digitally signatures on code.
> > > If
> > there was an attack that compromised a certificate or CA, then the
> > signature is no longer valid and may be something to look for on a
> > system that can check digital signature validity.  There are a few
> > recent examples where a cert was used when it was valid to sign code, but
> was revoked later.
> > >
> > > =====
> > > (3) Convention in separating multi-word enumerated values?
> > >
> > > The HashInformation@type attribute has a number of multi-word
> > enumerated values separated by an underscore and the "ext-value" using
> > a hyphen.
> > > Key@registrationaction also uses an underscore in the enumerated
> values.
> > > The use of an underscore for multi-word enumerated value is not
> > consistent with use of the hyphen elsewhere in the schema.  It's a
> > nit, but would make the schema look consistent.  Is there a reason not
> > to have this consistency?
> > >
> > > PK> Sounds goos to me.
> > > KM> Please correct it to make it consistent, thanks.
> > >
> > > =====
> > > (4) What's the difference between a HashInformation@type="*_ds" and
> > HashInformation@type="*_ds_watchlist"?
> > >
> > > For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds,
> > > PGP_file_ds, file_hash, email_hash} there is a corresponding
> > > enumerated value with the same name but an "_watchlist" appended to
> > > it (i.e., {PKI_email_ds_watchlist, PKI_file_ds_watchlist,
> > > PGP_email_ds_watchlist, PGP_file_ds_watchlist, file_hash_watchlist,
> > > email_hash_watchlist}).  The language in Section 4.4 of
> > > draft-ietf-mile-iodef-guidance-01 suggests this is to create
> > > predicate logic.  If that's the case, just as in the case of email
> > > thread about IP watchlists (see,
> > > http://www.ietf.org/mail-archive/web/mile/current/msg01145.html)
> > > could
> > the parsing logic rules please be explained.  Regardless of the
> > clarity provided in the guidance document, I feel like we're missing
> > adequate description in the data model.
> > >
> > > Are the following two equivalent:
> > >
> > > <HashInformation
> > > type="file_hash"><FileName>foo-file</FileName></HashInformation>
> > > <HashInformation
> > > type="file_hash_watchlist"><FileName>foo-
> > file</FileName></HashInformat
> > > ion>
> > >
> > > PK> I think the watchlist names were addede for the predicate logic
> > > PK> that you
> > > mentioned, unless I am mistaken.
> > > PK> I will try to address your last email about predicate logic soon.
> > > KM> I agree with Panos, this was for the predicate logic.
> > >
> > > =====
> > > (5) What are the types of FileName and FileSize?
> > >
> > > The type of FileName and FileSize are not defined in the text.  I'd
> > > propose
> > the following:
> > >
> > > FileName = STRING (Section 2.3)
> > > FileSize = INTEGER (Section 2.1), size of the file in bytes
> > >
> > > The schema says:
> > > <xs:element name="FileName" type="iodef:MLStringType"
> minOccurs="0"
> > > maxOccurs="unbounded"/>
> > > <!-- QUESTION: For FileSize, need to specify the unit this is provided in
> > >             assume kb? -->
> > > <xs:element name="FileSize" type="xs:integer" minOccurs="0"
> > > maxOccurs="unbounded"/>
> > >
> > > ** Do we need ML_STRING for FileName?
> > > PK> IMO yes
> > > ** The schema comments suggest measuring files in Kb.  If we do
> > > that,
> > how do we represent file sizes less than a Kb?
> > > PK> I suggest PositiveFloatType or  xs:float and the number expressing
> KB.
> > > KM> +1
> > >
> > > =====
> > > (6) What HashInformation@type should be used to convey a TLS
> > certificate?
> > >
> > > From
> > > http://www.ietf.org/mail-archive/web/mile/current/msg01148.html,
> > it was indicated that a TLS certificate or certificate chain could be
> > provided as an indicator.  Let's say it was related to a web-server.
> > What enumerate value should be used for the @type?
> > >
> > > PK> I was under the impression that ds:Signature or ds:KeyInfo with
> > > PK> ds:Reference could express certs for XML sigs in
> > > PK> http://www.w3.org/2000/09/xmldsig#
> > > KM> +1.  The thinking was to use KeyInfo as you can refernce this
> > > KM> +and other
> > > points directly within the W3C schema and it is already in a number
> > > of
> > libraries.  The other reason for using this is that it would be
> > maintained by the W3C and experts in that area.  As their work
> > evolves, we can continue to point to it and have up-to-date
> > capabilities without having to keep up on their developments or re-work
> the wheel.
> > >
> > > =====
> > > (7) What is the minimum contents of HashInformation?
> > >
> > > Under the present definition of the HashInformation class, the
> > > following
> > blank definition is legal:
> > >
> > > <HashInformation>
> > > </HashInformation>
> > >
> > > All the attributes and elements are optional in the schema and no
> > > further
> > parsing logic is defined in the text.  Do we want to make any of
> > contents mandatory?
> > > I think type should be required and either Signature or Reference
> > > should
> > also exist once.
> > >
> > >
> > > ** Does the choice of a particular @type value mandate a particular
> > > set of classes be used?  For example, if @type="PKI_email_ds" is
> > > set, can any guidance about whether ds:Reference, ds:Signature, or
> > > ds:KeyInfo
> > > PK> I think we can't be sure about it.
> > > KM> +1.  In working through examples, I think we had come up with
> > > KM> +reasons to
> > > use a few options.  This may depend on just needing the hash
> > > information
> > > (ds:Reference) or in other cases, you want the CA chaining
> > > information, so
> > you use ds:KeyInfo, or if you have even more detail, you start from
> > ds:Signature.
> > > ** If any of the values of @type with email in them are chosen, and
> > > a
> > FileName is provided, what does that mean?  For example:
> > >
> > > <HashInformation type="PKI_email_ds">  <FileName>my-
> file</FileName>
> > > <ds:Reference> ...
> > > </HashInformation>
> > >
> > > PK> I think that should be illegal. Only file ds should have filenames.
> > > Maybe for email we can have the "Filename" depict the email subject.
> > > KM> +1 - except - do we need to have filename outside of the
> > > KM> +container in
> > > case there is no signature?
> > >
> > >
> > > ====
> > > (8) Is the HashInformation the only way to list file indicators?
> > >
> > > What is the preferred way to list a given set of file names (not
> > > hashes) as
> > indicators?  Is the following the preferred method?
> > >
> > > <RecordData>
> > >   <HashInformation>
> > >     <FileName>my-file1</FileName>
> > >   </HashInformation>
> > >   <HashInformation>
> > >     <FileName>my-file2</FileName>
> > >   </HashInformation>   <HashInformation>
> > >     <FileName>my-file3</FileName>
> > >   </HashInformation>
> > > </RecordData>
> > >
> > > It strikes me if we do that, the text describing the HashInformation
> > > class,
> > "[t]his class are [sic] the hash and signature details that are needed
> > for providing context for indicators" would need to be revised.
> > >
> > > PK> A text revision would clarify it a little, but I think it can be done.
> > > KM> +1
> > >
> > > PK> Panos
> > > KM> Thank you, Kathleen
> > >
> > > Roman
> > > _______________________________________________
> > > mile mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mile
> > > _______________________________________________
> > > mile mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mile
> > >
> > >
> > > _______________________________________________
> > > mile mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mile
> > >
> > >
> > > * Christopher Harrington <[email-masked]>
> > > * Issuer: RSA Security LLC - Unverified
> > > _______________________________________________
> > > mile mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mile
> >
> > This email and any attachments are confidential and may also be
> > privileged. If you are not the named recipient, please notify the
> > sender immediately, and do not disclose the contents to another
> > person, use it for any purpose, or store, or copy the information in
> > any medium. Please also destroy and delete the message from your
> computer.
> >
> > _______________________________________________
> > mile mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mile
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 28 Jan 2014 02:25:16 +0000

Hello!

I'm again reposting this email and noting inline the items that still need to be discussed for HashInformation.  I've added two new issues as well.  Removed from this discuss is matter of defining the behavior of HashInformation@valid.  See http://www.ietf.org/mail-archive/web/mile/current/msg01161.html or Issue #26.

[snip]

> > > > From: [email-masked] [mailto:[email-masked]] On
> > > > Behalf Of Roman D. Danyliw

[snip]

> > > it was indicated that a TLS certificate or certificate chain could
> > > be provided as an indicator.  Let's say it was related to a web-server.
> > > > PK> I was under the impression that ds:Signature or ds:KeyInfo
> > > > PK> with ds:Reference could express certs for XML sigs in
> > > > points directly within the W3C schema and it is already in a
> > > > number of

RD> I'm not disputing that ds:Signature and ds:Keyinfo can represent a certification.  However, I am wondering what the enumerated value of the @type attribute would be if one passed such an indicator.  Likewise, what would FileName and FileSize mean in this context?

> > > > ** Does the choice of a particular @type value mandate a
> > > > particular set of classes be used?  For example, if
> > > > @type="PKI_email_ds" is set, can any guidance about whether
> > > > ds:Reference, ds:Signature, or ds:KeyInfo

RD> IMO, if the @type attribute dictates how ds:Keyinfo, ds:Signature, and ds:Reference should be interpreted, we need to provide specific guidance on a what they mean on a per enumerated value basis.  Otherwise, we are left in the situation described above where an empty HashInformation or  HashInformation@type="PKI_email_ds"/ds:Signature/ds:KeyInfo/ds:PGPData are valid.

> > > > ** If any of the values of @type with email in them are chosen,
> > > > and a

RD> This question highlights a bit of an inconsistency for me.  HashInformation is the only place to list filenames and associated hashes and signatures in a well-defined way.  However, this class also has support for email hashes and signatures, but not any other email information.  Email indicators that aren't hashes or signatures are listed in Services/EmailInfo.  Does that make sense to split email information in this ways?  

Brainstorming for a minute, would it make sense to have a multiple container classes, perhaps one for email and the other for files.  In each of these would be file/email specific information as well as the hash or signature information.  For example, add a stripped down version of HashInformation with just ds:{Signature,KeyInfo,Reference} and @type="*-email-*" to EmailInfo.  An equivalent could be made for file information.

[snip]

(9) The text of HashInformation@type="file-hash" reads "a file hash".  Do we need to say something about how this hash is computed?  Perhaps "a hash of the contents of the file".

(10) Same as #9, but on an email.  The text of HashInformation@type="email-hash" reads "an email hash".  Which part of the email?  Do we need to say something about how this hash is computed?