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

"Dan Harkins" <dharkins@lounge.org> Tue, 19 November 2013 15:33 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 DBED21AE023 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 07:33:42 -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 hAHoceIEGRVZ for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 07:33:41 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3E75E1AE010 for <tls@ietf.org>; Tue, 19 Nov 2013 07:33:41 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4092210224008; Tue, 19 Nov 2013 07:33:35 -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:33:35 -0800 (PST)
Message-ID: <de18fa62ba0d8da0b1f618fafe696b30.squirrel@www.trepanning.net>
In-Reply-To: <D4318E7AF8480146A18F382CB1E64DBD15A20C0009@W2053.kpnnl.local>
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> <D4318E7AF8480146A18F382CB1E64DBD15A20C0009@W2053.kpnnl.local>
Date: Tue, 19 Nov 2013 07:33:35 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: oscar.koeroo@kpn.com
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
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:33:43 -0000

  Hi Oscar,

On Tue, November 19, 2013 3:15 am, oscar.koeroo@kpn.com wrote:
> May I add that it's not clear which elements are to be presented to the
> user for visual (or automated) inspection and in which form. I can handle
> long random string for visual inspection, but I wonder if this is to be
> expected from all users. If I've understood the spec correctly the
> fingerprint of the public key and the domain names, i.e. the subject alt
> names, are to be presented to the user. This could turn out to be quite a
> bit of data per certificate.
>
> Also, if the fingerprint is tied to public key exclusively I wonder what
> the UAs are expected to do when subject alt names have changed in the
> certificates when the public key is preserved.

  Very interesting questions... for the web sec WG; this is TLS. And this
is a thread dealing with a draft that does certificate-less authentication.

  regards,

  Dan.

> Oscar Koeroo
> Red Team / Ethical Hacker
> Chief Information Security Office
> KPN
> Tel: +31 6 1217 5278
> Fingerprint: 3D5F 5BA5 AF84 BBE1 3D60 8621 0DCD 74C3 A211 B654
>
>
> Van: TLS [mailto:tls-bounces@ietf.org] Namens Ralf Skyper Kaiser
> Verzonden: dinsdag 19 november 2013 11:16
> Aan: Dan Harkins
> CC: tls@ietf.org
> Onderwerp: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
>
> 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 <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.
>
>
>
>