Subject: Re: [http-auth] Evaluation Criteria for the experimental drafts

From: Douglas Stebila <[email-masked]>
Date: Wed, 18 Sep 2013 10:51:25 +1000

On 2013/08/28, at 09:05, Yoav Nir <[email-masked]> wrote:

> As we talked in Berlin, the following is not a checklist. It is meant only as guidance. Comments that are not covered by these guidelines are very welcome. 
> 
> Security:
>   - No vulnerabilities that we should find
>   - Assumptions, limitations should be stated up front, not left to security considerations
>     For example, a method that requires secure storage of password equivalents should state this up front.

I would encourage that proposals employing cryptographic subprotocols should have formal security analyses, using either provable security or formal methods.  Although such analyses do not imply complete security, they at least rule out certain classes of attacks, which is better than a solely heuristic argument, which is how I interpret "no vulnerabilities that we should find".

For example, some of the proposals I've seen on the mailing list employ password-authenticated key exchange (PAKE).  There are many, many provably secure password-authenticated key exchange protocols in the academic literature, and to my mind there is no reason why a proposal should not use a provably secure one if it can.  

Some colleagues and I have a current paper (http://www.douglas.stebila.ca/research/papers/msd13) which aims to formally define and prove the security of combined TLS / http-auth protocols such as the one proposed by Oiwa et al.  Our approach extends recent work on modelling the provably security of TLS as an "authenticated and confidential channel establishment" (ACCE) protocol to the password-based setting, and shows that it's safe to bind TLS and an HTTP-level PAKE together using either the TLS server certificate or TLS Finished message.
	
We haven't written an Internet-Draft based on our paper since the basic structure is similar to the Internet-Draft of Oiwa et al, but with a different PAKE used for the cryptographic protocol; if there is desire for an alternative, we could write such a draft.

Douglas