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

"Dan Harkins" <dharkins@lounge.org> Tue, 19 November 2013 15:31 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D820C1AE060 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 07:31:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9virBGm3vzw for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 07:31:16 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5B99C1AE056 for <tls@ietf.org>; Tue, 19 Nov 2013 07:31:16 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0D3281022400A; Tue, 19 Nov 2013 07:31:10 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 19 Nov 2013 07:31:10 -0800 (PST)
Message-ID: <ab46858e8823b4b08aea11ae1b8b268e.squirrel@www.trepanning.net>
In-Reply-To: <CA+BZK2qPEXXK6zGHU3MJ4Z64sQkPLPQp1T6i6AT2k-Odjb8tuQ@mail.gmail.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <CA+BZK2rQ9-3XYB0sUJA-iWHBEfQrnkeo6q+VMt2jcV16ryupnQ@mail.gmail.com> <cd311295df981e28835cfc44ab95bb3a.squirrel@www.trepanning.net> <CA+BZK2qPEXXK6zGHU3MJ4Z64sQkPLPQp1T6i6AT2k-Odjb8tuQ@mail.gmail.com>
Date: Tue, 19 Nov 2013 07:31:10 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Ralf Skyper Kaiser" <skyper@thc.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Nov 2013 15:31:18 -0000

  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 <dharkins@lounge.org> 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.
>>
>>
>>
>>
>