Security & Trust Meeting 2010-07-08

Notes from NHIN Direct Security & Trust Meeting

Date: July 8, 2010
Time: 2pm-3pm
Attendees: Ravi Madduri, Nick Radov, Fred Trotter, David McCallie, John Moehrke, Mike Berry, Don Jorgenson, Eric Heflin, Sean Nolan, Konda Mullapudi, Arien Malec, Brian Behlendorf, Uvinie Hettiaratchy, Donald Bechtel, Pete Palmer

Actions for this week:

#	Date	Action	Status	Owner	Due Date
33	7/8/10	Clarify what happens in a wrapped model	Open	Arien Malec	7/8/10
34	7/8/10	Create table of encryption options, nothing PHI exposure risks	Open	Sean Nolan	7/15/10
35	7/8/10	Review John Moehrke’s risk assessment model and Sean Nolan’s model on the wiki	Open	WG	7/15/10
36	7/8/10	Take John’s risk assessment of end to end S/MIME model and see which risks are applicable to Sean’s model.	Open	WG	7/15/10

Actions from last week

#	Date	Action	Status	Owner	Due Date
30	6/24/10	Provide background information on comparable threat assessments already done for SMTP and S/MIME approach	Open	WG	6/25/10
31	6/24/10	Draft initial SMTP threat assessment and post to wiki	Open	Sean	6/24/10
32	6/24/10	Provide IHE and HL7 model	Open	John Moehrke	6/24/10
32	6/24/10	Review threat assessment wiki page	Open	WG	6/24/10

Agenda

1. Comments on "Full Service HISP" threat model --- been pretty thin on the wiki. Around the room.

2. Discuss the implications of header exposure to HISPs based on using "current client implementations" of S/MIME. Sean to frame the issue based on issues being discussed in the "policy cloud" and then go around the room for comment. NOTE this has direct impact on John's simple threat model (thanks for doing, John!).

• S/MIME standard provides two models for encryption:
  1. MIME content only. This means that headers like "subject" are exposed to the SMTP server.
  2. FULL MESSAGE, including headers. This protects all headers except "to" and "from".
• Clients today only support MIME ONLY for outbound. Inbound works, but received message shows up as empty with a single message "attachment".
• Policy chatter indicates that they may see to/from as "non-PHI", but subject and other "content headers" appear to be "PHI" --- this is just chatter and NOT FINAL IN ANY WAY
• We have to trade off and no solution seems ideal:
  • Require FULL MESSAGE encryption for NHIN-Direct, which excludes the "zero new software" (John's threat model) approach.
  • Classify all headers as non-PHI (realistic?)
  • Require every HISP to be a BA, prohibit intermediate server hops, and require SSL for transport (reduces scalability of NHIN-D)
• Sean's perspective: Require FULL MESSAGE encryption for now, understanding the implications. Discuss.

3. Proposal for workgroup next steps. Request an live (ideally f2f) meeting with the Tiger team to present our guidance to the implementation team. Ask is for:

• Confirmation that we are moving in a direction aligned with the likely outcomes of policy work --- e.g., understanding the policy work will continue, is it reasonable to expect that we are 90% in the ballpark so that implementations will have minimal churn as final policy guidance emerges?
• Any KNOWN issues that we are not covering that we need to address.

Notes

Sean Nolan

• Would like to do a Round the Room on Threat Model.
• One issue that has come up about S/MIME and headers and encryption of headers. What are considered PHI? Direct implication of what John has put out.
• Next best step as a group is to increase confidence level of implementation team. Perhaps have live bandwidth conversation with Tiger team so we can have back and forth with them.

Round the Room for comments on full service HISP threat model.
Ravi Madduri
· No Comment
Nick Radov
· Have only reviewed part. Want to fully account for DNS.
Fred Trotter
· No comment.
David McCallie
· No comment on threat model. Confused about what’s being encrypted. Is it the MIME objects themselves or entire message? Open question about TLS channel?
Sean Nolan
· That is the number 2 task.
John Moehrke
· I have also posted a different threat assessment which is a different deployment model. When I did that, I initially started with your threats. I ended up with a few other threats that would translate into that model.
Sean Nolan
· That’s fair. I have homework this weekend to look at yours.
Mike Berry
· In arc 1 and 12 there’s a note that we’re not modeling it. Rationale?
Sean Nolan
· That was based on timing not intent to be final. We were trying to make sure we had decision points at HISP level. We wanted to get this part done first. These are open to do items.
Don Jorgenson
· No comment.
Eric Heflin
· No comment.
Konda Mullapudi
· No comment
Don Bechtel
· No comment
Pete Palmer
· No comment
Brian Behlendorf
· The thing I see as a potential issue is that the HIT committee that reviewed the NHIN Direct Project did note concern about use of mail clients on client side. If we ask doctors to add an account to their mail client configurations, when they send those messages, there’s a possibility for them to use non-secure account. Perhaps this will get covered in links 1 and 11. Language that could be around HISPs with end users and configure them to avoid that problem. Also addresses with host names in which regular email would not work. These kinds of things would address those concerns.
Sean Nolan
· Agreed. Those should be the key threats identified.
Arien Malec
· There may be confusion on my part on threat analysis and failure analysis. There may be risk of PHI exposure from agent code. I think this model seems to be pretty strong. If we’re looking at ways for system to fail that isn’t an external threat, I think it’s incomplete.
· It goes to failure analysis more than threat analysis. If we’re assuming you’re writing good code with good configuration, document is fine as is.
John Moehrke
· We’re in position that we’re doing a threat assessment on specification, so assumption is implementer will have to implement perfectly. Valid point that the system complexity itself is a potential threat. So I don’t think that’s necessarily in conflict with presumption that system is implemented perfectly. The answer may be do better implementation.
Sean Nolan
· The only mitigation is to have a different model.
Arien Malec
· That’s why I want to wrap the whole message.
Brian Behlendorf
· There are things that go above and beyond the threat to mitigate potential for any confusion.
Arien Malec
· I wonder if we can do some specific actions since number of people can do a good review. One key action:
o 1) Take John’s risk assessment of end to end S/MIME model and see which risks are applicable to Sean’s model.
o 2) Another key action is the area of complexity as a potential issue.
o 3) Third, the people who are in this call should spend an hour to do a review.
John Moehrke
· I think still useful to do a round that asks for any risks. Now that you’ve seen Sean’s page.
Arien Malec
· I’m wondering if code review approach be a good idea.
John Moehrke
· Yes, that might work.
Sean Nolan
· I’m happy to schedule some time to do that next week.
· If we move on, there’s question with implications on the way NHIN Direct is adopted. Please don’t think this is trying to define policy. We want to represent technology that may survive policy decisions of the future.
· The question, if you look at S/MIME specification there are two models of encryption that are supported. One suggests that you encrypt and sign exclusively the MIME content. The other suggests that the entire message and header is encrypted together. Even the addresses are still disclosed because required to be seen by routing agent.
· Also suggest that proper behavior that you should make assumption that header even if in attachment was meant to be encrypted.
· I have yet to find a client that gives option for doing wrapped model. The question we have to deal with is we are exposing beyond the source these content headers and subject. Both headers may be considered PHI. Subject might give away information about patient. If we believe that is going to be a likely recommendation to protect that information. There are only three ways I’ve seen:
o Option 1 – add to requirements the requirement of messaging encryption. That takes the headers off the table. Downside, it means it’s not possible anymore to use a client to configure to deal with S/MIME currently on market and participate with NHIN Direct without any NHIN direct software available.
o Option 2 – headers are not PHI. Not sure if this is realistic, making a calculated bet that Policy group will not match that. We can combine with marketing campaign.
o Option 3 – If you do some things to server, you can get around this. 1) My SMTP server needs to be internal or business associate. Prohibit intermediate server hopes. Require SSL for transport. If we do that, we’re back in the model that ok with normal clients. It would greatly reduce scalability of server side of NHIN Direct.
· My belief is to require full messaging encryption. We would have to go to market, you can still have client on the model, but client has to fully implement standard and have option of full message wrapping. Open to Arien.
Arien Malec

• I have a third interpretation – the server will always do full wrapping and the client if they take responsibility for encryption, is also taking responsibility for what is and isn’t outside encrypted boundary. If you want to take responsibility for this, you’re also taking responsibility for knowing how to do this and making good decisions.
• The second thing is, outside of Dixie, I doubt there will be a policy pronouncement that says what to do. More likely, Dixie and others who can talk to policy and technology will notice this issue and raise concerns. I think we should come up with approach we believe satisfies policy goals – should be able to run exchange model that does not require access to PHI. We should show how we do that and defend it.

Sean Nolan

• Don’t understand double wrap model.

Arien Malec

• My model would say HISP either always double wraps or fully wraps or if it has responsibility for encryption that it fully wraps. If a client has pre-wrapped, pre-encrypted and signed their content, they are taking responsibility for what they have and haven’t encrypted.

Sean Nolan

• Does that mean that you’re suggesting that a client could decide disclosure of subject is ok.

Arien Malec

• Yes, they are taking responsibility of what they’ve decided to encrypt.

Sean Nolan

• How would that play in practice? Certain policy environments make decision? Individual doctor?

Arien Malec

• Certain policy environments will have to decide how to use. We would be clear about current behavior of current clients. They would have to make a policy decision to see if it’s acceptable to use a standard client.

Sean Nolan

• Makes me nervous not to be concrete. Why don’t we do a round.

Round on encryption options
Ravi Madduri

• Sean is proposing that off the shelf email clients will not be able to send a message fully encrypted with the subject and they would need some set of modification or plug in to be client with NHIN Direct?

Sean Nolan

• Right, somewhere in channel, new software would have to be applied.

Ravi Madduri

• You’re right. I think having doctors or practices making policy decisions is not a good idea. I support Sean’s approach.

Nick Radov

• No comment.

Fred Trotter

• I had opportunity to listen to Tiger Team recordings. From listening to that, it seems we should take high level position.

David McCallie

• If you are going to trust the HISP to hold your private key, you already have strong trust relationship with that HISP

Arien Malec

• Option 1 says you must do end to end encryption from the client.
• Option 2 says must do HISP level encryption or use a client feasible of doing full message wrapping – Sean model and John Moehrke model
• Option 3 – Arien model – if you take on responsibility for encryption, you ‘re taking on responsibility for understanding it.

David McCallie
· How does Arien model differ?
Arien Malec
· Sean’s model says you must fully wrap messages. My model says you take responsibility for what you’re exposing or not.
Brett Peterson
· One of the threat models has assumption that all PHI is encrypted.
David McCallie
· If we were to do the fully wrapped model at the HISP, would that make the TLS requirement unnecessary? Trade off between mandatory TLS?
Sean Nolan
· That’s a tea leaf thing. Are to and from considered PHI? I seem to be hearing that it’s not. I
David McCallie
· But you’re exposing subject unless you use TLS.
Sean Nolan
· If you’re not wrapping subject, you’re disclosing to somebody. You can further segment who gets it. The cleanest model is if to and from are not PHI, doing full message encryption simplifies decision points in network.
Arien Malec
· I think we should simplify discussion and assume a dedicated HISP and look at trade offs between the different models.
· The trust issue is around whether you have a dedicated HISP. I can have one and still not trust it.
John Moehrke

• I think we’re overloading word of HISP. Tiger Team has addressed this.

Sean Nolan

• It’s easy to be more precise. SMTP servers and chain in between.

John Moehrke

• I went through my threat model to not require anything that is not available off the shelf. I would not call any of the Internet technology a HISP. I think by saying your mail server is a HISP is wrong.

Arien Malec

• The decision about whether you can use Google’s infrastructure is not essential to the discussion.

John Moehrke

• The core of the discussion is that we have identified a risk of using only S/MIME and to and from and subject are not protected.
• We have not specified what subject would contain. We could say do not use subject in the field. Or do not put PHI. The to and from not an issue?

Sean Nolan

• I don’t know if to and from is an issue. It appears that to and from falls not in PHI and subject does. I’m hoping that if you believe to and from is not PHI, we can take it off the table as a problem. That’s a bet I’m ready to fight for.

John Moehrke

• I’m fine with starting with that assertion.

David McCallie

• I’m comfortable with that. Footnote, not out of the question that optional headers could creep in.

John Moehrke

• I personally don’t believe that additional cost used in a loose way of deprecating every single off the shelf client is worth protection of this risk. If we’re trying to address small provider with limited technology mandating a technology not currently implemented is counter to that. I suggest that we say this is a known risk and be upfront about it that are not perfectly mitigated by solution using S/MIME.

Sean Nolan

• That is not the recommendation. We’re not suggesting we can’t use those clients. They can’t use them for everything. They can use them with HISP that provides encryption service.

Arien Malec

• How would you prevent case of using off the shelf S/MIME client and I’m sending information?

Sean Nolan

• A trusted recipient would say that this is not encrypted properly and reject it.

Arien Malec

• Once unwrapped, determined that it’s valid, they would expose them to PHI already. Let’s take that offline.

Mike Berry

• Arien’s question how do you prevent user from using a client that’s not up to spec, once user sends the message, damage is done. I would add that it’s a straightforward trade off between cost and security. This concept of using policy and telling users to watch out for the subject line is not new. I agree that relying on end users to be careful.

Don Jorgenson

• The additional processing might be necessary. If we’re committed to doing that, we can reframe a lot of these issues separately.

Eric Heflin

• PHI exposed to and from– I don’t see how this solves the problem. It seems like name of sender itself has potential to have PHI.

John Moehrke

• The other part of it is whose communicating to whom. If provider is communicating to provider, you haven’t disclosed anything. If patient communicating, the patient makes the decision to send to provider.

Konda Mullapudi

• There could be a use case where you’re trying to send a message and you want to prevent exposing that subject. I do agree that we have to encrypt subject if possible.

Don Bechtel

• I don’t see to and from headers as being PHI threat. I appreciate that domain names may be a giveaway. I think good if subject line is not populated, but can’t control that. Trying to encrypt it adds cost and difficult, in favor with John Moehrke.

Pete Palmer

• To get things going, I say we go with idea that it’s not PHI in subject line. And if problem, circle back.

Sean Nolan

• Further discussion on wiki.
• I will try and write this out – what’s exposed and what’s not exposed. Create a table and include where and when TLS is used.

Arien Malec

• Will start conversation about what happens in wrapped model.