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

Ralf Skyper Kaiser <skyper@thc.org> Tue, 19 November 2013 10:15 UTC

Return-Path: <skyper@thc.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 381A01ADBD0 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 02:15:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 HiNQTuXDaKe9 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 02:15:40 -0800 (PST)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3C96D1ADBCE for <tls@ietf.org>; Tue, 19 Nov 2013 02:15:40 -0800 (PST)
Received: by mail-ie0-f171.google.com with SMTP id ar20so4343795iec.2 for <tls@ietf.org>; Tue, 19 Nov 2013 02:15:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z63hDuZOe8J4w7H5GzF7Ii5QX3ikaDC3inspbj05jrs=; b=Wc4Q46s0DS/Uh8MgiAiM1gVF3sPFvls/n9DqnCLJfTI0ua9BBUpQK3XkoFcEatGz3W kao6/XchRPbsAG6Je32xw3VBDLpb7Z//dus0sQw+ooI4/eZ2NoMQG4HINs6bOA4+ZcJJ iPJI3A33CnjACyl4zc2tMI6LybbSrUOlI+h1Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=z63hDuZOe8J4w7H5GzF7Ii5QX3ikaDC3inspbj05jrs=; b=mYcurrnGGve9EPxtbv9m/qb4wOY0GKUbEru1oGNnUz0b2uohpEi5Q6BBTiu2b1dxaF CxV75YOUyvkHTWOSq7NFp/2buWyYbsoXNR+dyA5TwzJx9B1vjDqPDV0l9mYvvePX67Hm o7Nlgx+qoFi4uz2KCRk0M5glnpdPStqLWn0EMf3Halhl/DxNDgGUuoJnPLh4VIyWvvOS T0eYnqnw5/mfwxQICWJNP8GJLMG69UJmJPS57LNOAe/yVcm86Y/UmhKUesmyzdDovUBm Cm+8XJIb0OLNrAQ0NUl4eg9560N0PyAKZkLsNYnBqX3mL603xDirtf1qZbBUrR3uQ7YB tWpw==
X-Gm-Message-State: ALoCoQl3a8XI5N2DEO1wG/PbvSja3u253OLA6Yx55uKgLauL2KnfXGIOjE6yebsNavKvs+woDi84
MIME-Version: 1.0
X-Received: by 10.50.131.163 with SMTP id on3mr18182522igb.46.1384856134151; Tue, 19 Nov 2013 02:15:34 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Tue, 19 Nov 2013 02:15:34 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <cd311295df981e28835cfc44ab95bb3a.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <CA+BZK2rQ9-3XYB0sUJA-iWHBEfQrnkeo6q+VMt2jcV16ryupnQ@mail.gmail.com> <cd311295df981e28835cfc44ab95bb3a.squirrel@www.trepanning.net>
Date: Tue, 19 Nov 2013 10:15:34 +0000
Message-ID: <CA+BZK2qPEXXK6zGHU3MJ4Z64sQkPLPQp1T6i6AT2k-Odjb8tuQ@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary="047d7b2e0d1ff10fb104eb84f1ec"
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 10:15:42 -0000

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