Re: [websec] [saag] Pinning
On 17/08/12 13:58, Alexey Melnikov wrote: On 10/08/2012 23:20, Chris Palmer wrote: Hi all, Resurrecting this ancient thread, and explicitly including Moxie and Trevor in case they aren't already on any of the relevant mailing lists. So ultimately I do think we should decide on either HPKP or TACK, but that we should make that decision after there has been some real-world deployment experience with both (or, sadly, real-world non-deployment of one or both). Additionally, HPKP and TACK might converge, more or less. I have plans to publish a new HPKP I-D that borrows some of TACK's pin activation and expiration ideas, for example. Additionally, one of the main criticisms of HPKP is that it is tied to HTTP. I currently don't consider that a huge problem — even though I consider TACK's TLS-generic-ness a nice benefit — for several reasons: * HTTPS is the big, important application that we need to secure right now. * IMAPS and POPS are surely on the list too, right after HTTPS; but specifying IPKP and PPKP is likely to be relatively straightforward once we get HPKP working. I am surely hoping there would be no IMAP, POP or SMTP extensions to address this. IMHO, judging from past experiences of any new functionality being adopted by IMAP/POP/SMTP, chances of such extensions being deployed in any reasonable number of email clients any time soon are close to 0. I think some more generic facility (like a TLS extension) has much better chance of success. Having said that, I think it is Ok if an HTTP facility is deployed now before the TLS extension is finalized. hat=individual I agree with Alexey on both: chances of deployment in email clients is unclear and that it is ok to get an HTTP facility deployed. * It's not clear that SMTP over TLS is very beneficial, because you can't stop delivery due to pin validation failure (or really even regular old X.509 failure). You could use certificate errors as soft-fail spam signals, but you can in principle do that now, too, without explicit pinning. I don't know how much benefit you'd get from using pin validation failure as a spam signal. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [saag] Pinning
On 10/08/2012 23:20, Chris Palmer wrote: Hi all, Resurrecting this ancient thread, and explicitly including Moxie and Trevor in case they aren't already on any of the relevant mailing lists. So ultimately I do think we should decide on either HPKP or TACK, but that we should make that decision after there has been some real-world deployment experience with both (or, sadly, real-world non-deployment of one or both). Additionally, HPKP and TACK might converge, more or less. I have plans to publish a new HPKP I-D that borrows some of TACK's pin activation and expiration ideas, for example. Additionally, one of the main criticisms of HPKP is that it is tied to HTTP. I currently don't consider that a huge problem — even though I consider TACK's TLS-generic-ness a nice benefit — for several reasons: * HTTPS is the big, important application that we need to secure right now. * IMAPS and POPS are surely on the list too, right after HTTPS; but specifying IPKP and PPKP is likely to be relatively straightforward once we get HPKP working. I am surely hoping there would be no IMAP, POP or SMTP extensions to address this. IMHO, judging from past experiences of any new functionality being adopted by IMAP/POP/SMTP, chances of such extensions being deployed in any reasonable number of email clients any time soon are close to 0. I think some more generic facility (like a TLS extension) has much better chance of success. Having said that, I think it is Ok if an HTTP facility is deployed now before the TLS extension is finalized. * It's not clear that SMTP over TLS is very beneficial, because you can't stop delivery due to pin validation failure (or really even regular old X.509 failure). You could use certificate errors as soft-fail spam signals, but you can in principle do that now, too, without explicit pinning. I don't know how much benefit you'd get from using pin validation failure as a spam signal. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [saag] Pinning
On Fri, 2012-08-10 at 15:20 -0700, Chris Palmer wrote: * It's not clear that SMTP over TLS is very beneficial, because you can't stop delivery due to pin validation failure (or really even regular old X.509 failure). That depends. Key pinning may not be very interesting for accepting coming mail from unknown sources, but it may be very interesting when TLS is used for communication between cooperating components of an enterprise mail system, or with an outsourced anti-smap or anti-virus or backup MX service. And of course, it's also interesting when TLS is used to protect authenticated mail submission services -- a user sending outgoing mail via his ISP probably doesn't want to tell his username and password to just anyone. * SSH already has PKP. Well, no. Certainly, SSH clients making a leap-of-faith connection to a previously unknown host will generally remember that host's public key. And yes, once a host's public key is known, clients will generally reject a host that presents a public key other than the one known for that host. But then, web browsers do the same thing for leap-of-faith connections to web servers, when a server has a self-signed certificate or one signed by an unknown CA. But while this behavior is common, it is not required by any standard, not something I'd expect an SSH client to do when an X.509 certificate is used, and not the same thing as key pinning. So in fact, if this gets done at the application layer, it likely will eventually have to happen for SSH, too. I would really rather not see a proliferation of application-layer extensions to handle pinning of the long-term keys used for TLS. While I haven't participated in previous discussion on this question, I think that in the long run this is much better handled at the TLS layer. That said, there may be a benefit to solving the problem for HTTP at the HTTP layer, _if_ doing so allows us to get something deployed more quickly than a TLS-layer solution. -- Jeff ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [saag] Pinning
On Aug 10, 2012, at 3:20 PM, Chris Palmer wrote: Additionally, one of the main criticisms of HPKP is that it is tied to HTTP. I am one of those people who expressed that criticism in the past. Having said that: I currently don't consider that a huge problem — even though I consider TACK's TLS-generic-ness a nice benefit — for several reasons: * HTTPS is the big, important application that we need to secure right now. * IMAPS and POPS are surely on the list too, right after HTTPS; but specifying IPKP and PPKP is likely to be relatively straightforward once we get HPKP working. Fully agree to both. TACK is more general, but HPKP's specificity is an advantage for deployability and interoperability, and other TLS-using application protocols can copy what they need from it when it is deployed. * It's not clear that SMTP over TLS is very beneficial, because you can't stop delivery due to pin validation failure (or really even regular old X.509 failure). You could use certificate errors as soft-fail spam signals, but you can in principle do that now, too, without explicit pinning. I don't know how much benefit you'd get from using pin validation failure as a spam signal. Even if you could, the SMTP community hasn't spent much effort and thinking about the value of TLS failure as spam signals. Until they do, it is not wise for us to gate our work on them. If they deal with it, they can then deal with things like pinning issues. * SSH already has PKP. :) And we can learn from that. And from the smiley. * The other common application protocols, like SIP, XMPP, and friends, are likely to also be pretty easy to extend in a manner similar to HPKP, IPKP, and PPKP. Yes. And finally, as Ben Laurie pointed out, there is also Certificate Transparency. I personally consider the public log class of solutions (of which CT is a leading member, along with Sovereign Keys) to be The Real Solution. Pinning-like solutions (including HPKP and TACK) are a good, quick fix — as long as they are quick and simple. Here is what I say about them proposals are orthogonal to here is what I say about myself proposals and should not be confused with each other. --Paul Hoffman ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [saag] Pinning
Hi Chris, all, On Fri, Aug 10, 2012 at 3:20 PM, Chris Palmer pal...@google.com wrote: So ultimately I do think we should decide on either HPKP or TACK, but that we should make that decision after there has been some real-world deployment experience with both (or, sadly, real-world non-deployment of one or both). My 2c: We should keep exploring both TACK and HPKP. I'd like to see both proposals fleshed out, so we can do an in-depth comparison. We'll try to send a draft-01 in a couple weeks. Additionally, HPKP and TACK might converge, more or less. I have plans to publish a new HPKP I-D that borrows some of TACK's pin activation and expiration ideas, for example. Awesome, looking forward to it. There's some things you'll have to grapple with (is pin activation performed for each key individually, or for the keys as a set? when is it performed? etc.) Additionally, one of the main criticisms of HPKP is that it is tied to HTTP. I currently don't consider that a huge problem — even though I consider TACK's TLS-generic-ness a nice benefit — for several reasons: * HTTPS is the big, important application that we need to secure right now. Agreed: TACK's TLS-generic-ness is a nice benefit, but a good solution for HTTPS is more important than reusability. * It's not clear that SMTP over TLS is very beneficial, because you can't stop delivery due to pin validation failure (or really even regular old X.509 failure). Pinning for MTA-to-MTA SMTP seems useful. Since receiving MTAs often have invalid certificates, they're hard to authenticate any other way. If a sending MTA doesn't want to reject connections on pin failure, it could run in warn-only mode. * SSH already has PKP. :) Not proposing to change that. But a TACK_Extension *could*, theoretically, be embedded in non-TLS, non-X.509 protocols... And TACK *does* have some nice lifecycle features (activation, break sigs, generations)... And finally, as Ben Laurie pointed out, there is also Certificate Transparency. I personally consider the public log class of solutions (of which CT is a leading member, along with Sovereign Keys) to be The Real Solution. Pinning-like solutions (including HPKP and TACK) are a good, quick fix — as long as they are quick and simple. I think pinning is likely to coexist or integrate with future trust systems. For example, Cert Transparency is cool and would help detect bad certs, but pinning would prevent their use. I think sites would want to deploy pinning even in a CT world. Also, self-asserted pins like TACK and HPKP can be detected by trust infrastructure (think Convergence or Google Cert Catalog) which publishes them for auditors to review and for client apps to download. So, in a broad sense (pinning, CT, Convergence) are all public knowledge systems which have some similar benefits. Anyways, quick and simple is always good, but we shouldn't view pinning as a disposable technology. (Not that you're saying that, but just don't want it to be misconstrued). Trevor ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [saag] Pinning
Hi Chris I've removed SAAG from CC, trimmed most of your message, and re-arranged the rest. Hope you don't mind… On Aug 11, 2012, at 1:20 AM, Chris Palmer wrote: Additionally, HPKP and TACK might converge, more or less. I have plans to publish a new HPKP I-D that borrows some of TACK's pin activation and expiration ideas, for example. hat type=chair Just as a reminder, HPKP is now a working group draft. As such, change control is with the WG. Changes that change the rules for activation and expiration should be proposed and discussed on the list first. Having said that, we are pretty far from last call on key-pinning, so I think it would be OK to publish a version -03 with such proposed changes, as long as those changes are clearly marked as not being the result of WG consensus. /hat As an individual, I understand the limitations of the spare public key approach of the current HPKP. It's an administrative hassle to generate n spare keys and keep them safe, and if you have n+1 key compromise events within the max-age time, your site is blocked. But it does have the big advantage that the server side can be deployed *now* with no additional software. Until I see how those borrowed ideas can help with these issues, I prefer HPKP. So ultimately I do think we should decide on either HPKP or TACK, but that we should make that decision after there has been some real-world deployment experience with both (or, sadly, real-world non-deployment of one or both). Well, there's WG deciding, and there's the market deciding. The IETF can publish both approaches (as either proposed standard or experimental) and the one (if any) that the market prefers can later be upgraded to standard (or it can stay at proposed anyway) Yoav ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [saag] Pinning
I don't know IETF procedure for making changes, but one of the outstanding issues I don't think has been resolved with draft-ietf-websec-key-pinning-02 is inherited DSA parameters. I raised this issue here: http://www.ietf.org/mail-archive/web/websec/current/msg01027.html with suggested verbiage. -tom On 11 August 2012 16:37, Yoav Nir y...@checkpoint.com wrote: Hi Chris I've removed SAAG from CC, trimmed most of your message, and re-arranged the rest. Hope you don't mind… On Aug 11, 2012, at 1:20 AM, Chris Palmer wrote: Additionally, HPKP and TACK might converge, more or less. I have plans to publish a new HPKP I-D that borrows some of TACK's pin activation and expiration ideas, for example. hat type=chair Just as a reminder, HPKP is now a working group draft. As such, change control is with the WG. Changes that change the rules for activation and expiration should be proposed and discussed on the list first. Having said that, we are pretty far from last call on key-pinning, so I think it would be OK to publish a version -03 with such proposed changes, as long as those changes are clearly marked as not being the result of WG consensus. /hat As an individual, I understand the limitations of the spare public key approach of the current HPKP. It's an administrative hassle to generate n spare keys and keep them safe, and if you have n+1 key compromise events within the max-age time, your site is blocked. But it does have the big advantage that the server side can be deployed *now* with no additional software. Until I see how those borrowed ideas can help with these issues, I prefer HPKP. So ultimately I do think we should decide on either HPKP or TACK, but that we should make that decision after there has been some real-world deployment experience with both (or, sadly, real-world non-deployment of one or both). Well, there's WG deciding, and there's the market deciding. The IETF can publish both approaches (as either proposed standard or experimental) and the one (if any) that the market prefers can later be upgraded to standard (or it can stay at proposed anyway) Yoav ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [saag] Pinning
Hi all, Resurrecting this ancient thread, and explicitly including Moxie and Trevor in case they aren't already on any of the relevant mailing lists. So ultimately I do think we should decide on either HPKP or TACK, but that we should make that decision after there has been some real-world deployment experience with both (or, sadly, real-world non-deployment of one or both). Additionally, HPKP and TACK might converge, more or less. I have plans to publish a new HPKP I-D that borrows some of TACK's pin activation and expiration ideas, for example. Additionally, one of the main criticisms of HPKP is that it is tied to HTTP. I currently don't consider that a huge problem — even though I consider TACK's TLS-generic-ness a nice benefit — for several reasons: * HTTPS is the big, important application that we need to secure right now. * IMAPS and POPS are surely on the list too, right after HTTPS; but specifying IPKP and PPKP is likely to be relatively straightforward once we get HPKP working. * It's not clear that SMTP over TLS is very beneficial, because you can't stop delivery due to pin validation failure (or really even regular old X.509 failure). You could use certificate errors as soft-fail spam signals, but you can in principle do that now, too, without explicit pinning. I don't know how much benefit you'd get from using pin validation failure as a spam signal. * SSH already has PKP. :) * The other common application protocols, like SIP, XMPP, and friends, are likely to also be pretty easy to extend in a manner similar to HPKP, IPKP, and PPKP. And finally, as Ben Laurie pointed out, there is also Certificate Transparency. I personally consider the public log class of solutions (of which CT is a leading member, along with Sovereign Keys) to be The Real Solution. Pinning-like solutions (including HPKP and TACK) are a good, quick fix — as long as they are quick and simple. On Wed, Jun 6, 2012 at 9:46 AM, Tobias Gondrom tobias.gond...@gondrom.org wrote: Sean et al., hat=individual I agree with Paul and Yoav and think the coordination between dane and websec on HSTS and key-pinning is ok. Both WGs are aware of potential coordination issues when mechanisms in both (DNSSEC and HTTP header) will be implemented eventually. I don't think we need an operations statement yet. Maybe at some point in the future an informational Best Practice or if you wish a Std Track can help. With regards to draft-perrin-tls-tack and draft-ietf-websec-key-pinning, I am not so sure about potential conflicts here and whether we need or want both. /hat Best regards, Tobias Ps.: hat=WG chair And on a personal note, one thing I am not so happy about is that I can see from the tls-tack draft, that the authors are aware of key-pinning (which is nice) and perceive that there would be flaws, yet they chose to not post their comments on it to websec nor inform the WG about their new draft. To make it easier in the future to coordinate the two drafts and possibly discuss and decide whether to boil down to one, it might make sense to inform websec about draft-perrin-tls-tack and have a discussion about it at some point there. Just my 5cents. /hat On 05/06/12 23:01, Paul Hoffman wrote: On Jun 5, 2012, at 2:46 PM, Yoav Nir wrote: The similarity of pinning and DANE has been discussed before. DANE relies on DNSSEC being deployed, which key-pinning does not. Correct. Further, key-pinning in HTTP only applies to HTTP and relies on the client being able to establish a TLS session using non-key-pinning semantics. Key-pinning in TLS relies works with any lower-layer protocol and relies on the client being able to establish a TLS session using non-key-pinning semantics. Come to think of it, the draft needs a section comparing with DANE, but that's for another thread. draft-perrin-tls-tack seems to tackle the same problem as key-pinning. Instead of the pins getting attested to in HTTP headers, you have a special public/private key pair, that you use to sign the SPKI from the server certificate within the a TLS extension. Like key-pinning there's a TOFU element here, because the client only learns about the special key when it encounters it in a TLS handshake. The obvious question is why would we need both key-pinning and tack. It would be clearer if you said both key-pinning in HTTP and key-pinning in TLS (tack). --Paul Hoffman ___ saag mailing list s...@ietf.org https://www.ietf.org/mailman/listinfo/saag ___ saag mailing list s...@ietf.org https://www.ietf.org/mailman/listinfo/saag ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [saag] Pinning
Sean et al., hat=individual I agree with Paul and Yoav and think the coordination between dane and websec on HSTS and key-pinning is ok. Both WGs are aware of potential coordination issues when mechanisms in both (DNSSEC and HTTP header) will be implemented eventually. I don't think we need an operations statement yet. Maybe at some point in the future an informational Best Practice or if you wish a Std Track can help. With regards to draft-perrin-tls-tack and draft-ietf-websec-key-pinning, I am not so sure about potential conflicts here and whether we need or want both. /hat Best regards, Tobias Ps.: hat=WG chair And on a personal note, one thing I am not so happy about is that I can see from the tls-tack draft, that the authors are aware of key-pinning (which is nice) and perceive that there would be flaws, yet they chose to not post their comments on it to websec nor inform the WG about their new draft. To make it easier in the future to coordinate the two drafts and possibly discuss and decide whether to boil down to one, it might make sense to inform websec about draft-perrin-tls-tack and have a discussion about it at some point there. Just my 5cents. /hat On 05/06/12 23:01, Paul Hoffman wrote: On Jun 5, 2012, at 2:46 PM, Yoav Nir wrote: The similarity of pinning and DANE has been discussed before. DANE relies on DNSSEC being deployed, which key-pinning does not. Correct. Further, key-pinning in HTTP only applies to HTTP and relies on the client being able to establish a TLS session using non-key-pinning semantics. Key-pinning in TLS relies works with any lower-layer protocol and relies on the client being able to establish a TLS session using non-key-pinning semantics. Come to think of it, the draft needs a section comparing with DANE, but that's for another thread. draft-perrin-tls-tack seems to tackle the same problem as key-pinning. Instead of the pins getting attested to in HTTP headers, you have a special public/private key pair, that you use to sign the SPKI from the server certificate within the a TLS extension. Like key-pinning there's a TOFU element here, because the client only learns about the special key when it encounters it in a TLS handshake. The obvious question is why would we need both key-pinning and tack. It would be clearer if you said both key-pinning in HTTP and key-pinning in TLS (tack). --Paul Hoffman ___ saag mailing list s...@ietf.org https://www.ietf.org/mailman/listinfo/saag ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
