Re: Require security review before FPWD

On 11/2/2014 11:47 AM, Anne van Kesteren wrote:
>> >Perhaps you argue, however, that for security (more than other areas) if we
>> >don't start with security retrofitting later is harder.
> It is hard to require TLS for a feature later if you already allow it
> to be used without TLS. This kind of baseline requirement is not
> really in play for other aspects as much I think.

 From a pure technical specifications pov, if a WG decides that it wants 
to mandate TLS, I don't understand why it makes a difference whether it 
does it at FPWD or at CR.  In either case, TLS is mandated.

But I assume you are not talking about pure technical specifications.  
You are talking about when implementers are implementing products 
without TLS.  If the existing product implementations are a boat anchor 
which convinces a WG not to mandate TLS, there could be a problem.


>
>
>> >This is certainly a plausible argument - but it still leaves open the
>> >question as to what is the best solution.  Oftentimes an FPWD is very
>> >minimal in completeness.  Fundamental changes in design; changes in author;
>> >new security exposures can easily creep in during the path from FPWD to REC.
>> >So a review before FPWD is not a panacea.
>> >
>> >Who is best to judge when is the best time for the security review? The
>> >current philosophy is to require that a set of things get done before CR -
>> >and leave it to the WG to determine the best timing. That is why I suggested
>> >requiring to do before CR and suggesting to do it early (and I might add
>> >early and often).
> Well, we have WebRTC and EME as examples where deployed non-TLS
> content seems to have considerable weight, more so than the security
> and privacy concerns of end users. The question is whether we want
> this to continue or make sure it cannot happen again.

Surely we want the right architecture.  So if the WG wants to mandate 
TLS, they should.  The only question is what is the best time to look at 
that.

Mandating a security review at FPWD might help.  But it is not a 
panacea.  After all, there could be implementation baggage before even 
reaching FPWD, for example if the spec work started in a CG or in 
another organization.  On the other hand, reviewers will not necessarily 
determine that TLS is needed.  I'm actually doubtful that if there were 
a security review at FPWD for either EME or WebRTC whether a TLS mandate 
would have emerged at the time.

Mind you, I have no strong objection to the proposal; just discussing 
whether it is most effective. More effective would be to raise the level 
of understanding and training among spec writers to be constantly 
security aware.

Received on Monday, 3 November 2014 03:41:36 UTC