| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Please complete this spreadsheet by July 9, 2018. To submit your entry, scroll right and add your votes/comments in the next available column... | Ballot 48 contents: | |||||||||||||||||
2 | ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance/CPs/Ballots/2019/Ballot_48/ | ||||||||||||||||||
3 | |||||||||||||||||||
4 | Organization--> | ICW | By Light | N. Harris Computer | Change HC | Philips | Arsenàl.IT | ASIP Santé | IntraHealth International, Inc. | ||||||||||
5 | Y/N/A | CP-ITI- | Descr. | Profile | Doc updated | Your name--> | Tarik Idris | John Moehrke | Elliott Lavy | Elliot Silver | Chris Melo | Gregorio Canal | Sylvie Colas | Luke Duncan | |||||
6 | 2/3/3 | 1094-08 | ATNA - Add Option: Require server certificate domain name validation for all traffic over the public internet | ATNA | Vol 1, 2a, ATNA-TI | Yes/Abstain/No: | Abstain | No | No | No | Abstain | Yes | Yes | Abstain | |||||
7 | FAILED BALLOT | Comments: (Req'd if No) | This is a dangrous configuration unless you have a secure DNS. This is explained in BCP195, Section 6.1. This lack of a requirement for secure DNS makes this option dangerous. The ability to issue a certificate that wll be considered trusted, relies on poor trust-store management by the client. The ability to use a trusted certificate, relies on poor private-key management by servers. Yet the ability to poison or re-direct DNS requests is far easier and does not rely on any failure by the endpoints. DNS is not a trustworthy protocol, it uses UDP and as has no authentication, integrity, or confidentiality. If this CP goes forward, it should limit the changes to just adding the new option, and describing the new option impact to authentication only within the option scope. Meaning the changes it proposes in section 9.1 are unnecessary and confusing, as this option is in addition to the basic outline given in 9.1. RESOLUTION: Also, the insertion in 9.4.1.2.2 is argumenative and unnecessary. Indeed the use of this option addresses on issue but not all MiM issues, as it does not addres secure DNS. MiM are more likely to be initiated by first attacking DNS. RESOLUTION: Sentence removed | 9.1.1.1 - Rather than say that a SN doesn't need to do certain things, just say, "this requirement does not apply". Similar for 9.1.1.2, 9.1.1.3, and 9.1.1.5. RESOLUTION: Table 9.2-1 - Don't refer to volume 2. The section in volume 1 already does. RESOLUTION: Wording of note - change to "...shall support either the Retrieve Audit Message or the Retrieve Syslog Message option." Possibly put a "see note" on those options. RESOLUTION: 9.2.7 - "An actor that supports the Server Certificate FQDN Validation Option shall be able to apply...". Insert "an" before "X.509". The reference to BCP195 needs a URL or some identifying text. RESOLUTION: 9.4.1.2.2. An actor doesn't "use" an option. Perhaps "use the feature of" the option? RESOLUTION: 3.19.6.1.3 - Keep the 2nd half of the first sentence. RESOLUTION: 3.19.6.1.4 - The requirements for a server are simply to be configured with an appropriate certificate. That should mean that ALL servers are already capable of filling the requirements. Therefore, this option should not apply to servers at all. The "requirement" for the server should be listed as a note associated with the client requirement, that the server must have an appropriate certificate for the functionality to work. The remaining text for the section should be reworded: "An actor that supports the ...Option shall be able to apply the rules presented in ...(TLS). In particular, the actor shall be able to validate that the reference..." RESOLUTION: | "Long comment, read to ""COMMENT END"" Although I support the addition of Server FQDN validation, I do not like how this is added. We are breaking exisiting implementations, and the rationale does not make it clear why we want to do that. I would rather see true options added, where the actor is capable of FQDN validation. Further, FQDN validation has client and server requirements, and our single option doesn't do a good job of identifying when an actor has taken on which requirements. For example, 9.1.1.1 becomes: ... The Secure Node shall: 1. Use the Authenticate Node transaction for all network connections to or from the node that may expose private information as specified in ITI TF-2a: 3.19. If the Secure Node claims the Server Certificate FQDN Validation Option, it shall be capable of performing the Server Certificate FQDN Validation Option on the Authenticate Node transaction. 2. ... 3. ... 9.1.1.2 ... 9.2.7 does not follow our standard option description style. There should be one (or more) sentences describing the benefit of the option, and then a paragraph per actor of ""A Secure node that claims the X option shall..."" For example: The Server Certificate FQDN Validation Option provides additional assurances against man-in-the-middle and similar attacks. The option requires clients to perform additional validitation checks when connecting to a server, and the server to present a certificate containing specific content. A Secure Node that claims the Server Certificate FQDN Validation Option shall be capable of performing the Server Certificiate FQDN Validation option of the Authenticate Node transaction on configured connections. 3.19.6.1.3 - I would recommend leaving parts of the first paragraph. We don't generally require any particular certificate content, and we should not change that, except in this option, unless we intend to break compatability. Leave the first sentence, but preface it with, ""Except as describedin the FQDN Validation option, ..."" 3.19.6.1.4: We need to define what a client and server is, and clarify what the expectation is for systems that implement both roles, particularly if it has one role exposed to the internet, and the other role in a controlled environment. ""A system that initiates a secure connection is acting as a client in the context of ..."" Why doesn't Audit Forwarder have the FQDN validation option? COMMENT END" | ||||||||||||||
8 | 3/2/3 | 1124-09 | ATNA – Add two options related to BCP195 TLS Secure Transport Connection | ATNA | Vol 1, 2a, ATNA-TI | Yes/Abstain/No: | Yes | Yes | No | No | Abstain | Abstain | Yes | Abstain | |||||
9 | FAILED BALLOT | Comments: (Req'd if No) | The first editor instructions are confusing "(Note that subsections 9.2.3 and 9.2.4 are added in the “Add RESTful Query to ATNA TI Supplement, so the new options get numbered 9.2.5 and 9.2.5)." The 2nd mention of 9.2.5 probably should be 9.2.6. RESOLUTION: Fixed The section numbers at the end are off. There are now 2 sections with number 3.19.6.5. RESOLUTION: Fixed. Created subsections for each option. | 9.2 - Rather than leave blank sections waiting for a Supplement, make the new sections here be 9.2.3 and 9.2.4 and modify the supplement to have new numbers. RESOLUTION: 9.2.5/9.2.6 - The options do not "provide implementations the ability" to do anything. They describe a mechanism for implementations to do things. Also, change "implementation" to "actor". RESOLUTION: 3.19.6.2 - The first paragraph, even without the markup, seems backwards. But what's a "normal connection mechanism"? The second paragraph seems to be the one referring to public Internet. RESOLUTION: 3.19.6.3 - (not part of the CP) - The URL for WS-I BSP is no longer correct. Based on the section number, it appears to be referencing BSP 1.0, not 1.1. The correct URL for 1.1 is http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html. Is the "identical and interoperable" statement still true? RESOLUTION: 3.19.6.4/3.19.6.5 - "Actor", not "Implementation". "shall be able to utilize" and "shall be able to comply". RESOLUTION: I don't think the requirements for the Integration Statement belong here. Maybe in volume 1, and as a "should", not "shall". RESOLUTION: Integration Stmt requirements are removed. 3.19.6.4 - Instead of "The following cipher suites...", "As specified in BCP195, the following cipher suites should be supported:". RESOLUTION: 3.19.6.5 - Remove the last sentence ("BCP195 recommends...") from the first paragraph. Replace with "Note that some of these restrictions are only recommendations in RFCs referenced in BCP195." Remove 2nd paragraph. Remove "where BCP195 merely recommends them". RESOLUTION: Renumber the old 3.19.6.5. RESOLUTION: | "Long comment read to ""COMMENT END"" ""• Operate with the highest level of cyber protection for the TLS-protected communication channel per the IETF Best Current Practice (BCP195)."" -- Strike ""cyber"", replace ""per"" with ""by adopting"" ""• Continue to interoperate with ATNA Actors that do not support this option, by down-grading to TLS Version 1.1 or Version 1.0 and/or cipher suites under specific conditions that are allowed by BCP195. As this option adds significant recommendations by the IETF BCP195, it is well-suited for upgrading an installed base."" -- consider whether we mean ""ATNA actors that do not support this option"" or more generally, ""systems that do not follow BCP195"". Current language is awkward, suggest ""...by allowing the actor to use less preferred TLS versions, and/or less preferred cipher suites under specific conditions as allowed by BCP195. <new paragraph>This option adopts many valuable recommendations of BCP195, while providing flexibility when communicating with an installed base."" First bullet of 9.2.5 and 9.2.6 should be identical (I prefer calling out TLS 1.2 as in 9.2.6). Also, neither section use our standard ""an actor that claims <X> option shall..."" Should the additional restrictions, etc. be done as an options on Authenticate node, rather than as a reference from volume 1 actor requirements to a vol 2 transaction description? 9.2.6 second bullet -- again, are we refusing to interoperate with ATNA actors that do not claim this option, or refusing to operate with any system that does not support this option? Thinking further, I would like to see the first bullet of both sections identical and claim ability to interoperate with other systems using TLS 1.2. Then 9.2.5 can go on to say that it is flexible and can downgrade, while 9.2.6 says it is secure and will not downgrade. The last sentence of the second bullet of both sections should follow the pattern I gave above. I'm not sure what the first paragraph of 3..19.6.2 means (either before or now). What are normal mechanisms? 3.19.6.4: Are those cyphersuites required or recommended (shall support)? If recommended, why call out -- doesn't BCP195 recommend them? Are additional cyphersuites of lesser strength allowed? How do we test that requirement? IHE integration statements don't contain details like ports or key management. Including that here would be inappropriate. 3.19.6.5: ""BCP195 recommends the use of TLS1.2 or higher"" -- So? If TLS1.2 just a recommendation from BCP195, then they'll read it in BCP195. If it is a requirement we add on top of BCP195, then state it as a shall. Are we allowed to make non-TLS connections? COMMENT END" | ||||||||||||||
10 | |||||||||||||||||||
11 | |||||||||||||||||||
12 | |||||||||||||||||||
13 | |||||||||||||||||||
14 | |||||||||||||||||||
15 | |||||||||||||||||||
16 | |||||||||||||||||||
17 | |||||||||||||||||||
18 | |||||||||||||||||||
19 | |||||||||||||||||||
20 | |||||||||||||||||||
21 | |||||||||||||||||||
22 | |||||||||||||||||||
23 | |||||||||||||||||||
24 | |||||||||||||||||||
25 | |||||||||||||||||||
26 | |||||||||||||||||||
27 | |||||||||||||||||||
28 | |||||||||||||||||||
29 | |||||||||||||||||||
30 | |||||||||||||||||||
31 | |||||||||||||||||||
32 | |||||||||||||||||||
33 | |||||||||||||||||||
34 | |||||||||||||||||||
35 | |||||||||||||||||||
36 | |||||||||||||||||||
37 | |||||||||||||||||||
38 | |||||||||||||||||||
39 | |||||||||||||||||||
40 | |||||||||||||||||||
41 | |||||||||||||||||||
42 | |||||||||||||||||||
43 | |||||||||||||||||||
44 | |||||||||||||||||||
45 | |||||||||||||||||||
46 | |||||||||||||||||||
47 | |||||||||||||||||||
48 | |||||||||||||||||||
49 | |||||||||||||||||||
50 | |||||||||||||||||||
51 | |||||||||||||||||||
52 | |||||||||||||||||||
53 | |||||||||||||||||||
54 | |||||||||||||||||||
55 | |||||||||||||||||||
56 | |||||||||||||||||||
57 | |||||||||||||||||||
58 | |||||||||||||||||||
59 | |||||||||||||||||||
60 | |||||||||||||||||||
61 | |||||||||||||||||||
62 | |||||||||||||||||||
63 | |||||||||||||||||||
64 | |||||||||||||||||||
65 | |||||||||||||||||||
66 | |||||||||||||||||||
67 | |||||||||||||||||||
68 | |||||||||||||||||||
69 | |||||||||||||||||||
70 | |||||||||||||||||||
71 | |||||||||||||||||||
72 | |||||||||||||||||||
73 | |||||||||||||||||||
74 | |||||||||||||||||||
75 | |||||||||||||||||||
76 | |||||||||||||||||||
77 | |||||||||||||||||||
78 | |||||||||||||||||||
79 | |||||||||||||||||||
80 | |||||||||||||||||||
81 | |||||||||||||||||||
82 | |||||||||||||||||||
83 | |||||||||||||||||||
84 | |||||||||||||||||||
85 | |||||||||||||||||||
86 | |||||||||||||||||||
87 | |||||||||||||||||||
88 | |||||||||||||||||||
89 | |||||||||||||||||||
90 | |||||||||||||||||||
91 | |||||||||||||||||||
92 | |||||||||||||||||||
93 | |||||||||||||||||||
94 | |||||||||||||||||||
95 | |||||||||||||||||||
96 | |||||||||||||||||||
97 | |||||||||||||||||||
98 | |||||||||||||||||||
99 | |||||||||||||||||||
100 | |||||||||||||||||||