[TLS] Fwd: Cached Info

Sean Turner <turners@ieca.com> Tue, 08 March 2016 01:21 UTC

Return-Path: <turners@ieca.com>
X-Original-To: tls@ietfc.amsl.com
Delivered-To: tls@ietfc.amsl.com
Received: from localhost (localhost []) by ietfc.amsl.com (Postfix) with ESMTP id B1C4A1CD735 for <tls@ietfc.amsl.com>; Mon, 7 Mar 2016 17:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfc.amsl.com []) (amavisd-new, port 10024) with ESMTP id L9PvAFDUvXHL for <tls@ietfc.amsl.com>; Mon, 7 Mar 2016 17:21:14 -0800 (PST)
Received: from gateway36.websitewelcome.com (gateway36.websitewelcome.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 3C7231CD729 for <tls@ietf.org>; Mon, 7 Mar 2016 17:21:14 -0800 (PST)
Received: from cm2.websitewelcome.com (cm2.websitewelcome.com []) by gateway36.websitewelcome.com (Postfix) with ESMTP id 4168AFEEFC2F2 for <tls@ietf.org>; Mon, 7 Mar 2016 19:20:05 -0600 (CST)
Received: from gator3286.hostgator.com ([]) by cm2.websitewelcome.com with id TDL31s0155Qt53201DL4Q6; Mon, 07 Mar 2016 19:20:05 -0600
Received: from ([]:50380 helo=[]) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <turners@ieca.com>) id 1ad6Jd-000KFX-Us for tls@ietf.org; Mon, 07 Mar 2016 19:20:02 -0600
From: Sean Turner <turners@ieca.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C5E6AA90-9E9F-40CC-A129-966779840EB9"
Date: Tue, 8 Mar 2016 10:19:59 +0900
References: <F403D8E5-98C1-4CE6-A0B3-A44C2749FBC1@gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <01B45068-A591-4F31-9993-CEF6A538F3CB@ieca.com>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Exim-ID: 1ad6Jd-000KFX-Us
X-Source-Sender: ([]) []:50380
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 2
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/qBJf-aozr4eKIFcOXVDh85TcZZY>
Subject: [TLS] Fwd: Cached Info
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 08 Mar 2016 01:21:15 -0000


The cached-info draft got all the way to the IESG and then we receive a couple of comments that require we bring the draft back to the WG to discuss.


> Begin forwarded message:
> From: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
> Subject: Re: Cached Info
> Date: February 23, 2016 at 12:34:31 GMT+9
> To: Sean Turner <TurnerS@ieca.com>om>, Eric Rescorla <ekr@rtfm.com>om>, Martin Thomson <martin.thomson@gmail.com>om>, "Stephen ie>" <stephen.farrell@cs.tcd.ie>
> Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>
> Some corrections:
> Dear All,
> I took a quick look at cached-info at Ekr’ prodding, who was worried about key synchronization-style attacks (Ekr’s original email is a the bottom of this email.)
> My conclusion is that the use of a 4-byte hash is unnecessarily fragile.
> The attacks are not super-serious, but the following scenario looks bad.
> Maybe I got something wrong about the spec, so do tell me if I did.
> Suppose that the client uses client certificates (or channelID/token binding) to login to all websites.
> The client’s authentication credential is bound to the current handshake transcript.
> If the transcript does not contain the server certificate, then a malicious server may be able
> to forward a credential sent by the client to the malicious server to a different server.
> This kind of credential forwarding attack enables certain kinds of impersonation (see Triple Handshake)
> In Cached-Info, the transcript includes a 32-bit hash of the certificate and some signature or RSA encryption that uses the certificate signing/encryption key.
> To mount the attack described above, the attacker would first need to find a certificate that collides with the honest server certificate hash.
> You can imagine the attacker generating 2^32 self-signed certificates until the collision is found, this is not hard.
> Next, the attacker still has to match the parts of the transcript that use the server’s public key (if any).
> The client could maybe choose the public key to match that of the server, or carefully choose the RSA signing key to create a signature value that matches that of the real server etc.
> There may be other attacks where the attacker uses a static ECDH ciphersuite, and so does not need to sign anything.
> So now, the honest client C connects to malicious server M that has a self-signed cert (for M).
> C accepts the cert (for M) and agrees to use certificate/token-bound authentication at M.
> M can then forward the credential and signature to S, which will accept it.
> M would not control the keys between M and S (since it used S’s public key.)
> But if C is using a browser, then C’s window is at M’s origin, so M can inject 
> data into the connection which will then be forwarded to S, as if the authenticated user C intended to send it to M.
> Perhaps the above attack is not very worrisome to some people, but the silly
> bit is that accepting this risk is completely unnecessary. The client and 
> server could simply use the full SHA-256 hash for the certificate and the
> client would have a hard time creating a colliding certificate.
> Best,
> Karthik

> —————
> Ekr’s original email
> ————————
> Folks,
> I've been thinking over the cached-info draft, and I'm not convinced
> that the security analysis is right.
> In the current design, the client sends a truncated 32-bit hash
> of what it believes the server's certificate is. If that matches
> the server's certificate, then the server echoes that truncated
> hash (if I'm reading it correctly).
> The security considerations section claims:
>    The use of the cached info extension allows the server to send
>    significantly smaller TLS messages.  Consequently, these omitted
>    parts of the messages are not included in the transcript of the
>    handshake in the TLS Finish message.  However, since the client and
>    the server communicate the hash values of the cached data in the
>    initial handshake messages the fingerprints are included in the TLS
>    Finish message.
> But this isn't correct with a short hash, since you're not strongly
> binding the hash into the handshake. And elsewhere the text claims
> that the hash isn't relevant:
>    If an attacker
>    injects an incorrect fingerprint then two outcomes are possible: (1)
>    The fingerprint does not relate to any cached state and the server
>    has to fall back to a full exchange. (2) If the attacker manages to
>    inject a fingerprint that refers to data the client has not cached
>    then the exchange will fail later when the client continues with the
>    handshake and aims to verify the digital signature.  The signature
>    verification will fail since the public key cached by the client will
>    not correspond to the private key that was used by server to sign the
>    message.
> I think this is closer to the truth. But consider the case where
> an attacker convinces the client to accept a certificate for
> attacker.com <http://attacker.com/> but with victim.com <http://victim.com/>'s public key that *also*
> hash the same fingerprint as victim.com <http://victim.com/>'s certificate. In that case,
> you could end up with a UKS between the client and victim.com <http://victim.com/>
> (where the client thinks he's talking to attacker.com <http://attacker.com/>). What prevents
> this (I believe) is the text in Security Considerations:
>    Clients MUST ensure that they only cache information from legitimate
>    sources.  For example, when the client populates the cache from a TLS
>    exchange then it must only cache information after the successful
>    completion of a TLS exchange to ensure that an attacker does not
>    inject incorrect information into the cache.  Failure to do so allows
>    for man-in-the-middle attacks.
> If followed, this will stop the client from accepting attacker.com <http://attacker.com/>'s
> bogus cert (because he doesn't have the private key). Note, however, that
> you have to follow it strictly. For instance, if you cache after
> False Start, then you are vulnerable to this attack. Also, these
> instructions seem really counterintuitive, because naively you
> would expect to just be able to validate the server's cert and
> store the hash once it had been validated. I also note that this
> advice was in the draft in -19 when the full hash was used.
> To be honest, I'm not entirely convinced that this advice is sufficient,
> but I don't have a complete analysis either way. However, I do think it's
> clear that the text in the draft is confusing.
> Thoughts?
> -Ekr