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

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 6 Aug 2013 20:32:47 +0000

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.

=====
(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

=====
(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?

=====
(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></HashInformation>

=====
(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?
** The schema comments suggest measuring files in Kb.  If we do that, how do we represent file sizes less than a Kb?

=====
(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?

=====
(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? 

** 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 
** 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>

====
(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.

Roman

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 7 Aug 2013 03:28:16 +0000

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!

PK> I think this class is like the ContactMeansType or IncidentID class in 5060.
<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.

=====

PK> I am not sure about the point of the validity since I don't see why an invalid sig would be carried in IODEF.

=====

PK> Sounds goos to me.

=====

PK> I think the watchlist names were addede for the predicate logic that you mentioned, unless I am mistaken. 
PK> I will try to address your last email about predicate logic soon.

=====

The schema says:

** 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.

=====

>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 w…

PK> I was under the impression that ds:Signature or ds:KeyInfo with ds:Reference could express certs for XML sigs in http://www.w3.org/2000/09/xmldsig# 

=====

<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.
** If any of the values of @type with email in them are chosen, and a FileName is provided, what does that mean?  For example:

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.

====

<RecordData>
   <HashInformation>

PK> A text revision would clarify it a little, but I think it can be done.

PK> Panos

Roman
_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 7 Aug 2013 13:15:11 +0000

Thanks Katheleen.

Two quick answers.  Agreed on the rest.

KM> I am not following why the ContactMeansType is part of this question
PK> I put it in there as an example of an existing place in 5070 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 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,

-----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!

PK> I think this class is like the ContactMeansType or IncidentID 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.  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>

KM> I am not following why the ContactMeansType is part of this question?

=====

PK> I am not sure about the point of the validity since I don't see why an invalid sig would be carried in IODEF.
KM> If you have an incident that involves a digital signature that 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.

=====

PK> Sounds goos to me.
KM> Please correct it to make it consistent, thanks.

=====

PK> I think the watchlist names were addede for the predicate logic 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.

=====

The schema says:

KM> +1

=====

>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 w…

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 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.

=====

<HashInformation>
</HashInformation>

** 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 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:

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 container in case there is no signature?

====

<RecordData>
   <HashInformation>

KM> +1

PK> Panos
KM> Thank you, Kathleen

Roman

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 7 Aug 2013 09:16:16 -0400

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.

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)

Thank you,
Kathleen

Hi Roman,

-----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!

=====

=====

PK> Sounds goos to me.

=====

=====

The schema says:

=====

=====

<HashInformation>
</HashInformation>

====

<RecordData>
   <HashInformation>

PK> Panos
KM> Thank you, Kathleen

Roman

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 7 Aug 2013 09:06:10 -0400

Thank you,
Kathleen

Hi Roman,

-----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!

=====

=====

PK> Sounds goos to me.

=====

=====

The schema says:

=====

=====

<HashInformation>
</HashInformation>

====

<RecordData>
   <HashInformation>

PK> Panos
KM> Thank you, Kathleen

Roman

---

From: "Harrington, Christopher" <[email-masked]>
Date: Wed, 7 Aug 2013 10:03:29 -0400

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

Thanks Katheleen.

KM> I am not following why the ContactMeansType is part of this question
PK> I put it in there as an example of an existing place in 5070 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 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)

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,

-----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.

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 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.  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.

=====

There is no text in the document on this attribute.  Comments in the schema
read as follows:

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 why an
invalid sig would be carried in IODEF.
KM> If you have an incident that involves a digital signature that 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.

=====

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.

=====
(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.

<HashInformation
type="file_hash"><FileName>foo-file</FileName></HashInformation>
<HashInformation
type="file_hash_watchlist"><FileName>foo-file</FileName></HashInformation>

PK> I think the watchlist names were addede for the predicate logic 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.

=====

The type of FileName and FileSize are not defined in the text.  I'd propose
the following:

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

=====

>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 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.

=====

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 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:

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 container in
case there is no signature?

====

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>

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> Panos
KM> Thank you, Kathleen

Roman

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 7 Aug 2013 17:01:26 +0000

> 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:

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

-----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!

Thank you!
Kathleen

Thanks Katheleen.

KM> I am not following why the ContactMeansType is part of this question
PK> I put it in there as an example of an existing place in 5070 were 
PK> 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 there 
KM> 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)

Thank you,
Kathleen

Hi Roman,

-----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!

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"/>".

PK> I think this class is like the ContactMeansType or IncidentID class 
PK> 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.

=====

PK> I am not sure about the point of the validity since I don't see why 
PK> an
invalid sig would be carried in IODEF.
KM> If you have an incident that involves a digital signature that does 
KM> 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.

=====

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.

=====

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.

<HashInformation

PK> I think the watchlist names were addede for the predicate logic that 
PK> 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.

=====

The schema says:

=====

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 and 
KM> +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.

=====

<HashInformation>
</HashInformation>

** 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:

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 container 
KM> +in
case there is no signature?

====

<RecordData>
   <HashInformation>

PK> Panos
KM> Thank you, Kathleen

Roman

* Christopher Harrington <[email-masked]>
* Issuer: RSA Security LLC - Unverified

---

From: Neil Hare-Brown <[email-masked]>
Date: Wed, 7 Aug 2013 23:13:25 +0100

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

> Others - please chime in on the questions for this message and the scope message for IODEF v2.

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.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 7 Aug 2013 18:43:32 -0400

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

Rgds

Neil HB

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 8 Aug 2013 19:36:29 +0000

RFC6545 assumes encapsulation of IODEF in RID.  What if IODEF is used outside of RID? How would the "seal" get addressed then?

Dave

> Sent: Wednesday, August 07, 2013 6:44 PM
> To: Neil Hare-Brown; Panos Kampanakis (pkampana)
> Cc: [email-masked]
> 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
> 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
> 
> >> 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.
> > 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
> the hash of a file (MD5, SHA-1, etc.) and the PKI / PGP hashes. I see there is a
> Boolean for Valid:
> >
> > 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.
> > 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
> > GSO - Critical Incident Response Center EMC - Where Information Lives
> > 174 Middlesex Turnpike
> > Bedford, MA 01730
> > 781-515-5862 (work)
> > 603-583-1585 (cell)
> >
> > KM> I am not following why the ContactMeansType is part of this
> > KM> question
> > 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
> > 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
> > PK> I think this class is like the ContactMeansType or IncidentID
> > PK> class in
> > 5060.
> > PK> I am not sure about the point of the validity since I don't see
> > PK> why an
> > KM> If you have an incident that involves a digital signature that
> > KM> does not
> > The HashInformation@type attribute has a number of multi-word
> enumerated values separated by an underscore and the "ext-value" using a
> hyphen.
> > 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.
> > 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
> > 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
> > ** The schema comments suggest measuring files in Kb.  If we do that,
> how do we represent file sizes less than a Kb?
> > 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?
> >
> 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
> > ** 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
> 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.
>

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 8 Aug 2013 15:46:59 -0400

Hi Dave,

Changing the subject to avoid confusion on the threads in case others want to weigh in on the HashInformation class questions for IODEF.

You can reference a specific section of an RFC and not use the full standard.  If RID is not used as a transport, the policy and/or object security could still be applied to IODEF if appropriate.  For instance, if you were to use ROLIE (or some other transport), it points to the RID data model for policy information and could also use section 9.1 for object security (I don't think that is called out explicitly at the moment).  I think this would work fine, but if something needs to get fixed and there are real applications of the object security in use outside of RID, then we can adjust those to meet the community needs through consensus.

Thanks,
Kathleen
________________________________________
From: Waltermire, David A. [[email-masked]]
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)

Dave

> question?

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 9 Aug 2013 21:05:25 +0000

Hello!

> 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.
> 

I think we have a very simply editorial issue to fix.  In the schema, some complex elements are defined inline, others reference a previously defined type.  HashInformation is the name of the XML element, and the name that should be used for the corresponding UML class.  HashSigDetails (or iodef:HashSigDetails) is the type referenced for the element HashInformation (i.e., <xs:element name="HashInformation" type="HashSigDetails" ...).  The XML type was mistakenly added as the UML class name.  The reference to ContactMeansType is to cite another example where a XML complex type used to define elements like Email, Telephone, etc.

It seems like we're all saying the same thing.  Fix the incorrect text.  No change in the schema.

[snip]

> 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.
> 

I figured they were for predicate logic.  However, I'm still wondering if these are equivalent XML snippets. 
 
> ** Do we need ML_STRING for FileName?

Could you talk through a bit why you think it should be ML_STRING.  All you get for using MLStringType vs. xs:string is an extra attribute to express language (@lang).  Do you envision populating that information?  

> PK> I suggest PositiveFloatType or  xs:float and the number expressing KB.

Could either of you talk through the reasoning behind representing a data value that's inherently an integer as something other than that.  I ask because would have proposed defining it as a type="xs:nonNegativeInteger".

> 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
> 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

I agree with both of you that the combination of ds:Signature, ds:KeyInfo, and ds:Reference elements can represent a TLS certificate.  However, the HashInformation@type attribute restricts the semantics of these classes to either (1) a signature on a file or email (PKI_*_ds, PGP_*_ds), or (2) a hash of the contents of an email or file (*_hash).  I don't believe that any of these existing attribute values would be appropriate for a server certificate.  It would appear that we need to add more enumerated values.

> KM> +1.  In working through examples, I think we had come up with reasons
> to use a few options.  This may depend on just needing the hash information

I was primarily envisioning the simplest of use cases: a file or email hash list.  Aren't the three things I need only algorithm, hash result, identifier for the thing I hashed?

Not to be too precise about it, but the name **Hash**Information as a descriptive element name only applies to the minority of @types.

> 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.

What about Message-ID instead of Subject? Or Both? 

I'm also a little leery of overloading the meaning of an element named FileName.

> case there is no signature?

That's where I was heading with my question.  What are the possible circumstances?

Roman

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 9 Aug 2013 21:18:17 +0000

Hi Roman,

> Could you talk through a bit why you think it should be ML_STRING.  All you get for using MLStringType vs. xs:string is an extra attribute to express language (@lang).  Do you envision populating t…

To be honest, I don't know, but I can imagine files with weird language names. 

> Could either of you talk through the reasoning behind representing a data value that's inherently an integer as something other than that.  I ask because would have proposed defining it as a type="…

I was thinking since that viruses are usually pretty small files, maybe KB floting point granularity couyld identify

> That's where I was heading with my question.  What are the possible circumstances?

Hmm, renaming the FileName to something more general that could also fit email identifier deosn't seem like a bad idea to me.

Panos

-----Original Message-----
From: Roman D. Danyliw [mailto:[email-masked]] 
Sent: Friday, August 09, 2013 5:05 PM
To: Moriarty, Kathleen; Panos Kampanakis (pkampana); [email-masked]
Subject: RE: Clarity on HashInformation (or HashSigDetails)

Hello!

> 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
> a Section 3.21 named Hash Sig Details.  Section 4.4 of draft-ietf-mile-iodef-guidance-01 refers
> Unless someone disagrees, I think there are a few typos in Section 
> 3.21 and HashInformation is the class name.
> 
> I understand that the extra type " HashSigDetails " can be removed and 
> the "HashInformation" class contain the attributes and elements though.

[snip]

> 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.
> 
> <HashInformation type="file_hash"><FileName>foo- 
> file</FileName></HashInformation> <HashInformation 
> file</FileName></HashInformation>
> 

> The type of FileName and FileSize are not defined in the text.  I'd 
> propose the
> following:
> 

> 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?
> 
> 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.

> 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?
> KM> +reasons
> (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.

> PK> I think that should be illegal. Only file ds should have 
> PK> filenames. Maybe

Roman

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Wed, 21 Aug 2013 14:19:48 +0000

Hi Panos!

> From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
> Sent: Friday, August 09, 2013 5:18 PM
> To: Roman D. Danyliw; Moriarty, Kathleen; [email-masked]
> > Could you talk through a bit why you think it should be ML_STRING.  All you
> get for using MLStringType vs. xs:string is an extra attribute to express
> language (@lang).  Do you envision populating that information?
> 

Understood.  You can represent strange language names with just xs:string. What you're saying is you would like to also convey the analyst's insight into what language it is, ala

<FileName lang="strange">some-strange-filename.evil</FileName>

> > Could either of you talk through the reasoning behind representing a data
> value that's inherently an integer as something other than that.  I ask because
> would have proposed defining it as a type="xs:nonNegativeInteger".
> 

I don't mean to belabor the point, but can you help us understand the algorithm that needs a floating point value to find small files.  Why can't you do it with an integer? I'm pushing back here because the no transform on a file 

> Hmm, renaming the FileName to something more general that could also fit
> email identifier deosn't seem like a bad idea to me.

Agreed, let's track the gap at http://trac.tools.ietf.org/wg/mile/trac/ticket/20

Roman