Re: Mandatory encryption

On Tue, Jul 17, 2012 at 9:50 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> Perhaps you are not aware that I work for a CA and I have spent 20
> years working on Web security, most of it developing the CA industry
> and PKI infrastructure.
>
> Maintaining the policies for accepting trust roots is essentially a
> full time job for each of the parties doing it. It is not just a
> matter of checking that a CA has a valid audit. The root manager has
> to determine that the audit actually relates to the root of trust to
> be included and that the practices adhered to meet the necessary
> inclusion criteria.
>
>
> Unlike a coding task, maintaining a root store is an ongoing
> commitment. It is not something that you can do once and forget.
>

I didn't comment on the difficulty of the policy.  I am aware of the
incredible detail that goes into such policies.  But the policy has always
remained outside the protocol specification, so I don't see why it is
relevant.

For most uses, the OS already takes care of this for you, so there is no
work to be done at all.  Just use the OS certificate store and you're fine.

Mike





>
>
>
> On Tue, Jul 17, 2012 at 11:51 PM, Mike Belshe <mike@belshe.com> wrote:
> >
> >
> > On Tue, Jul 17, 2012 at 8:32 PM, Phillip Hallam-Baker <hallam@gmail.com>
> > wrote:
> >>
> >> Umm pretty much every Web Server has SSL support, the issue is that
> >> only about 2% of deployments turn it on. Or is the idea that we are
> >> going to mandate turning it on? If so, who is going to define the
> >> trust criteria for accepting certs?
> >
> >
> > Browsers already have well documented policies for this.  Major OSes also
> > have their own policies (MacOS, Windows).
> >
> >>
> >>
> >> I am a big supporter of TLS. I just don't see anything good coming
> >> from a mandate that is superfluous.
> >>
> >> As an example, we have had a mandate in PKIX to check CRLs and/or OCSP
> >> for over a decade and to reject a certificate if the client cannot
> >> perform validation. Most browsers try to check but accept the
> >> certificate if there is no response to the OCSP request. So virtually
> >> every deployed browser has been out of compliance with a fundamental
> >> PKIX control for over a decade despite repeated attempts by the CAs to
> >> persuade the providers to change this.
> >>
> >> I can't see how DANE is going to solve anything either since DANE
> >> poses an even more disruptive hard-fail criteria.
> >>
> >> I don't want to tie an application layer protocol version to a
> >> transport layer protocol version or vice versa. If you tie HTTP 2.0 to
> >> TLS 1.2 then you are going to have to revise HTTP when you revise TLS.
> >
> >
> > This is not true.  HTTP did not change when we went from earlier
> versions of
> > TLS to the current versions.  Browsers do support older versions of TLS,
> > usually for older servers that haven't upgraded.  Even SSL3 - shudder.
> >
> >>
> >>
> >>
> >> I don't see any value in a Canute/sea act here.
> >>
> >>
> >> What would be valuable is to have a suite of standards for a specific
> >> application that could be identified as a set. Something like 'best
> >> practices for Web server hosting, IPv6 +HTTP 2.0 + TLS 1.2 with
> >> AES+SHA2 + DNSSEC'. It would also be nice to see a similar draft for
> >> best practices for email clients and servers, and yes, support for
> >> STARTTLS would be high on my list of requirements. A draft like that
> >> would be very useful as a contract term for outsourcing Web hosting or
> >> mail service.
> >>
> >> But that is a totally different prospect to trying to tie HTTP to a
> >> particular security solution.
> >>
> >>
> >> Implementing TLS in a product is far from trivial. Getting the code is
> >> easy, selecting trust anchors is not. Is the specification going to
> >> mandate a particular choice of trust anchor? that is not going to
> >> happen. Nor is defining a minimum Certification Policy or locking the
> >> whole HTTP trust infrastructure to the ICANN PKI root by trying to
> >> mandate DNSSEC and DANE as well as TLS.
> >>
> >> TLS requires a PKI to work and every PKI comes with a set of policy
> >> and legal questions that have to be understood if the scheme is going
> >> to provide any security.
> >
> >
> > Users expect privacy and security.  We've all seen the legislation around
> > the globe for stronger security and privacy options.  SSL won't fix
> > everything, I know, but it is a solid step, and its the responsible step
> for
> > the protocol.  I don't understand how we can argue that HTTP/2.0 could
> be a
> > protocol for the next 20 years if it is sniffable over the wire.
> >
> > Go talk to non-techie users about whether HTTP is secure.  They assume it
> > is.  Ask them if they would prefer a secure protocol or an insecure one.
> > Ask them if they think protocols should be eavesdroppable so that other
> > people in the cafe can see what they're doing, steal their passwords, and
> > more?  I have yet to find any of these users that want this flimsy level
> of
> > security.
> >
> > So- the problem we're solving here is to make users safer and raise the
> bar
> > on web security globally.
> >
> > Mike
> >
> >
> >>
> >>
> >>
> >> On Tue, Jul 17, 2012 at 10:30 PM, Mike Belshe <mike@belshe.com> wrote:
> >> > Mandatory SSL is +1 and very forward thinking.
> >> >
> >> > On Tue, Jul 17, 2012 at 6:22 PM, Phillip Hallam-Baker <
> hallam@gmail.com>
> >> > wrote:
> >> >>
> >> >> -1
> >> >>
> >> >> I don't want to have a mandatory requirement unless it is going to
> >> >> change behavior.
> >> >
> >> >
> >> > I don't think we can change behavior with protocols.  All we can do is
> >> > offer
> >> > new features.  If the features are compelling, people will upgrade.
>  If
> >> > the
> >> > features are not compelling, they won't.
> >> >
> >> > People used to tell me SPDY would never get people to "upgrade".  Even
> >> > after
> >> > touching a half a billion users, people still tell me that.  I think
> the
> >> > evidence of adoption speaks for itself.
> >> >
> >> >>
> >> >>
> >> >> We already have ubiquitous deployment of TLS in browsers. The code is
> >> >> freely available, everyone knows the benefit.
> >> >>
> >> >> The only HTTP servers or clients I am aware of that don't have TLS
> >> >> support are either toolsets that the provider expects to be used with
> >> >> OpenSSL or the like and embedded systems.
> >> >
> >> >
> >> > I'll ask the google crawler guys to weigh in on this.  They have
> pretty
> >> > good
> >> > stats.  I believe your assertion is provably false.
> >> >
> >> >>
> >> >>
> >> >> Incidentally, suport for IPSEC is mandatory in IPv6 but that does not
> >> >> seem to do any good either. It just means that IPv6 is harder to
> >> >> deploy as implementations are required to support a security layer
> >> >> almost nobody uses as TLS has proved better.
> >> >>
> >> >>
> >> >> Making TLS a mandatory requirement seems like a feelgood approach to
> >> >> security to me. Instead of doing something useful, we pass a
> >> >> resolution telling people to do what they plan to do anyway.
> >> >
> >> >
> >> > You imply there is something else that would be useful - what would it
> >> > be?
> >> > (don't feel obliged to answer :-)
> >> >
> >> > To me mandating security is a great first step.  Nobody should think
> >> > this
> >> > 'fixes' security. But if we believe the net ever needs to be secure,
> we
> >> > need
> >> > to start taking steps toward that.
> >> >
> >> > Mandating SSL is a simple step we can take which solves most of the
> >> > eavesdropping problem right now.  But more importantly, it poises us
> to
> >> > address the next set of security issues, including CA/verification
> >> > problems,
> >> > distribution of video over ssl, handshake latency, etc.  Until we
> start
> >> > trying to be secure, of course we'll never be secure.
> >> >
> >> > Mike
> >> >
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Jul 17, 2012 at 8:51 PM, Paul Hoffman <
> paul.hoffman@gmail.com>
> >> >> wrote:
> >> >> > +1 to what seems to be a lot of developers: make TLS mandatory.
> >> >> >
> >> >> >>  so, even when used in an internal application protocol, it's
> going
> >> >> >> to
> >> >> >>  be end to end
> >> >> >>  encrypted to make it super hard to debug?
> >> >> >
> >> >> > In an internal application protocol, why would it be "super hard to
> >> >> > debug"? The client can do an HTTP dump before TLS, the server can
> do
> >> >> > an HTTP dump after TLS; either of the sides could debug the TLS.
> >> >> >
> >> >> >>  http is about more than users using
> >> >> >>  web browsers.
> >> >> >
> >> >> > Completely true, and not relevant. Insecure HTTP for non-browser
> >> >> > applications still has the same bad properties, no?
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Website: http://hallambaker.com/
> >> >>
> >> >
> >>
> >>
> >>
> >> --
> >> Website: http://hallambaker.com/
> >
> >
>
>
>
> --
> Website: http://hallambaker.com/
>