Re: CSP: Minimum cipher strength

The CA/Browser Forum <https://cabforum.org/> is one of the major
organizations driving policy decisions around TLS certificates for TLS
clients and Certificate Authorities.

Perhaps the most visible effect is member Certificate Authorities are not
issuing certificates for IP addresses, nor private intranet names, past
November 1, 2015.

The five top Web browser vendors are also members.

TLS itself, of course, does not and can not make policy decisions like
minimum required cipher, though known insecure parameters (like data
compression) are being removed with TLS 1.3.

TLS is, appropriately, designed so policy decisions can evolve rapidly
around the technology without necessitating updates to the standard itself.

The concern of manipulating TLS connections is not a new one, nor one
specific to HTTP, and there's much work being done elsewhere that would
benefit more applications than just Web services. Problems like a rogue CA
can be addressed with RFC 6698 or the proposed Public-Key-Pins HTTP header
(in draft); additionally, an attacker can only downgrade a connection to
one that both ends are willing to use, so simply disable the insecure
ciphers on your server to set a "minimum cipher strength". Specifically,
SSL 3.0 should be disabled.

Is the intent to not load _third party_ resources that fail to meet the
requirements? I would be concerned that it offers a false sense of
security: Third parties can still become untrusted, become compromised,
etc, even without a MITM attack. Simply don't load executable code from
third parties, and use CSP to enforce it.

Austin.

On Sun, Sep 14, 2014 at 2:39 PM, Jim Manico <jim.manico@owasp.org> wrote:

> > Ultimately, I agree with Mike - the solution to solve this (generally)
> is for UAs to start deprecating things
>
> Is there some kind of "rolling standard" that could be set to that all
> UA's are on the same page? This seems fairly arbitrary as it stands
> today...
>
> --
> Jim Manico
> @Manicode
> (808) 652-3805
>
> On Sep 13, 2014, at 8:37 PM, Tom Ritter <tom@ritter.vg> wrote:
>
> >> Ultimately, I agree with Mike - the solution to solve this (generally)
> is
> >> for UAs to start deprecating things
>
>
>