Re: [Cryptography] End to end
On 2013-09-17 Max Kington mking...@webhanger.com wrote: [snip] Hence, store in the clear, keep safe at rest using today's archival mechanism and when that starts to get dated move onto the next one en-masse, for all your media not just emails. [snip] I would tend to agree for environments with very high regulations, where the need to comply with regulations is more important than the need to keep data confidential. I would suggest to balance that for every organisation. The risk to disclosure is much higher if data is stored unprotected. Any admin with access to the file system is able to read it. Maybe this could be a cultural difference between US and Europe, the regulative pressure in US is higher, in Europe the privacy is more important or more protected. I agree that both ways may be the right implementation for an organisation, but this has to be a management decision, balancing the needs. Best regards -- Christoph Gruber If privacy is outlawed, only outlaws will have privacy. Phil Zimmermann ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] End to end
On 18 Sep 2013 07:44, Christoph Gruber gr...@guru.at wrote: On 2013-09-17 Max Kington mking...@webhanger.com wrote: [snip] Hence, store in the clear, keep safe at rest using today's archival mechanism and when that starts to get dated move onto the next one en-masse, for all your media not just emails. [snip] I would tend to agree for environments with very high regulations, where the need to comply with regulations is more important than the need to keep data confidential. I would suggest to balance that for every organisation. The risk to disclosure is much higher if data is stored unprotected. Any admin with access to the file system is able to read it. Maybe this could be a cultural difference between US and Europe, the regulative pressure in US is higher, in Europe the privacy is more important or more protected. I agree that both ways may be the right implementation for an organisation, but this has to be a management decision, balancing the needs. I was referring to the UK :-) I'm not saying it isn't important to consider how data is made available in the cases where you have end to end security but a future standard wants to be permissive of a solution even if it's out of scope for the RFC rather than prohibitive by including it as mandatory, could/can vs should/must. That said now there appears to be evidence that side channel attacks that force lesser security where it's an option are being actively exploited. Previously we'd have all assumed that the main benefit of those was in interoperability but now not so much. So there is an argument to use 'must' more in standards concerning security. By making archival a separate concern you also reduce the complexity of many deployments. As you say, for environments with very high regulation, my personal mailbox, isn't, my work one, is. Max Best regards -- Christoph Gruber If privacy is outlawed, only outlaws will have privacy. Phil Zimmermann ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] End to end
On 2013-09-16 Phillip Hallam-Baker hal...@gmail.com wrote: [snip] If people are sending email through the corporate email system then in many cases the corporation has a need/right to see what they are sending/receiving. [snip] Even if an organisation has a need/right to look into people's email, it is necessary to protect the communication on transport and storage. Of course a certain way of key recovery has to be in place. Just my 2 cents -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] End to end
On 17 Sep 2013 15:47, Christoph Gruber gr...@guru.at wrote: On 2013-09-16 Phillip Hallam-Baker hal...@gmail.com wrote: [snip] If people are sending email through the corporate email system then in many cases the corporation has a need/right to see what they are sending/receiving. [snip] Even if an organisation has a need/right to look into people's email, it is necessary to protect the communication on transport and storage. Of course a certain way of key recovery has to be in place. Just my 2 cents I intend to reply in more detail to the draft there's lots of very interesting work there. The most common approach to ILM for email in highly regulated sectors I've seen is to divorce the storage and transport mechanism and associated security from the long term storage. In a corporate environment the message is captured pre encryption and transmission and stored. Whilst key escrow mechanisms do exist the risk is that what gets escrowed isn't what was sent if you maliciously want to tunnel data (imagine not being able to decrypt a message at the request of the SEC or FSA because the key you were sent is wrong by the desktop app, or conversely having to decrypt everything first to check). You have the added issue of having to store all the associated keys and in 7 years (the typical retention period over here for business now regarded as complete, let alone long running contracts still in play) still have software to decrypt it. Hence, store in the clear, keep safe at rest using today's archival mechanism and when that starts to get dated move onto the next one en-masse, for all your media not just emails. Hence for the purposes of your RFC perhaps view that as a problem that doesn't require detailed specification. M -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] End to end
Just writing document two in the PRISM-Proof series. I probably have to change the name before November. Thinking about 'Privacy Protected' which has the same initials. People talk about end-to-end without talking about what they are. In most cases at least one end is a person or an organization, not a machine. So when we look at the security of the whole system people security issues like the fact they forget private key passphrases and lose machines matter. Which ends you are talking about depends on what the context is. If we are talking about message formats then the ends are machines. If we are talking about trust then the ends are people and organizations. End to end has a lot of costs. Deploying certificates to end users is expensive in an enterprise and often unnecessary. If people are sending email through the corporate email system then in many cases the corporation has a need/right to see what they are sending/receiving. So one conclusion about S/MIME and PGP is that they should support domain level confidentiality and confidentiality, not just account level. Another conclusion is that end-to-end security is orthogonal to transport. In particular there are good use cases for the following configuration: Mail sent from al...@example.com to b...@example.net * DKIM signature on message from example.com as outbound MTA 'From'. * S/MIME Signature on message from example.com with embedded logotype information. * TLS Transport Layer Security with Forward Secrecy to example.net mail server using DNSSEC and DANE to authenticate the IP address and certificate. * S/MIME encryption under example.net EV certificate * S/MIME encryption under b...@example.net personal certificate. [Hold onto flames about key validation and web of trust for the time being. Accepting the fact that S/MIME has won the message format deployment battle does not mean we are obliged to use the S/MIME PKI unmodified or require use of CA validated certificates.] Looking at the Certificate Transparency work, I see a big problem with getting the transparency to be 'end-to-end', particularly with Google's insistence on no side channels and ultra-low latency. To me the important thing about transparency is that it is possible for anyone to audit the key signing process from publicly available information. Doing the audit at the relying party end prior to every reliance seems a lower priority. In particular, there are some type of audit that I don't think it is feasible to do in the endpoint. The validity of a CT audit is only as good as your newest notary timestamp value. It is really hard to guarantee that the endpoint is not being spoofed by a PRISM capable adversary without going to techniques like quorate checking which I think are completely practical in a specialized tracker but impractical to do in an iPhone or any other device likely to spend much time turned off or otherwise disconnected from the network. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] End to end
On Mon, Sep 16, 2013 at 3:14 PM, Ben Laurie b...@links.org wrote: On 16 September 2013 18:49, Phillip Hallam-Baker hal...@gmail.com wrote: To me the important thing about transparency is that it is possible for anyone to audit the key signing process from publicly available information. Doing the audit at the relying party end prior to every reliance seems a lower priority. This is a fair point, and we could certainly add on to CT a capability to post-check the presence of a pre-CT certificate in a log. Yeah, not trying to attack you or anything. Just trying to work out exactly what the security guarantees provided are. In particular, there are some type of audit that I don't think it is feasible to do in the endpoint. The validity of a CT audit is only as good as your newest notary timestamp value. It is really hard to guarantee that the endpoint is not being spoofed by a PRISM capable adversary without going to techniques like quorate checking which I think are completely practical in a specialized tracker but impractical to do in an iPhone or any other device likely to spend much time turned off or otherwise disconnected from the network. I think the important point is that even infrequently connected devices can _eventually_ reveal the subterfuge. I doubt it is necessary to go very far to deter PRISM type surveillance. If that continues very long at all. The knives are out for Alexander, hence the story about his Enterprise bridge operations room. Now the Russians... Do we need to be able to detect PRISM type surveillance in the infrequently connected device or is is sufficient to be able to detect it somewhere? One way to get as good timestamp into a phone might be to use a QR code: This is I think as large as would be needed: [image: Inline image 1] -- Website: http://hallambaker.com/ qr-256.png___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] End to end
On 16 September 2013 18:49, Phillip Hallam-Baker hal...@gmail.com wrote: To me the important thing about transparency is that it is possible for anyone to audit the key signing process from publicly available information. Doing the audit at the relying party end prior to every reliance seems a lower priority. This is a fair point, and we could certainly add on to CT a capability to post-check the presence of a pre-CT certificate in a log. In particular, there are some type of audit that I don't think it is feasible to do in the endpoint. The validity of a CT audit is only as good as your newest notary timestamp value. It is really hard to guarantee that the endpoint is not being spoofed by a PRISM capable adversary without going to techniques like quorate checking which I think are completely practical in a specialized tracker but impractical to do in an iPhone or any other device likely to spend much time turned off or otherwise disconnected from the network. I think the important point is that even infrequently connected devices can _eventually_ reveal the subterfuge. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
