Alexey replied:
>
> On 27/08/2012 21:18, Tobias Gondrom wrote:
>> Hello dear websec fellows,
>>
>>
>> we have so far only very few comments regarding this. If you feel
>> strongly either way, please say so ASAP, within the next 5 days (until
>> Sep-1), otherwise we will have to go with the few co
On 27/08/2012 21:18, Tobias Gondrom wrote:
Hello dear websec fellows,
we have so far only very few comments regarding this. If you feel
strongly either way, please say so ASAP, within the next 5 days (until
Sep-1), otherwise we will have to go with the few comments we received
to judge conse
On Aug 27, 2012, at 1:28 PM, Yoav Nir wrote:
> With no hats: let's not choose a policy for a registry that we are not
> setting up, especially since we're not even sure that it's ever going to be
> set up.
>
> We can leave it to the first extension document to set up the registry and
> policy
With no hats: let's not choose a policy for a registry that we are not setting
up, especially since we're not even sure that it's ever going to be set up.
We can leave it to the first extension document to set up the registry and
policy. If that document ever comes.
Yoav
On Aug 27, 2012, at 11
Hello dear websec fellows,
we have so far only very few comments regarding this. If you feel
strongly either way, please say so ASAP, within the next 5 days (until
Sep-1), otherwise we will have to go with the few comments we received
to judge consensus based on them.
Thank you, Tobias
On
On 08/20/2012 10:55 AM, =JeffH wrote:> Thanks for the clarification Barry. Yes,
this question is in response to Ben
> Campbell's review comment (which I was going to note, but you took care of it
:)
>
> > "We need to decide on an IANA policy *or* explicitly decide that we
> > don't want to cho
Thanks for the clarification Barry. Yes, this question is in response to Ben
Campbell's review comment (which I was going to note, but you took care of it :)
> "We need to decide on an IANA policy *or* explicitly decide that we
> don't want to choose that now, and leave it to whoever creates the
On 19/08/12 01:56, Barry Leiba wrote:
I'd also noted that we need to decide on a IANA policy to declare.
Do we need to do this? Assuming the proposed resolution achieves
consensus (and there have been no nays yet), we're not setting up a
registry. I don't think we get to set a policy for a regi
>>> I'd also noted that we need to decide on a IANA policy to declare.
>>
>> Do we need to do this? Assuming the proposed resolution achieves
>> consensus (and there have been no nays yet), we're not setting up a
>> registry. I don't think we get to set a policy for a registry we're not
>> setting
On 18/08/12 07:21, Yoav Nir wrote:
On Aug 18, 2012, at 1:55 AM, =JeffH wrote:
Yoav Nir noted:
As a reminder, the proposed resolution is as follows:
* Do not establish a registry now
Let the first new header field specification establish it
* A client that gets an unknown field ignores
On Aug 18, 2012, at 1:55 AM, =JeffH wrote:
> Yoav Nir noted:
>>
>> As a reminder, the proposed resolution is as follows:
>>
>> * Do not establish a registry now
>> Let the first new header field specification establish it
>>
>> * A client that gets an unknown field ignores it
>> This
Yoav Nir noted:
>
> As a reminder, the proposed resolution is as follows:
>
> * Do not establish a registry now
> Let the first new header field specification establish it
>
> * A client that gets an unknown field ignores it
> This means no mandatory-to-understand extensions
Thanks,
From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On Behalf Of
Barry Leiba
Sent: Tuesday, August 14, 2012 7:14 AM
To: IETF WebSec WG
Subject: Re: [websec] handling STS header field extendability
Please forgive my ignorance, but do LockCA and/or LockEV offer any
functionality that
: Tuesday, August 14, 2012 7:14 AM
To: IETF WebSec WG
Subject: Re: [websec] handling STS header field extendability
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?
Folks, this thread has r
>
> 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?
>
Folks, this thread has rather been hijacked. We need to have some WG
input on what registration policy to recommend for a possible
On Aug 13, 2012, at 2:31 PM, Hill, Brad wrote:
> tl;dr version:
>
> EV is not a security boundary today in web user agents, it is a way to get a
> user interface decoration.
>
> If we want to ask browser vendors to make it into a security boundary which
> they will defend, we need to think abo
> Not to intentionally pick on PayPal — sorry, Brad :) — but the attack works
> because of explicit cross-origin script inclusion. The first demo of this
> attack I
> saw was by Sotirov and Zusman at CanSecWest some years ago. In the attack
> demo, EV paypal.com includes (included) script from no
On Mon, Aug 13, 2012 at 12:21 PM, Collin Jackson
wrote:
> Quite the opposite, you just made the argument in favor of LockEV. If
> LockEV is being used, the MITM attack with a DV certificate would no
> longer be possible, because the DV certificate would not be accepted
> by the browser.
Not to i
On Aug 13, 2012, at 2:09 PM, Collin Jackson wrote:
> Brad was describing a network attacker that was able to obtain a DV
> certificate (but not an EV certificate) for a target site. The
> attacker can "act as a partial MITM and provide, using a DV
> certificate, trojan script content in an iframe
I don't understand your question, but I'll attempt to rephrase my comment.
Brad was describing a network attacker that was able to obtain a DV
certificate (but not an EV certificate) for a target site. The
attacker can "act as a partial MITM and provide, using a DV
certificate, trojan script conte
On Aug 13, 2012, at 12:21 PM, Collin Jackson wrote:
> On Mon, Aug 13, 2012 at 10:58 AM, Hill, Brad wrote:
>> There are, of course, non-browser HTTP clients that may respect HSTS, but EV
>> certificates in particular are aimed at a browser audience as it is about
>> user trust indicators.
>>
>>
On Mon, Aug 13, 2012 at 10:58 AM, Hill, Brad wrote:
> There are, of course, non-browser HTTP clients that may respect HSTS, but EV
> certificates in particular are aimed at a browser audience as it is about
> user trust indicators.
>
> EV is *not* a security boundary in browsers, however. It is
c-boun...@ietf.org] On Behalf
> Of Tom Ritter
> Sent: Saturday, August 11, 2012 7:43 AM
> To: Chris Palmer
> Cc: Ben Campbell; IETF WebSec WG
> Subject: Re: [websec] handling STS header field extendability
>
> On 10 August 2012 17:52, Chris Palmer wrote:
> > Please forgive m
On 10 August 2012 17:52, Chris Palmer 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' publi
On Thu, Aug 9, 2012 at 3:09 PM, =JeffH wrote:
> The only extensions we'd discussed in the past were the CertPinning, LockCA,
> LockEV. We've decided that cert pinning is an intersecting but orthogonal
> policy to HSTS, and thus best handled at this point via a separate header
> field.
> Also, th
Hi, here's a write-up on the background of, and proposed resolution to the
question of handling STS header field extendability more properly in the spec.
I also pose the question of which IANA policy to declare, down at the very end.
thanks,
=JeffH
Background:
--
We've defined the S
26 matches
Mail list logo
