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

"Dan Harkins" <> Tue, 19 November 2013 15:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DBED21AE023 for <>; Tue, 19 Nov 2013 07:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.867
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hAHoceIEGRVZ for <>; Tue, 19 Nov 2013 07:33:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3E75E1AE010 for <>; Tue, 19 Nov 2013 07:33:41 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 4092210224008; Tue, 19 Nov 2013 07:33:35 -0800 (PST)
Received: from (SquirrelMail authenticated user by with HTTP; Tue, 19 Nov 2013 07:33:35 -0800 (PST)
Message-ID: <>
In-Reply-To: <D4318E7AF8480146A18F382CB1E64DBD15A20C0009@W2053.kpnnl.local>
References: <> <> <> <> <D4318E7AF8480146A18F382CB1E64DBD15A20C0009@W2053.kpnnl.local>
Date: Tue, 19 Nov 2013 07:33:35 -0800 (PST)
From: "Dan Harkins" <>
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
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Nov 2013 15:33:43 -0000

  Hi Oscar,

On Tue, November 19, 2013 3:15 am, 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.



> Oscar Koeroo
> Red Team / Ethical Hacker
> Chief Information Security Office
> Tel: +31 6 1217 5278
> Fingerprint: 3D5F 5BA5 AF84 BBE1 3D60 8621 0DCD 74C3 A211 B654
> Van: TLS [] Namens Ralf Skyper Kaiser
> Verzonden: dinsdag 19 november 2013 11:16
> Aan: Dan Harkins
> CC:
> 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 <> 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
>> 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.