Subject: [websec] Fwd: [TLS] Working Group Last Call for draft-ietf-tls-pwd

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 19 Nov 2013 16:06:58 +0000

Moving discussion from TLS-WG to WEBSEC-WG. See below.

---------- Forwarded message ----------
From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, Nov 19, 2013 at 10:15 AM
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
To: Dan Harkins <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

Hi Dan,

The security risk lies within the implementation.

The capable client will always offer TLS-PWD.

Simplified, this is how pinning will be implemented: The client receives
the server's certificate. The client checks if the server's certificate (or
better the SPKI) is already known to the client (e.g. pinned) and if the
server's certificate is different to the pinned certificate then the
connection fails.

The draft assumes that certificate based server authentication is the only
authentication that exists.

The draft does not discuss the scenario where TLS-PWD is used.

In such a case I'm concerned that the part of the client source code that
checks for pinning is not triggered and by-passed. The client goes into the
TLS-PWD mode.

Instead what should be pinned is the SPKI _and_ that certificate based
server-authentication must be used. E.g. once a client has pinned a
certificate for a host it should not allow TLS-PWD.

This is obvious to us but not obvious to the developer and should be
explicitly mentioned.

(It could be mentioned in websec-rfc as you say but that's beyond draft
status and additions are no longer practical). Mentioning it in the TLS-PWD
draft will hopefully prevent an insecure implementation.

regards,

Ralf

On Mon, Nov 18, 2013 at 9:51 PM, Dan Harkins <[email-masked]> wrote:

>
>   Hi Ralf,
>
> On Tue, November 12, 2013 2:28 am, Ralf Skyper Kaiser wrote:
> > Hi,
> >
> > could not find it in the draft:
> >
> > the interoperability with draft-ietf-websec-key-pinning-08 should be
> > mentioned explicitly to prevent
> > an attack scenario. (e.g. user has pinned certificate for google.com.
> > Attacker MITM forces
> > client to do tls-pwd. Client should not allow this). E.g. once a host is
> > pinned no other server-side
> > auth mechanism should be allowed.
>
>   If the client doesn't want to do TLS-pwd then it won't include the
> mandatory extension in its client hello and it won't include any TLS-pwd
> ciphersuites. I don't see how this attack happens.
>
>   Perhaps the necessary requirements to deal with pinning certificates
> for websec should be dealt with in the draft you mention.
>
>   regards,
>
>   Dan.
>
>
>
>