Security & Trust Meeting 2010-09-02

From Direct Project
Jump to navigation Jump to search
Notes from the Security and Trust Meeting
Date: September 2, 2010
Time: 2pm-3pm
Attendees: Don Bechtel, Mike Davis, Uvinie Hettiaratchy, Erik Horstkotte, Arien Malec, John Moehrke, Sean Nolan, Pete Palmer, Brett Peterson, Vassil Peytchev, Patrick Pyette, Nick Radov, Jas Singh

Current Actions

#
 Date
 Action
 Status
 Owner
 Due Date
49
 2010/08/26
 Create a one page document further explaining the LDAP issue to be submitted to the Security and Trust WG at large for approval
 Open
 John Moehrke
 2010/09/02
51
 2010/08/26

Bring following items up for consensus vote in WG:

 Open
(Extended)
 Sean Nolan
 2010/09/02
52
 2010/09/02
 Update the threat model diagrams to state "messaging client" instead of "SMTP" where necessary
 Open
 John Moehrke, Sean Nolan
 2010/09/09
53
 2010/09/02

Draft the risks for Arc 1 and Arc 12 as identified by WG brainstorm:

  • Mal-intentioned perpetrators trying to connect
  • Clear text on both sides
  • Improper signing / bouncing issue
  • Middle man poisoning clarification
  • DNS spoof (Risk 2)
  • A client is trying to send data on behalf of a valid user
  • SMTP authentication/Mutual TLS issue clarification
 Open
 Sean Nolan, John Moehrke
 2010/09/09
54
 2010/09/02
 Projected: Outline possible threat model for edge protocols to be included in XDD specification
 Open
 John Moehrke
 2010/09/16
55
 2010/09/02

Update CERT Distribution Statement in the Content Security for Simple Health Transport spec

 Closed
 Sean Nolan
 2010/09/09
56
 2010/09/02

Address Brett Peterson's question about the E attribute of a DN

 Closed
 Umesh Madan
 2010/09/09


Actions from Last Week

#
 Date
 Action
 Status
 Owner
 Due Date
43
 2010/08/12
 Approach Dragon Bashyam and Will Ross of the Documentation and Testing WG to assist with security considerations
 Tabled
 Pete Palmer and Iona Singureanu
 2010/08/19
46
 2010/08/19

Review harmonized threat assessment on Security and Trust Workgroup page

 Closed
 All
 2010/08/26
47
 2010/08/19
 Monitor both edits to the table on wiki and discussion thread comments
 Closed
 John Moehrke
 2010/08/26
48
 2010/08/26

Include statement regarding LDAP in the specification around DNS section

 Closed
 Sean Nolan
 2010/09/02
49
 2010/08/26
 Create a one page document further explaining the LDAP issue to be submitted to the Security and Trust WG at large for approval
 Open
 John Moehrke
 2010/09/02
50
 2010/08/26

Give a final review of Threat Model - SMTP with Full Service HISPs and Threat Model - Simple SMTP prior to call for consensus vote; Send comments on the following to John Moehrke or post on the discussion tab:

  • Inaccuracies
  • Additional risks
  • Changes to the existing risks
 Closed
 All
 2010/08/30
51
 2010/08/26

Bring following items up for consensus vote in WG:

 Open
 Sean Nolan
 2010/09/02


Agenda


1. Call for workgroup consensus on the two Threat Models, mitigations and risks. If we have consensus on the phone, we will present a call for IG consensus next week.


2. Review text added to spec regarding certificate distribution. I don't think this requires a formal consensus vote, but would like to go around the call and ask for objections to the wording as is.


NOTE: Universal certificate distribution is critical to friction-free exchange of messages. During the current pilot phase we recognize that DNS may or may be the most effective real-world option. We encourage pilot implementations to experiment with alternatives such as those outlined above. Post-pilot, taking into account the learnings from that work, this specification will be edited to provide firm guidance as to the preferred go-forward mechanism for certificate distribution

Final Comments on the Harmonized Threat Models


"Round the Room" - Consensus on Threat Models?
Sean Nolan

  • Opened the meeting with a "Round the Room" regarding the harmonized threat models
  • Summary of Questions:
    • Have you read the updated threat models?
      • Yes (8): Nick Radov, John Moehrke, Sean Nolan, Erik Horstkotte, Pete Palmer, Andrew Rikarts, Brett Peterson, Don Bechtel
      • No (4): Vassil Peytchev, Pat Pyette, Arien Malec, Mike Davis
    • Do you agree with the threat models in their current form?
      • Yes (10): Nick Radov, John Moehrke, Sean Nolan, Erik Horstkotte, Arien Malec, Pete Palmer, Mike Davis, Andrew Rikarts, Brett Peterson, Don Bechtel
      • No (0):
      • Abstain (2): Vassil Peytchev, Pat Pyette

Nick Radov

  • Had read the updated threat models
  • Agreed with the threat models in their current form

Vassil Peytchev

  • Had not read the updated threat models
  • Did not comment on the threat models at the time

John Moehrke

  • Reminded the WG that he authored the threat models
  • Agreed with the threat models in their current form
  • However, shared a comment:

Sean Nolan

  • Responded that John Moehrke suggested a good idea
    • Sean Nolan noticed this himself that morning
    • Believes it is worth a brainstorm on those numbers

Pat Pyette

  • Did not read the updated threat models
  • Did not comment on the threat models at the time

Sean Nolan

  • Commented that he is with John Moehrke on the issue
  • Agreed with the threat models at the time

Erik Horstkotte

  • Had read the updated threat models
  • Agreed with the threat models in their current form

Arien Malec

  • Indicated that he has reviewed the threat models many times
  • Stated that if John Moehrke and Sean Nolan support the current threat models, then he does as well

Pete Palmer

  • Had read the updated threat models
  • Agreed with the threat models in their current form

Mike Davis

  • Did not read the updated threat models
  • However, still agreed with the threat models in their current form

Andrew Rikarts

  • Had read the updated threat models
  • Agreed with the threat models in their current form

Brett Peterson

  • Had read the updated threat models
  • Agreed with the threat models in their current form

Don Bechtel

  • Joined the call after the roll call
  • Had read the updated threat models
  • Agreed with the threat models in their current form as well

Vassil Peytchev

  • Asked how other possible mechanisms for the mail client beyond SMTP were represented in the diagrams

Sean Nolan

  • Suggested changing SMTP to "e-mail client" in the diagrams

Arien Malec

  • Assessed that Sean Nolan's proposal implies that it is always e-mail
    • Sometimes it is not "always e-mail"
  • Suggested and received support for the title "messaging client"

Mike Davis

  • Commented that the risk assessment will have to do that separately

John Moehrke

  • Responded that there is a standalone e-mail client regulating the transport into a CHR/EHR
    • That is why the boxes on the diagrams are denoted as such
    • Titled a destination location
  • Further responded that the details that describe the arcs address the issue, but he understand Mike Davis's perspective
    • Would then need to label the server in the HISP as "SMTP/POP/IMAP/etc"

Arien Malec

  • Suggested that Sean Nolan and John Moehrke may want to put some language about the MDN risk assessment

Sean Nolan

  • Responded that they assumed that it was addressed since they are regularly encrypted like any mail

Mike Davis

  • Added they could place it in the top paragraph


Discussion About the Risks for Arc 1 & Arc 12
Sean Nolan

  • Suggested the group brainstorm the risks facing Arcs 1 and Arc 12
    • Recognized that each specific protocol has its own profiles of risk
      • It is not possible to define them all here
    • Mitigation: Implementations should conduct specific tests on the protocols they deploy
      • Not tenable to conduct tests for all the different protocols

John Moehrke

  • Asked about POP3 versus IMAP4

Sean Nolan

  • Responded that they do not want to go through the entire history of POP3

John Moehrke

  • Suggested that the WG can generalize major risks in the arcs

Arien Malec

  • Added that if someone steals the end-user credits, then all bets are off
  • Further added that an improperly configured client may send to a non-secure SMTP server

John Moehrke

  • Responded that this needs to be in Arc 1

Arien Malec

  • Continued that messages would get to the right location, and then bounce by the destination HISP because it is not signed
    • However, it would leave a PHI trail

Sean Nolan

  • Asked if the WG wants to address the issue of a clear text local storage

John Moehrke

  • Suggested the WG make that an operational challenge

Sean Nolan

  • Summarized possible risks thus far to Arcs 1 and 12
    • Mal-intentioned perpetrators trying to connect
    • Clear text on both sides
    • Improper signing / bouncing issue

Arien Malec

  • Asked about middle man DNS poisoning issue

Sean Nolan

  • Responded that risk is somewhere else in the threat model to a different extent

Arien Malec

  • Clarified such a risk is to a higher level
    • Has a self-CERT/TLS-CERT
  • If someone poisons a server, there could be higher level consequences

Sean Nolan

  • Agreed that this should be included

John Moehrke

  • Suggested that a DNS spoof (Risk 2) is applicable to Arc 1 and 12
    • The content is already s/MIME by arcs 3.2, 6.2 and 9.2
    • More likely to see a DNS spoof for Arc 1 or 12
    • Mitigated by TLS authentication, but still should be noted
  • Highlighted a potential problem for Arc 1
    • What if a client is trying to send data on behalf of a valid user?
      • No user identity going across

Sean Nolan

  • Responded that he will look into it further

John Moehrke

  • Asked about requiring SMTP awe authentication on Arc 1
    • Advantage is that anyone can use MIME
  • Other operational mitigation
    • TLS client authentication mechanism limits who can send from that address

Sean Nolan

  • Basic mitigation: Mention that it is in a secure space

Arien Malec

  • Questioned whether mutual TLS has the same limitations

Sean Nolan

  • Responded that this model does not use mutual TLS

John Moehrke

  • Asked if anyone can send e-mail messages to that e-mail address

Sean Nolan

  • Responded they cannot unless they have an authenticated connection to the server

Arien Malec

  • Stated that then they need mutual TLS

John Moehrke

  • Added that it has to be one or the other

Sean Nolan

  • Agreed that it needs to be one or the other
    • Believed that this was already clear in the threat model
    • Needs to be some rewording - "did not realize how messy that it was"

John Moehrke

  • Shared that he had someone in the past try to spoof something of his own

Sean Nolan

  • Moving forward, asked if there is anything else to be discussed

Vassil Peytchev

  • Asked if this is based on the end to the end SMTP

Sean Nolan

  • Answered "that is correct"

Vassil Peytchev

  • Asked: Do you plan to address the other edge protocols?

Sean Nolan

  • Suggested that developers will create custom models from Arc 1 and 12 of this threat model

John Moehrke

  • Asked the following questions:
    • Do we feel like we need to do additional risk assessments?
    • Do these two represent most of the deployment models?
    • If so, then we are good

Sean Nolan

  • Expressed his personal vote that they do not need a third one
  • However, solicited the views of the others WG members

John Moehrke

  • Agreed in general
  • However, interested in a third threat model potentially

Arien Malec

  • Suggested considering the pre-condition such that it is reasonable

Sean Nolan

  • Asked once more: "Do we go for it or are we okay?"

Arien Malec

  • Further suggested this maybe best done in the XDD spec

John Moehrke

  • Offered to outline that as well when they get down to it

Sean Nolan

  • Asked for any other thoughts
    • Will take his notes and implement the suggested changes
    • Ask John Moehrke to help with this
  • Asked to try again for the consensus next week

John Moehrke

  • Raised last item of denial of service attacks

Sean Nolan

  • Responded that he will mention it in there

John Moehrke

  • Asked Sean Nolan to look at Risk 5 and add in Archs 1 and 12
    • If its radically different, then suggested creating a duplicate
    • Example: Confidentiality - impact is much larger, but the mitigation brings them back

Sean Nolan

  • Ended the discussion by stating he will get all the changes and then get at consensus


Review of CERT Distribution Statement in Content Security for Simple Health Transport


"Round the Room" - Consensus on Sean Nolan's Suggested CERT Distribution Statement
Sean Nolan

  • Expressed goal of wrapping up the conversation from last week about certificate distribution
  • Pointed everyone to his suggested CERT distribution statement:
    • "Universal certificate distribution is critical to friction-free exchange of messages. During the current pilot phase we recognize that DNS may or may be the most effective real-world option. We encourage pilot implementations to experiment with alternatives such as those outlined above. Post-pilot, taking into account the learnings from that work, this specification will be edited to provide firm guidance as to the preferred go-forward mechanism for certificate distribution" [Note: pre-2010/09/02 meeting]
  • Expressed goal of trying to get to universal certificate distribution eventually
  • Outcome: Amended statement

Nick Radov

  • Agreed with Sean Nolan's suggested statement

Vassil Peytchev

  • Did not comment on the statement

John Moehrke

  • Disagreed with the first sentence of the statement
    • Viewed the sentence as a politically charged statement
    • Saw the wording in particular as politically charged
  • Agreed with everything else mostly

Sean Nolan

  • Clarified that he was not trying to make it political

John Moehrke

  • Responded that some organizations may specifically want some friction with respect to certificate discovery

Sean Nolan

  • Recognized John Moehrke's point, attempted to find right wording
  • Expressed view that allowing for technical barriers to having people communicate seems like a broken plan

John Moehrke

  • Responded that the first sentence is making judgments

Sean Nolan

  • Asked the WG is their goal is to remove technical barriers to directed exchange

John Moehrke

  • Responded that he agrees with the spirit of that
    • However, also believes that specific words will be used against specific architectures moving forward
    • Does not want to allow such potential attacks in the future

Sean Nolan

  • Rebutted that their goal is to have nationwide exchange that enables secure and simple directed exchange

John Moehrke

  • Suggested they proceed with the "Round the Room" to see if there were any other similar objections

Pat Pyette

  • Agreed with Sean Nolan's suggested statement
  • Asked if the message changes if the first sentence is removed

Erik Horstkotte

  • Agreed with Sean Nolan's suggested statement
    • Likes the phrasing and Sean Nolan's point
  • Proposed that they include something about those organizations who don't want their CERTs discoverable
    • Not everyone has to publish it?
  • Preferred one mechanism for all those who aim for a friction-free directed exchange
    • Alternative: If you want friction, then you have to arrange for it yourself

Arien Malec

  • Agreed with Sean Nolan's suggested statement
    • It is an advantage that they have universal addressing
    • Likes the wording, however was coming around to something cleaner than what he said

Peter Palmer

  • Agreed with Sean Nolan's suggested statement in principle
  • However, asked why they are going for a "winner-takes-all" solution
    • Why not use put forward mechanisms?
    • Cover the bases first

Mike Davis

  • Agreed with Sean Nolan's suggested statement in principle
    • Thinking about John Moehrke's comment about the first sentence
  • Asked if they want a "one-size fits all" communication
  • Proposed let the pilots determine this, instead of making a decision themselves

Andrew Rikarts

  • Agreed with Sean Nolan's suggested statement in principle
    • Waiting to see what pans out

Brett Peterson

  • Agreed with Sean Nolan's suggested statement in principle
    • Suggested dropping universal
    • Certificate distribution is critical to the secure exchange of messaging

Don Bechtal

  • Agreed with Sean Nolan's suggested statement in principle
    • In the same boat as everyone else

Arien Malec

  • Offered one more comment:
    • If we create a mechanism that does not create an easy default option for any two people who want to exchange information
      • This would only create communities that can exchange internally
      • However, there is a value to nationwide ability to exchange
    • There should be a mechanism or mechanisms to discover certificates should they want to discover it

Sean Nolan

  • Indicated that he had been editing this during the round
  • Proposed an amended statement that was updated online
    • Asks pilots to experiment
    • This will be edited as to the default mechanism for certificate distribution after the pilots

John Moehrke

  • Indicated that he was mostly satisfied with the adjusted statement
    • Still begs the question why they mention DNS
    • Why not LDAP?

Sean Nolan

  • Responded that LDAP is explicitly mentioned in the paragraph above, which is directly referenced in his proposed statement
  • Barring any further objections, plans to go with that


Question and Answer Session

Brett Peterson

  • Asked about the Certificate Usage Section >> Certificate Verification Sub-section
    • Appears there is a "must" section
  • Had posted a question about this on July 15th:
    • "The spec mentions the E attribute of a DN. Is that intended to be the same as the EmailAddress attribute mentioned in section 4.1.2.6 of RFC 2459 (and displayed by OpenSSL as "emailAddress=")?
    • [1]
    • Also, the Subject Alternative Name extension is the "non-legacy" mechanism to encode email addresses in a cert so perhaps that should be supported. See section 4.2.1.7 (and 4.1.2.6) of RFC 2459"

Arien Malec

  • Wanted to make sure that Brett Peterson is looped into the separate review that is going into it

Sean Nolan

  • Informed Brett Peterson that he will to talk to Umesh Madan about this

Arien Malec

  • Indicated that Umesh Madan intends to update this
    • Working on a better way to address this

Brett Peterson

  • Commented that using extensions is probably the best way to approach it
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=Security_%26_Trust_Meeting_2010-09-02&oldid=726"