http://blog.gmane.org/gmane.ietf.websec hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.websec/1348 <pre>Hi all This is to announce a WGLC for the subject draft. Version -06 makes the following changes: Changed non-normative pin generation code from Go to POSIX shell script using openssl. Changed max-max-age from SHOULD to MAY, and used the example of 60 days instead of 30. As we've started mid-week, let's give it a little more than two weeks, so please get in your comments by July 5th, and maybe we can get it out of the working group by Berlin. Thanks Yoav </pre> Yoav Nir 2013-06-19T05:43:41 http://comments.gmane.org/gmane.ietf.websec/1347 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Security Working Group of the IETF. Title : Public Key Pinning Extension for HTTP Author(s) : Chris Evans Chris Palmer Ryan Sleevi Filename : draft-ietf-websec-key-pinning-06.txt Pages : 21 Date : 2013-06-18 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-06-18T23:14:44 http://comments.gmane.org/gmane.ietf.websec/1341 <pre>Hi Version -05 of the draft has some proposed text for issue #57. UAs SHOULD set an upper limit on the value of max-age, so that UAs that have noted erroneous pins (whether by accident or due to attack) have some chance of recovering over time. If the server sets a max- age greater than the UA's upper limit, the UA SHOULD behave as if the server set the max-age to the UA's upper limit. For example, if the UA caps max-age at 2592000 seconds (30 days), and a Pinned Host sets a max-age directive of 60 days in its Valid Pinning Header, the UA SHOULD behave as if the max-age were effectively 30 days. (One way to achieve this behavior is for the UA to simply store a value of 30 days instead of the 60 day value provided by the Pinned Host.) For UA implementation guidance on how to select a maximum max-age, see Section 4.1. I think by now we've heard all the arguments back and forth for and against limits on max-age. So the question to the group is, can you live with the above text? If so, then I think we can move on to last call. With no hats, I can live with this text, although I have two issues with it: 1. I think the 30 days recommended in section 4.1 is too low, as I can think of many cases where a user would connect to a site from a particular device less often than every 30 days. 2. I think it's a bad idea to leave the max-max-age to the discretion of the UA. If an erroneous pin was set for a domain for, say, 10 years, the domain owner has no way of knowing how long the pin will be set on some devices, and will have to assume the longest of all the UA implementation he's ever heard of. IOW having one popular browser set the maximum to 30 days, while another sets it to 90 days means that as the domain owner, I have to assume that the pin is "out there" for 90 days. Yoav </pre> Yoav Nir 2013-06-11T21:51:37 http://comments.gmane.org/gmane.ietf.websec/1306 <pre>hi websec folks-- I am wondering what people think the proper intersection is between a web browser's mixed-content warnings and HSTS. For example, if https://example.net has asserted Strict-Transport-Security: max-age=15768000 but the homepage at https://example.net/ also contains &lt;img src="http://example.net/example.jpg"/&gt; should an HSTS-compatible browser show its standard mixed-content warning even though it knows to rewrite that img src to https://example.net/example.jpg ? My intuition is that this shouldn't trigger the browser's mixed-content warning, but chromium 26.0.1410.43 does show it, and https://code.google.com/p/chromium/issues/detail?id=122548#c26 suggests that palmer&lt; at &gt; and rsleevi&lt; at &gt; think that is the correct behavior because they want: I'm not sure how the author is supposed to get this signal from the site visitor's browser, though -- perhaps the expectation is that site visitors will independently report the "broken lock" to the site administrator? I also note that firefox 21.0 (when security.mixed_content.block_display_content = true) doesn't show the media at all, and when security.mixed_content.block_display_content = false it shows the image but removes the lock from the address bar (which i think is the equivalent of the "mixed content warning" these days). Do other folks have any thoughts about the right thing is to do here? --dkg </pre> Daniel Kahn Gillmor 2013-05-22T21:56:28 http://comments.gmane.org/gmane.ietf.websec/1298 <pre>I have just submitted an updated version of the session continuation draft. http://www.ietf.org/id/draft-hallambaker-httpsession-01.txt I didn't bring the first version to the list attention as I was not convinced all the parts really worked. I have since re-engineered the replay prevention mechanism and I think the result is more sensible. There is code, but this version is not tracking it (yet). I modified the examples to get the draft out the door so don't go checking it :-) The basic idea here is that this is a more or less drop in replacement for HTTP cookies but with much better security properties. To signal that it can accept session continuation in place of cookies, a client adds an Accept-Session header to a request. If the server accepts the offer of using session management it returns a response with a Set-Session header. After the context is set up, the client and server both add Session headers to request and response messages. The main change is on replay attack prevention which I now think needs to be different for requests and responses. Response replay attack prevention is easy. Just put a nonce in the request and the server returns in in the response. Problem solved. No need to keep any state or muck about with clocks. Request replay attack is trickier and I don't think we even want to try to do the job in HTTP, certainly not the whole job. If people want really solid request replay attack prevention for a Web service then they should write the code into their Web Service because HTTP does not have enough visibility into their transaction to know when the nonces should be there or not. The same mechanism could be extended to cover public key techniques (digital signatures). </pre> Phillip Hallam-Baker 2013-05-15T01:36:35 http://comments.gmane.org/gmane.ietf.websec/1293 <pre>Hi folks We think it's time to move on with Key Pinning, as there haven't been substantial issues raised in months. The one outstanding contentious issue is the one in the subject: http://trac.tools.ietf.org/wg/websec/trac/ticket/57 We've heard the argument that allowing pins to exist for indefinitely long can cause a site to be bricked for that period because of simple mistakes like changing certificate vendor or changing ownership of the domain name. We've also heard the counter-argument that some domains are visited infrequently, so short pins would do nothing for them. So here are some options. Please reply to this thread with with your preference. Arguments are good, but "+1" works as well. So… How should we handle the max-max-age issue: (1) No hard limits, but allow UAs to limit the pin time. Suggest a month (2) Set a hard limit of one month in the RFC. Longer pins are truncated. (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't been observed for some time (like a month) (4) Adopt some gradual confidence-building scheme a-la-TACK. "None of the above" is possible, but MUST come with argument and proposed text. Let's give this until Wednesday, 22-May. Thanks Tobias &amp; Yoav </pre> Yoav Nir 2013-05-07T07:13:28 http://comments.gmane.org/gmane.ietf.websec/1290 <pre>Hi, I would like to discuss a possible vulnerability in Public Key Pinning scheme (http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ ), related to certificate revocation checking. I would appreciate if anybody can review and verify my observations. Section 2.6 the draft states that when the UA connects to a pinned host, it must terminate the TLS connection, if there are any errors. The referred rfc, RFC 6797, clarifies that error could be related to certificate revocation checking or server identity checking. But it is not mandatory that during TLS handshake, UA performs certificate revocation or an assertive answer is found about the revocation status of the certificate. The reasons could be: 1. OCSP is disabled by default at the UA and the user has not changed it. 2. OCSP checking is disabled by the user. 3. OCSP check is performed but no answer is obtained from the OCSP server within the stipulated timeout. So it is very much possible that the UA accepts the PKP header from the host without verifying the revocation status of the host certificate used in TLS handshake. In the case of the host losing its private key to an attacker, the attacker may be able to block the host permanently from connecting to the UA, as explained below. The host’s CA would have revoked the certificate but the unreliability in revocation checking creates a vulnerability. Suppose an attacker is in possession of the private key of the host and the host certificate is duly revoked by the issued CA. Attacker may succeed in diverting the UA to his server when UA tries to connect to the valid host. Attacker may mount a DNS attack or a MIM attack to achieve this. Since he posses the valid private key, the TLS connection will be successful. The only other thing he needs is that UA doesn’t get to know the revocation status of the certificate. Here, the attacker is able to make the UA accept whatever PKP headers sent in the HTTP response. Say, the attacker has two key pairs, KeyPair1 and Keypair2, and holds a valid certificate for KeyPair1. He constructs a PKP header, Public-Key-Pins: max-age= (maximum possible value); pin-sha1= (pin corresponding to compromised key); pin-sha1= (pin corresponding to KeyPair1); When UA accepts this PKP header, effectively the attacker is able to set a new backup pin. The attacker can set a new PKP header in subsequent connection. He can use KeyPair1 in the TLS handshake. Public-Key-Pins: max-age= (maximum possible value); pin-sha1= (pin corresponding to KeyPair1); pin-sha1= (pin corresponding to KeyPair2); Now the UA sets both pins to be attacker’s pins and the valid host is permanently blocked from connecting to the UA. To avoid this attack, shouldn’t we mandate revocation checking when PKP headers are accepted? Thanks, Vinod. </pre> vinod kumar 2013-05-02T09:50:35 http://comments.gmane.org/gmane.ietf.websec/1289 <pre>We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ websec mailing list websec&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/websec </pre> hammondjohnson< at >hushmail.com 2013-04-27T17:55:21 http://comments.gmane.org/gmane.ietf.websec/1287 <pre>I hear more and more talk about HPKP being used primarily in Report-Only mode. I think that's fair, as website operators are very *very* nervous about bricking themselves. But it also takes away the ability of users to be proactive about these (possible) violations. How do people feel about the following addition to the "Reporting Pin Validation Failure" section (probably under a new sub-section): If a UA provides extensibility points to be used by third party extensions or plugins, it [MAY?/SHOULD?] provide extensibility points relating to failures in both enforcement and Report Only mode. I envision a browser extension (which is naturally an opt-in mechanism) that flags Report Only violations so users are aware of them, and can investigate. I envision another one, perhaps run by the EFF, Google, or other trustworthy organization that actually sends these reports anonymized to a central database (besides the report-uri) where volunteers or employees could review them for suspicious entries. -tom </pre> Tom Ritter 2013-04-17T13:42:56 http://comments.gmane.org/gmane.ietf.websec/1286 <pre>Hi websec, Long email, sorry! TLDR: HPKP could do TACK-like "pin activation" for safer pinning. ----- At one point, the HPKP draft mentioned "pin activation" a la TACK [1]. In TACK's algorithm, a client has to observe a pin assertion multiple times before "activating" a pin. After the first observation, subsequent observations cause the pin to be activated for a period equal to the span in which the client has observed the assertion, or a max of 30 days. The goal of this is to limit damage from malicious or mistaken "bad pins", with a side benefit of simplifying deployment: * If connections to a domain are being hijacked (due to DNS hijacking, domain name theft, an intercepted Wifi connection, etc.), and the attacker is atttempting to set a malicious pin, the resultant pin will not last longer than the attacker has already controlled the connection for (e.g., if you're at a coffee-shop for 2 hours, it can't set bad pins that last more than 2 hours; if a domain name is hijacked for 2 days, bad pins will expire 2 days afterwards; etc.) * If a site advertises bad pins for itself, perhaps due to a configuration mistake, a hacker, or a disgruntled system administrator, damage will be limited if the mistake is noticed and corrected quickly. * Since pin lifetimes are automatically scaled in a way which allows safe rollout (with quick removal an option if things go wrong), we can potentially do without an explicit max-age, making deployment simpler (one less knob the deployer has to turn). </pre> Trevor Perrin 2013-04-16T00:23:34 http://comments.gmane.org/gmane.ietf.websec/1260 <pre>#57: Re-add an upper limit to max-age At IETF 86, it was decided that there should be an upper limit to the max- age directive </pre> websec issue tracker 2013-03-22T21:36:03 http://comments.gmane.org/gmane.ietf.websec/1253 <pre>Hi I have reviewed this draft, and here are some comments. Section 2.1 last paragraph says that the hash function MUST be sha1 or sha256. This is weird. First it provides no algorithm agility, so adding support for, say, SHA-3 would require a document that updates this one (section 2.4 says so explicitly). Second, SHA2-256 is slower on 64-bit platforms than SHA2-512, so right now some may prefer it. Third, in various locales, some other hash function might be required, such as GOST-34.311-95. I would much prefer that we referred to a registry of hash names ( perhaps this one&lt;http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml&gt; ), and allow anything from there (notably, it doesn't solve the GOST issue). There should be implementation advice advising support of SHA-1 and SHA-256, perhaps even calling them "mandatory to implement", but I don't think we need to require a new spec for updating a list of algorithms. It might also be good to advise on using the same hash algorithm that is used in the signature of the certificate, as the client would be sure to be able to calculate the hash function (or it wouldn't be able to verify the certificate signature. Some of the mandates in section 2 are mixed up. Section 2.2.1 second sentence has "… UAs MUST treat the host …" - clearly a UA mandate. But this is part of section 2.2 ("Server Processing Model"). UA mandates should be somewhere under section 2.3 ("User Agent Processing Model"). Some cleaning up is needed there. Section 2.6 requires the same no-error-or-block behavior here as in HSTS. I wonder if we need this level of strictness, or whether requiring this only for errors involving the verification of pins. IOW, should this document require that expired certificates cause a block, when such policy can and should be communicated via HSTS? Section 2.8 is about pinning self-signed (or self-issued) certificates. Should mention DANE (RFC 6698) type 2 or 3, because those are a more trust-worthy case than normal self-signed or self-issued certificates. Section 4 (security considerations) should have something about why it's wrong to use this header without HSTS. 3rd paragraph of section 1 says that using them together is intended, so we should explain why. Section 5: yes, there are actions for IANA, as they allocate HTTP headers (other than X-something). See the text from draft -14 of HSTS: 15&lt;http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-14#section-15&gt;. IANA Considerations Below is the Internet Assigned Numbers Authority (IANA) Permanent Message Header Field registration information per [RFC3864&lt;http://tools.ietf.org/html/rfc3864&gt;]. Header field name: Strict-Transport-Security Applicable protocol: HTTP Status: standard Author/Change controller: IETF Specification document(s): this one A more structural note: The introduction looks a little thin to me. The draft dives into syntax in section 2 before the reader has any idea: * When and why you should want to add this header to your web server responses. What is this defending against * Why you would want to pin an end-entity key, and alternatively why you would want to ping something higher up the chain * What does it mean when there are multiple pins. AND? OR? The third question is answered later in the draft, but I think this information should go in the introduction. And one nit: * The upper-case SHOULD in the introduction seems inappropriate. RFC 2119 labels SHOULD (not sure this is even a pun) be used for cases of interoperability or for preventing harm. Here, the use is the simple English "should", and doesn't mandate anything at all, so it ought to be lower-case: "We propose a new HTTP header to enable a web host to express to user agents (UAs) which Subject Public Key Info (SPKI) structure(s) UAs *should* expect to be present in the host's certificate chain in future connections using TLS (see [RFC5246]). Note: this review is with no hats. It is not part of some last-call process. Please treat this as any other review on the list. Yoav </pre> Yoav Nir 2013-03-18T04:21:13 http://comments.gmane.org/gmane.ietf.websec/1251 <pre>The main substantive query that seemed to be raised in the meeting was what we are going to call this session continuation thing. I am not that worried about confusion with HTTP-Auth. Folk who know, know. But one of the objectives here is to replace cookies. So choosing a name that positions the spec as a successor to authentication cookies is actually quite important. How about Session Bound State as the term of art? </pre> Phillip Hallam-Baker 2013-03-14T03:49:53 http://comments.gmane.org/gmane.ietf.websec/1250 <pre>Hi all Following our meeting today, I have uploaded the preliminary meeting minutes. Thanks again to Brad Hill for taking minutes during the meeting. Please send any corrections directly to me. Yoav Link: http://www.ietf.org/proceedings/86/minutes/minutes-86-websec </pre> Yoav Nir 2013-03-14T02:29:15 http://comments.gmane.org/gmane.ietf.websec/1249 <pre>Hi all. The agenda is updated and the meeting slides are not on the meeting materials page. We will be discussing a proposal to replace the session cookie mechanism. For a comprehensive review of what is wrong with using cookies to maintain sessions, you may want to read the document "Weaning the Web Off of Session Cookies" [1]. We are not likely to have time to discuss all of these issues, but we could be trying to solve them. Links: * Agenda: http://www.ietf.org/proceedings/86/agenda/agenda-86-websec * Slides: https://datatracker.ietf.org/meeting/86/materials.html#websec * Weaning the Web Off of Session Cookies: http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf Yoav [1] Not to be confused with "Weaning the IETF Off of inter-Session Cookies" </pre> Yoav Nir 2013-03-12T17:15:44 http://comments.gmane.org/gmane.ietf.websec/1237 <pre>As discussed during Atlanta, and as raised in http://trac.tools.ietf.org/wg/websec/trac/ticket/54 , there's a strong desire for a Content Security Policy-like report and report-only mode. The use of a report mode is not as an attack mitigation, but as a way of sites to be informed of misconfigurations. The use of a report-only mode is as a way to allow sites to experiment with and deploy a Pinning Policy effectively. Given that pinning is effectively ultimately dependent on client trust and PKI policies, it's important for site operators to be able to ensure their proposed pinning policy will work effectively. To that end, draft-04 has introduced the report-uri directive, Section 2.1.3, http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.3 , which allows a site to specify a URL to direct reports, as described in Section 3 - http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-3 In addition, and in the spirit of CSP, we'd like to propose the addition of a Public-Key-Pins-Report-Only header, as described in Section 2.1 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1 - as a compliment to the Public-Key-Pins header. This header would follow the same syntax and semantics of the Public-Key-Pins header, with the exception of not actually enforcing the pins (as described Section 2.6). I'd like to solicit feedback and make sure that both the discussions from Atlanta and from the list have been accurately captured. Are there concerns with a Report-Only mode that have not been accurately captured? </pre> Ryan Sleevi 2013-03-05T01:09:36 http://comments.gmane.org/gmane.ietf.websec/1236 <pre>With Key Pinning being split out from HTTP Strict Transport Security, one aspect that was lost was the includeSubDomains directive. This was raised as Issue 56 - http://trac.tools.ietf.org/wg/websec/trac/ticket/56 - against draft-03 draft-04 introduces the same directive, and with the same semantics, in Section 2.1.2 - http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.2 Is the added language acceptable? Are there any concerns with the validation/processing model that would prevent us from closing out this issue? </pre> Ryan Sleevi 2013-03-05T00:58:14 http://comments.gmane.org/gmane.ietf.websec/1235 <pre>This was raised with http://trac.tools.ietf.org/wg/websec/trac/ticket/55 , as a concern about the interaction between static/preloaded pin entries and those that were noted later (eg: through the observation of the header) In draft-04, Section 2.7 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.7 addresses this by indicating that UAs MUST use the newest information available. Note: This does not normatively describe how a UA must determine newest. The assumption here is that this represents the "newest observed", but the question is whether or not that should be explicitly specified. For example, imagine a UA that supports automatic updates to Preloaded Pin Lists. One interpretation of "newest information" would be to look at the most recent update to the preloaded pin list as a whole. Another interpretation of "newest information" may be to look at the date/time that the entry was originally added/updated in the "preloaded pin list". Imagine this UA had a preload for Site 1 to a set of pins, with the preload created at T=0. Later, at T=5, it observes a Max-Age of 0, effectively unpinning the host. At T=10, the UA vendor ships a new update to the preloaded pin list that adds Site 2, but which has not been updated to unpin Site 1. Under the first interpretation of "newest information", Site 1 would be "reactivated", by virtue of observing an update to the preloaded pin list. Under the second interpretation, Site 1 would remain unpinned. The authors belief is that the issues that arise from either implementations are artifacts of the implementation and distribution of preloaded pins, rather than an issue intrinsic to this specification. That is, the "correct" answer is that the preloaded pin list should be updated for Site 1 - however that information is distributed between the site operator and the creator of the preloaded pin list. Are there concerns with this interpretation, or can we close out Issue 55? </pre> Ryan Sleevi 2013-03-05T00:57:56 http://comments.gmane.org/gmane.ietf.websec/1234 <pre>This was raised during our discussions in Atlanta, and continued on the mailing list under http://trac.tools.ietf.org/wg/websec/trac/ticket/53 As discussed during Atlanta, the way that pinning is currently implemented within Google Chrome, pinning is only enforced as it relates to so-called "public trust anchors" (eg: those shipped by default as part of a browser or OS installation, not those installed by a user). The motivation for this was and is simple: If you have sufficient local privilege to install additional trust anchors on a device, then it's presumed you have sufficient privilege to take any number of other actions, including disabling pinning enforcement entirely. As such, having the UA disable enforcement selectively is strictly less worse, from a security perspective, than having the UA disable enforcement entirely, and still provides significant benefit through the reduction of risk through public trust anchors. However, this creates an interesting split between the specification language and implementations. In draft-04, we've tried to clarify this through the text in Section 2.6, http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.6 , along with the addition of a "strict" mode, as described in Section 2.1.4, http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.4 While there is an open question as to whether or not such user-agent behaviour is appropriate to specify here, does the group feel the proposed text sufficiently addresses the issue as originally raised? </pre> Ryan Sleevi 2013-03-05T00:57:20 http://comments.gmane.org/gmane.ietf.websec/1233 <pre>This was one of the outstanding issues from draft-03, raised in http://trac.tools.ietf.org/wg/websec/trac/ticket/52 The Chrises and I believe this has been addressed sufficiently in draft-04, through the clarifications in http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.1 and http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.3.1 Are there any objections to closing this out? </pre> Ryan Sleevi 2013-03-05T00:56:24 http://comments.gmane.org/gmane.ietf.websec/1225 <pre>Hi all The WebSec working group will meet in Orlando, on Wednesday, March 13th at 15:10. On the agenda are our current work items (framework requirements and key pinning) plus discussion of a proposed item, session continuation (or "session management") We have a two hour session, which should suffice. If anyone would like to request a time slot to present or discuss some other issue, please contact Tobias and me really soon. For your convenience, here are links to the drafts we will be discussing: - Framework Requirements: http://tools.ietf.org/html/draft-ietf-websec-framework-reqs - Key Pinning: http://tools.ietf.org/html/draft-ietf-websec-key-pinning - X-Frame-Options: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options - Session Continuation: http://tools.ietf.org/html/draft-williams-websec-session-continue-prob Yoav &amp; Tobias WG Chairs </pre> Yoav Nir 2013-02-19T22:16:05 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.websec