Re: [mile] Stephen Farrell's Discuss on draft-ietf-mile-rfc5070-bis-22: (with DISCUSS and COMMENT)
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 22 June 2016 19:51 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DC312D8E6; Wed, 22 Jun 2016 12:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1YXn2ewcVSW; Wed, 22 Jun 2016 12:51:31 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E56712D643; Wed, 22 Jun 2016 12:51:31 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id c2so46121271vkg.1; Wed, 22 Jun 2016 12:51:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xQvCt9QDUb3wAbM5cntZGopHo6SMol2cFpEsXtKo+iE=; b=0lsDQzPSsfXStpKXzIqlIam/DvVu27GZZonR3JUUWdTj3BPSuhzGuAyzsZsjl1AjP3 oC3greKGKyff6YRJgm5/XCxw9DcLWhVG2MdysulEaTj6hYVHTTiJrEDVC7A+qnYshpUd Nh7mnaPDAurUY8za2v0bbuKtJtTfIYQ5tu3XM84jLTtRmzw/eRR0vDLkhcDdM0tC8CjJ hjGVUywJwCPUOtHl0qbrHS5CLIlfaULhe87h/2tiMtMQOhEeLNW9VrZ+opKR3i0cADdY LaicNSnZ+p+HPYyLce2LC9PQ6ELF5hmryu6ttH1G27C3GpnKMIbes1YIKueY2TdUnJVW 36PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xQvCt9QDUb3wAbM5cntZGopHo6SMol2cFpEsXtKo+iE=; b=MOMipTZqMBHkDSw/s7EBgPJ2xaOfWbmIWtm7pKRCW2k3aX3GTrDIIU7A+pvjeRyiIP QIbdA3i6W3idFGYDw17PFf1WvKaroNXB5MvC0ThzUgjt8QV/mjEyll8yJNlaIJ/mSPSU tuvyqwRDFE9CmiOUsSYGDd3XWMyMh1Fw1g79V/N7+XP/Hg110uM1YX89f63Qds/0qVQL 5LbA+7n47z5Zjy7bjPIPstHRynTW4saxjoNlfs3f/mNWWmg/NmiY5fL1xWngZLJo6QuN SyoSVH26KwrWGAaGgsA6rM8IAYHoasyQLUWwHttQql7PfLG6wrbeq1beBPY+7nw+ZlcM xiQA==
X-Gm-Message-State: ALyK8tKtlCl6w1ev+++0wPXD8bbS1l23Hwmd94xCXgJv3JxzPQLmpdXNHH+i8XJbLEZDuk/NUE5pnkysJOorGg==
X-Received: by 10.176.69.196 with SMTP id u62mr13240318uau.111.1466625090316; Wed, 22 Jun 2016 12:51:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.236 with HTTP; Wed, 22 Jun 2016 12:51:29 -0700 (PDT)
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD97669C8@marathon>
References: <20160601234150.16188.9970.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFCD974F737@marathon> <5750568A.7020302@cs.tcd.ie> <359EC4B99E040048A7131E0F4E113AFCD97669C8@marathon>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Wed, 22 Jun 2016 15:51:29 -0400
Message-ID: <CAHbuEH4=EagGms97_fZDnc0KROBnnO50jtawTNhZFssVgRCj8g@mail.gmail.com>
To: "Roman D. Danyliw" <rdd@cert.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/Ht8WZgvPyc8aULaD8J3n16HAscs>
Cc: "mile-chairs@tools.ietf.org" <mile-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, "mile-chairs@ietf.org" <mile-chairs@ietf.org>, "mile@ietf.org" <mile@ietf.org>, "draft-ietf-mile-rfc5070-bis@ietf.org" <draft-ietf-mile-rfc5070-bis@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [mile] Stephen Farrell's Discuss on draft-ietf-mile-rfc5070-bis-22: (with DISCUSS and COMMENT)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2016 19:51:35 -0000
Hi Stephen, Do the updates address your concerns? Thanks! Kathleen On Mon, Jun 20, 2016 at 11:34 AM, Roman D. Danyliw <rdd@cert.org> wrote: > Hi Stephen! > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Thursday, June 02, 2016 11:54 AM >> To: Roman D. Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org> >> Cc: mile@ietf.org; draft-ietf-mile-rfc5070-bis@ietf.org; >> takeshi_takahashi@nict.go.jp; mile-chairs@ietf.org; mile- >> chairs@tools.ietf.org >> Subject: Re: Stephen Farrell's Discuss on draft-ietf-mile-rfc5070-bis-22: (with >> DISCUSS and COMMENT) >> >> >> Hiya, >> >> On 02/06/16 04:36, Roman D. Danyliw wrote: >> > Hello Stephen! >> > >> > Thanks for the review. A response to the DISCUSS and COMMENTs is >> > inline ... >> > >> >> -----Original Message----- From: Stephen Farrell >> >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, June 1, 2016 >> >> 7:42 PM To: The IESG <iesg@ietf.org> Cc: >> >> draft-ietf-mile-rfc5070-bis@ietf.org; Roman D. Danyliw >> >> <rdd@cert.org>; mile-chairs@tools.ietf.org; mile@ietf.org; >> >> mile-chairs@ietf.org; takeshi_takahashi@nict.go.jp; mile@ietf.org >> >> Subject: Stephen Farrell's Discuss on >> >> draft-ietf-mile-rfc5070-bis-22: (with DISCUSS and COMMENT) >> > >> > [snip] >> > >> >> ---------------------------------------------------------------------- >> >> >> >> >> DISCUSS: >> >> ---------------------------------------------------------------------- >> >> >> >> >> >> >> (1) 3.6: Does one confidence value apply to all of these? >> >> That seems wrong. And over-confidence is attributing threat actor >> >> identity is a real issue with real consequences, hence the discuss >> >> to make sure we bottom out on this. I think it's just too >> >> error-prone to be ablve to associate one confidence value with two >> >> things about which one can have very different concreteness. Mixing >> >> up high confidence in a campaign with a lack of confidence in >> >> threat actor identification is precisely the kind of thing that >> >> goes wrong, or that could be deliberately manipulated (for >> >> eventual media/marketing reasons). (This overlaps with but isn't >> >> quite the same as Alissa's 2nd discuss point. In this case, I'm >> >> explicitly worried about the threat actor identity confidence, as >> >> that has possibly severe impacts, so the resolution here could >> >> differ from what results from Alissa's discuss.) >> > >> > The RelatedActivity class (Section 3.6) does have the ability to >> > provide a single confidence value on all of the child classes in it. >> > Per your example, yes, a single confidence value could be made both >> > on the campaign and the actor. However, if more granularity was >> > desired, one can express different confidence values for both the >> > campaign and actor as follows (ThreatActor with low confidence but >> > the Campaign with high confidence): >> > >> > <Incident ...> ... <RelatedActivity> <ThreatActor>...</ThreatActor> >> > <Confidence rating="low" /> </RelatedActivity> <RelatedActivity> >> > <Campaign>...</Campaign> <Confidence rating="high"/> >> > </RelatedActivity> </Incident> >> >> Right, it's clear one can do the right thing, but it's not clear >> what semantics apply when one does not do that. You could address >> that in various ways, but I think in particular for the confidence/ >> threat-actor combination, the draft does need to say how to interpret >> whatever the document contains. > > The following was added to the Security Considerations of -23 to explicitly call out that confidence assessment should not necessarily be trusted. > > 9.1. Security > [snip] > An IODEF implementation may act on the data in the document. These > actions might be explicitly requested in the document or the result > of analytical logic that triggered on data in the document. ... > > The recipient may > interpret the contents of the document differently based on who sent > it; or vary actions based on the sender. While the sender of the > document may explicitly convey confidence in the data in a granular > way using the Confidence class, the recipient is free to ignore or > refine this information to make its own assessment. > > Certain classes may require out-of-band coordination to agree upon > their semantics (e.g., Confidence@rating="low" or DefinedCOA). This > coordination MUST occur prior to operational data exchange to prevent > the incorrect interpretation of these select data elements. When > parsing these data elements, implementations should validate, when > possible, that they conform to the agreed upon semantics. These > semantics may need to be periodically reevaluated. > >> >> (2) 3.18.1 - you provide a way to specify e.g. an address and >> >> netmask, or v6 prefix. But you don't specify any way to say that >> >> some of the address (or prefix) bits are not real or are >> >> additionally masked for privacy reasons. E.g. If everyone in >> >> 2001:1:1:beef::/64 is misbehaving, but I don't (yet) want to >> >> specify the exact prefix, I might want to say " some >> >> 2001:1:1:xxxx::/64" is misbehaving, meaning one /64 in >> >> 2001:1:1::/48 is being bad and not the entire /48. Why is support >> >> for that not required? (IPFIX does have that as an option, and >> >> it's been added to CDNI too.) Same idea can apply to other address >> >> forms too. >> > >> > Makes sense. A few new Address@category enumerated value can be >> > created, say "ipv6-net-sanitized" and "ipv4-net-sanitized" where "x" >> > has the significance of masking bits in an otherwise valid >> > address/prefix. >> >> So I think supporting something like that would be a good thing. If >> the WG consider it but decide to not add it, I'll just clear. > > The following was added to -23 to provide comparable capability: > > 3.18.1. Address Class > [snip] > 6. ipv4-net-masked. A sanitized IPv4 address with significant > bits per "ipv4-net" but with the character 'x' replacing any > digit(s) in the address or prefix. > [snip] > 10. ipv6-net-masked. A sanitized IPv6 address and prefix per > "ipv6-net" but with the character 'x' replacing any > hexadecimal digit(s) in the address or digit(s) in the > prefix. > >> >> ---------------------------------------------------------------------- >> >> >> >> >> COMMENT: >> >> ---------------------------------------------------------------------- >> >> >> >> >> >> >> >> >> - My review is based on [1] >> >> [1] >> >> https://tools.ietf.org/rfcdiff?url1=rfc5070&url2=draft-ietf-mile-rfc5070- >> bis-22 >> >> >> >> >> >> >> - "cyber" galore - yuk! Which of the fourteen (14!) uses of that ill-defined >> >> marketing term are useful or even well defined? RFC5070 had zero >> >> uses of such terms. Why is it a good plan for us to damage the RFC >> >> series via the use of such marketing nonsense? Someone may answer >> >> that this is accepted in industry these days, and that is true, but >> >> is nonetheless not a good enough reason for us to assist with the >> >> promulgation of anti-scientific non-concepts. My suggestion is to >> >> try s/cyber//g and then to see what if anything is less clear - >> >> perhaps we'll find that things are more clear. (And yes, it's a bit >> >> of a bugbear of mine:-) The use of "cyber indicator" instead of >> >> just "indicator" in 3.19 is a good example of how that phrase makes >> >> the spec less clear. >> > >> > Alissa commented on the same thing. Please see my response there >> > (https://www.ietf.org/mail-archive/web/mile/current/msg01886.html). >> > Long story short, IMO, there are a few instances where cyber is the >> > appropriate adjective (e.g., a "cyber-physical system"). > > This was cleaned up in -23. > > [snip] > >> >> - 2.8: So you don't like leap-seconds? It's often good to be clear >> >> if that bit of ABNF is expected to be enforced along with schema >> >> validation or not. >> > >> > As currently specified, if the schema is validated, this regex will >> > be enforced. It's baked into the schema with the iodef:TimezoneType. >> > Whether the schema should be validated is a separate issue that you >> > also brought up in another COMMENT (see below). >> >> That's fine - what about leap seconds? > > The regex in -23 was updated to be: > > <xs:simpleType name="TimezoneType"> > <xs:restriction base="xs:string"> > <xs:pattern > value="Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9](:[0-5][0-9])?"/> > >> >> The rest below is fine, >> Cheers, >> S. >> >> > >> >> - 2.12: What about EAI? >> > >> > Good point. I'll change the reference to RFC5336. > > The text in -23 now reads: > > 2.12. Email String > > An email address is represented in the information model by the EMAIL > data type. The format of the EMAIL data type is documented in > Section 3.4.1 of [RFC5322] and Section 3.3 of [RFC6531]. > >> >> - 3.13.1 - is CoA expanded somewhere? (See, I just looked at the >> >> diff:-) >> > >> > The write-up of the class in 3.13.1 says "DefinedCOA = Zero or more. >> > STRING. An identifier meaningful to the sender and recipient of this >> > document that references a course of action." I can make that >> > clearer by saying "... references a course of action (COA)". > > The text in -23 now reads: > > DefinedCOA > Zero or more. STRING. An identifier meaningful to the sender and > recipient of this document that references a course of action > (COA). This class MUST be present if the action attribute is set > to "defined-coa". > >> >> - 3.18.1 - I think it'd be good to refer to the RFC for wriing down >> >> IPv6 addresses and prefixes. I forget it's number though:-) And who >> >> uses ipv6- net-mask? Don't we all use prefixes? > > The text in -23 now reads: > > 8. ipv6-addr. IPv6 host address per Section 4 of [RFC5952]. > > 9. ipv6-net. IPv6 network address, slash, prefix per > Section 2.3 of [RFC4291]. > >> > Ipv6-net-mask is a hold over form rfc5070. I'll find the right >> > reference and drop it here. > > Yes, it was a cut-and-paste from RFC5070. Address@type="ipv6-net-mask" is now removed. > > [snip] > >> >> - 4.3 - I also think that recommending schema validation of input >> >> documents is a bad plan. (Even if that was already in 5070.) > > Schema validation is now just RECOMMENDED per -23. A full discussion as it relates to the security review is at: > > https://mailarchive.ietf.org/arch/msg/mile/cz8_ZoyVYZX88QUoqeEgZQFUrYE > > https://mailarchive.ietf.org/arch/msg/mile/uPHPtq_PvUvxKTP4jKA5x6_y2Jg > >> > Robert Sparks security review >> > (https://www.ietf.org/mail-archive/web/mile/current/msg01869.html) >> > and Alexey's review hinted at this issue but in the context of >> > dynamically generated schemas. I'll start the conversation on this >> > issue on that thread. > > The discussion and changes made in -23 to address the concerns with dynamically generated schemas can be found at: > > https://mailarchive.ietf.org/arch/msg/mile/cz8_ZoyVYZX88QUoqeEgZQFUrYE > > [snip] > >> >> - 9.1: you could not here the DoS and possible other attacks (e.g. >> >> spoofed .xsd files loaded over port 80) that follow on from on-line >> >> schema >> > >> > Good point. If the underlying schema is to be dynamically generated, >> > there is an IANA-to-schema-generator channel to secure that should be >> > covered here. This will need new text, the substance of which will >> > depend on the clarifying conversation that needs to happen on how >> > these dynamic updates should be handled. > > These is addressed in the links to the security review in the previous item. > > [snip] > > Thank you for the detailed review. > > Roman > -- Best regards, Kathleen
- Re: [mile] Stephen Farrell's Discuss on draft-iet… Kathleen Moriarty
- Re: [mile] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [mile] Stephen Farrell's Discuss on draft-iet… Roman D. Danyliw
- Re: [mile] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [mile] Stephen Farrell's Discuss on draft-iet… Roman D. Danyliw
- Re: [mile] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [mile] Stephen Farrell's Discuss on draft-iet… Kathleen Moriarty
- Re: [mile] Stephen Farrell's Discuss on draft-iet… Roman D. Danyliw
- Re: [mile] Stephen Farrell's Discuss on draft-iet… Kathleen Moriarty
- [mile] Stephen Farrell's Discuss on draft-ietf-mi… Stephen Farrell
- Re: [mile] Stephen Farrell's Discuss on draft-iet… Roman D. Danyliw
- Re: [mile] Stephen Farrell's Discuss on draft-iet… Stephen Farrell