[websec] draft-ietf-websec-mime-sniff

[Same preface I gave when I spoke at the mic in the WG session: I am speaking as an individual IETF participant, not as an AD. This comment by itself will not cause me to DISCUSS the document when it comes to the IESG. If the consensus of the WG is that I am wrong about this, I may validly end

Re: [websec] HSTS: Maintenance of hardcoded lists in clients

On Mon, 25 Jul 2011 22:28:02 +0200, Gervase Markham wrote: On 25/07/11 11:13, Yngve N. Pettersen wrote: At least one client supporting HSTS (maybe more) is using a hardcoded list of sites that are always HSTS enabled, as a method of countering the bootstrap problem. Is "the bootstrap probl

Re: [websec] Public Suffix definition

On Mon, 25 Jul 2011 22:41:00 +0200, Gervase Markham wrote: On 25/07/11 11:17, Yngve N. Pettersen wrote: This draft, which tries to define the term "Public Suffix", as used in cookies and document.domain, and elsewhere, may be of interest to the websec group.

Re: [websec] HSTS: Maintenance of hardcoded lists in clients

On Jul 25, 2011, at 4:28 PM, Gervase Markham wrote: > On 25/07/11 11:13, Yngve N. Pettersen wrote: >> At least one client supporting HSTS (maybe more) is using a hardcoded >> list of sites that are always HSTS enabled, as a method of countering >> the bootstrap problem. > > Is "the bootstrap pro

Re: [websec] Public Suffix definition

On 25/07/11 11:17, Yngve N. Pettersen wrote: > This draft, which tries to define the term "Public Suffix", as used in > cookies and document.domain, and elsewhere, may be of interest to the > websec group. > > Hi Yngve, Do you have

Re: [websec] HSTS: Maintenance of hardcoded lists in clients

On 25/07/11 11:13, Yngve N. Pettersen wrote: > At least one client supporting HSTS (maybe more) is using a hardcoded > list of sites that are always HSTS enabled, as a method of countering > the bootstrap problem. Is "the bootstrap problem", the problem that on your very first visit to a site, you

Re: [websec] HSTS: Maintenance of hardcoded lists in clients

On Mon, Jul 25, 2011 at 2:13 PM, Yngve N. Pettersen wrote: > For HSTS I expect that the number of websites wanting to get on the list(s) > is going to number in the thousands (with one million sites, even 0.1% is > 1000), which is likely to cause trouble for the maintainers of the list(s). I main

[websec] Public Suffix definition

Hi, This draft, which tries to define the term "Public Suffix", as used in cookies and document.domain, and elsewhere, may be of interest to the websec group. -- Sincerely, Yngve N. Pettersen *

[websec] HSTS: Maintenance of hardcoded lists in clients

Hi, As mentioned just now in the Websec WG meeting. At least one client supporting HSTS (maybe more) is using a hardcoded list of sites that are always HSTS enabled, as a method of countering the bootstrap problem. As I understand it, the process for how a website get on such lists is cu

[websec] Resource Timing draft

FYI, the resource timing draft that I just mentioned in the websec meeting is here: http://www.w3.org/TR/2011/WD-resource-timing-20110524/ The section with the Timing-Allow-Origin HTTP header is here: http://www.w3.org/TR/2011/WD-resource-timing-20110524/#cross-origin-resources

Re: [websec] Websec meeting in Quebec on July-25

Hello, please be informed that all slides for our meeting are now online in the Meeting Materials manager: https://datatracker.ietf.org/meeting/81/materials.html Kind regards, Tobias On 23/07/11 00:09, Tobias Gondrom wrote: Hello dear websec fellows, just some final updates for our meeting o

Re: [websec] #12: Remove dependencies on HTTPbis and depend on RFC2616 only

On 7/24/11 9:22 PM, websec issue tracker wrote: > #12: Remove dependencies on HTTPbis and depend on RFC2616 only > > -strict-transport-sec has various dependencies (e.g. STS header field > ABNF) on HTTPbis. > > HTTPbis may not complete in a timeframe workable for having -strict- > transport-s