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/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 </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)</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 f</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 t</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. -</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 </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 algorith</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</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 se</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 a</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 http://comments.gmane.org/gmane.ietf.websec/1210 <pre>Hi, https://tools.ietf.org/html/rfc6454 fails to properly account for a number of cases where URIs and URI schemes are slightly unusual, e.g. The origin of a URI is the value computed by the following algorithm: 1. If the URI does not use a hierarchical element as a naming authority (see [RFC3986], Section 3.2) or if the URI is not an absolute URI, then generate a fresh globally unique identifier and return that value. ... 2. Let uri-scheme be the scheme component of the URI, converted to lowercase. 3. If the implementation doesn't support the protocol given by uri- scheme, then generate a fresh globally unique identifier and return that value. Consider `javascript://example.org`. In order to make the determination whether "the URI" uses "a hierarchical element as a naming authority" you have to know the scheme, but the scheme is not mentioned until after the first step, which may lead one to believe that you can make this de- termination wit</pre> Bjoern Hoehrmann 2013-02-13T14:09:47 http://comments.gmane.org/gmane.ietf.websec/1208 <pre>This bug at Mozilla was recently brought to my attention: https://bugzilla.mozilla.org/show_bug.cgi?id=836132 It seems to indicate that the specified EBNF of using a colon between "ALLOW-FROM" and the URI is not the actual behavior of most user agents that implement that functionality. Perhaps we should update this to reflect the predominant implementation in the field. (Internet Explorer's) -Brad </pre> Hill, Brad 2013-02-11T22:09:50 http://comments.gmane.org/gmane.ietf.websec/1200 <pre>Hi there, I realise that this proposal might be rather late in the process, but would it be possible to add a list of excluded subdomains in the STS header? My use case is that I am setting up a new service which has the STS header set so that users might have a more secure experience. However, for the purposes of sending referrer path information to non-HTTPS sites, I have one subdomain which does redirects over plain HTTP, e.g. http://from.espra.com/some/referrer/path. In an ideal world, I would be able to set a comprehensive STS header which excluded just that one subdomain, e.g. Strict-Transport-Security: max-age=31536000; includeSubDomains; exclude=from.espra.com And since having an exclude implicitly suggests includeSubdomains, it could be shortened to just: Strict-Transport-Security: max-age=31536000; exclude=from.espra.com There are, of course, alternative solutions, e.g. using another domain for the HTTP redirect or setting STS on individual subdomains without specifying includeSubdomains</pre> tav 2013-01-15T22:57:36 http://comments.gmane.org/gmane.ietf.websec/1197 <pre>Hello, Just jumped over here from the http list per Yoav Nir's request for feedback with regards to the draft-williams-websec-session-continue-prob draft. Overall I think the draft is a good start. There definitely does need to be more of an explanation as to why the existing cookie-based mechanism is bad. As far as more forward looking feedback is concerned, I wanted to point to the In-Session Key Negotiation draft I wrote as input to the ongoing http/2 discussion http://tools.ietf.org/html/draft-snell-httpbis-keynego-00 This draft introduces a new (currently experimental) bidirectional key-negotiation sub-protocol within spdy/http2 for the negotiation of secure keys and can be used for the establishment of authenticated and unauthenticated sessions. (Note that I'm just making sure folks know about this draft as it is relevant to the discussion)... Running down through the list of requirements stated by the websec-session-continue-prob draft it covers a good deal of the issues. - James </pre> James M Snell 2013-01-14T21:36:28 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.websec