Re: [websec] handling STS header field extendability
On 10 August 2012 17:52, Chris Palmer pal...@google.com wrote:
Please forgive my ignorance, but do LockCA and/or LockEV offer any
functionality that you can't already get with public key pinning as
currently specified? You can pin to a given CA's public key(s), and
you can pin to any given EV issuers' public keys.
I can't think of one for Lock CA; but LockEV could be useful for sites
that want to deploy some additional measure, but can't/don't want to
a) commit to a CA or b) enumerate all possible EV authorities. It
should be ('should be', not 'is') more difficult to get a fraudulent
EV certificate through trickery or treachery than a DV certificate.
I don't think browsers differentiate between OV and DV in any
meaningful way, but I could be wrong.
-tom
___
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
[websec] #50: Handing of pinning DSA public keys
#50: Handing of pinning DSA public keys http://www.ietf.org/mail-archive/web/websec/current/msg01027.html To close up the hole with inherited parameters, in 2.2, prior to the We pin public keys note, add: If the SubjectPublicKeyInfo of a certificate is incomplete when taken in isolation, such as when holding a DSA key without domain parameters, a public key pin cannot be formed. -- -+- Reporter: Tom Ritter | Owner: draft-ietf-websec-key-pinning@… Type: defect | Status: new Priority: major| Milestone: Component: key-pinning |Version: Severity: -| Keywords: -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/50 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #51: Clarification of section 2.4
#51: Clarification of section 2.4 In 2.4, adding a phrase to the parenthetical comment in the big paragraph : If the connection has no errors, the UA will then apply a new correctness check: Pin Validation. To perform Pin Validation, the UA will compute the fingerprints of the SPKI structures in each certificate in the host's validated certificate chain. (The UA ignores certificates whose SPKI cannot be taken in isolation and superfluous certificates in the chain that do not form part of the validating chain.) The UA will then check that the set of these fingerprints intersects the set of fingerprints in that host's Pinning Metadata. If there is set intersection, the UA continues with the connection as normal. Otherwise, the UA MUST treat this Pin Failure as a non-recoverable error. -- -+- Reporter: Tom Ritter | Owner: draft-ietf-websec-key-pinning@… Type: defect | Status: new Priority: major| Milestone: Component: key-pinning |Version: Severity: -| Keywords: -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/51 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #52: Clarification of section 2.3.1
#52: Clarification of section 2.3.1 I'd suggest the following change to 2.3.1, clarifying it's required-ness and a max-age of 0. 2.3.1. max-age max-age specifies the number of seconds, after the reception of the Public-Key-Pins HTTP Response Header, during which the UA regards the host as a Pinned Host. The delta-seconds production is specified in [rfc-2616]. max-age is a required attribute. If omitted, the UA MUST NOT note the host as a Pinned Host, and MUST discard any previously set Pinning Metadata for that host in its non-volatile store. If max-age is set to 0, the UA MUST likewise discard any previsouly set Pinning Metadata. -- -+- Reporter: Tom Ritter | Owner: draft-ietf-websec-key-pinning@… Type: defect | Status: new Priority: major| Milestone: Component: key-pinning |Version: Severity: -| Keywords: -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/52 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
