Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

["Dan Harkins" <[e-mail]>]

  Hi Ralf,

On Tue, November 19, 2013 2:15 am, Ralf Skyper Kaiser wrote:
> Hi Dan,
>
> The security risk lies within the implementation.
>
> The capable client will always offer TLS-PWD.

  Unless it is expressly told not to because of some external event,
like pinning of a certificate for websec.

> 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.

  It's a draft. The tracker does not indicate that it has passed IETF LC.
Make the comment. It's the right place to do so. If you want this
event to take precedence then expressly say so in the document
that defines the event.

  regards,

  Dan.

> regards,
>
> Ralf
>
>
>
>
> On Mon, Nov 18, 2013 at 9:51 PM, Dan Harkins <[e-mail]> 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.
>>
>>
>>
>>
>