Re: [TLS] I-D Action: draft-ietf-tls-pwd-04.txt

[Nico Williams <[e-mail]>]

On Fri, Mar 28, 2014 at 7:07 PM, Dan Harkins <[e-mail]> wrote:
>> Why is a multi-party computation ala Socialist Millionaire's protocol
>> in OTR not feasible? That establishes a secure channel based on a
>> password shared on both ends in a way that is provably secure.
>> Aug-PAKE can easily be made to work symmetrically: why can't you use
>> that?
>
>   There is no draft specifying a multi-party computation ala the
> Socialist Millionaire's protocol in TLS, much less one that is as
> mature as TLS-pwd. Aug-PAKE doesn't work in TLS, as shown
> by draft-shin-tls-augpake-- what's conveyed in the ClientKeyExchange
> structure since the client's contribution has been overloaded into
> the ClientHello? Basically, the client must initiate in Aug-PAKE and
> that forces a square peg into a round hole, or introduces extra
> rounds.

IMO:

 - user authentication generally belongs at the app layer, with
channel binding to TLS,

however

 - since there are applications where having userauth in lower layers
is convenient, it's OK to have this option in TLS,

but

 - we should use an augmented ZKPP for this.  If that means extra
round-trips or starting sooner (in the client's first message), so be
it.  We shouldn't be so constrained by the "TLS state machine" that we
make no real progress.

Finally:

 - we should use well-understood, well-aged, believed-secure
protocols.  We are constrained here by IPR, but there are protocols
which can reasonably cut through IPR FUD (e.g., J-PAKE).

Nico
--