business associate agreement

[Luke Schierer]

The server can, and must be assumed to, record.  For most OTR conversations, it can be safely assumed that the time to brute force the messages, especially since with OTR you have to brute force them effectively individually, is prohibitive.  But it should be evaluated if that risk is acceptable for any particular use case - especially if you are worrying as much or more about legal compliance as you are about actual security. 

Luke


On Mon, Jun 01, 2015 at 05:29:12PM -0400, Michael McConville wrote:
> It's also worth noting, though, that OTR will disable logging and will
> delete messages along with their encryption key when the conversation
> ends. So, if nothing records the messages on either machine *during the
> conversation*, they cannot be retrieved. I'm assuming you already know
> this, Luke, but I think it's worth mentioning to Catherine.
> 
> We should also probably clarify that someone on the server or network
> shouldn't be able to "intercept, mutate, and record" messages if the
> Pidgin clients' fingerprints are verified. There are some unavoidable
> possibilities, like the server dropping messages. Generally, though,
> everything going between the two clients is securely unreadable and
> unalterable, and no one can inject false messages.
> 
> I also agree that it's important to make sure that the systems used are
> secure.
> 
> Let me know if I missed anything, or if I'm misunderstanding anything.
> 
> On Mon, Jun 01, 2015 at 05:02:54PM -0400, Luke Schierer wrote:
> > EVERYTHING that you do on a computer is submitted through your
> > operating system. If you type protected information on the keyboard,
> > the OS is responsible for transmitting that information to the
> > application.  If you save protected information to disk, the OS plays
> > a part in moving that information from memory to storage.  So on and
> > so forth.  
> > 
> > When I am responsible for implementing protection of information, the
> > considerations MUST include the operating system. 
> > 
> > But the base question is I suppose adequately answered.  You are
> > planning on transmitting PII data using Pidgin, and you feel that
> > raises it to the level of needing an agreement.
> > 
> > So we'll put aside the Operating systems for a moment, and focus in on
> > the transmission of that data.
> > 
> > You type it into Pidgin sure, but using which service? * have you
> > deployed a Jabber server within your office? If so, do you have an
> > agreement with your jabber server software provider? * Are you using
> > AIM? Do you have an agreement with AOL?  Their servers would be able
> > to record the messages sent. * Are you using MSN? Then we come back to
> > an agreement with Microsoft. * Yahoo?  so on.
> > 
> > OTR will help you with this by (essentially) creating an encrypted
> > tunnel between the two Pidgin IM clients, but given that the service
> > servers can intercept, mutate, and record your messages, I would want
> > to have some assurance that you have your bases covered.  
> > 
> > Luke
> > 
> > On Mon, Jun 01, 2015 at 03:35:42PM -0500, Catherine Galle wrote:
> > > Luke,
> > > 
> > > Yes we are required to have a 'BAA' with our appointment scheduling
> > > software. We do not have to have an agreement with Windows as nothing that
> > > is considered electronic protected health information is submitted to or
> > > through them.
> > > 
> > > Sincerely,
> > > Catherine
> > > 
> > > On Mon, Jun 1, 2015 at 1:58 PM, Luke Schierer <lschiere at pidgin.im> wrote:
> > > 
> > > _______________________________________________
> > > Support at pidgin.im mailing list
> > > Want to unsubscribe?  Use this link:
> > > https://pidgin.im/cgi-bin/mailman/listinfo/support
> > 
> > _______________________________________________
> > Support at pidgin.im mailing list
> > Want to unsubscribe?  Use this link:
> > https://pidgin.im/cgi-bin/mailman/listinfo/support
> 
> _______________________________________________
> Support at pidgin.im mailing list
> Want to unsubscribe?  Use this link:
> https://pidgin.im/cgi-bin/mailman/listinfo/support
>