[TLS] security considerations for draft-rescorla-tls-subcerts

Brian Sniffen <bsniffen@akamai.com> Thu, 30 March 2017 21:54 UTC

Return-Path: <bsniffen@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB7A12940E for <tls@ietfa.amsl.com>; Thu, 30 Mar 2017 14:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 K59UahUvQtkf for <tls@ietfa.amsl.com>; Thu, 30 Mar 2017 14:54:35 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 84DD31295E7 for <tls@ietf.org>; Thu, 30 Mar 2017 14:54:32 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2909E16CBA4 for <tls@ietf.org>; Thu, 30 Mar 2017 21:54:32 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 13AD716CB3B for <tls@ietf.org>; Thu, 30 Mar 2017 21:54:32 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1490910872; bh=4FCiNqnFyJn0O5b4PLWU7Yx8lyUgXTJZQSkdR5uEHWA=; l=1239; h=From:To:Date:From; b=I6YiQ2O0aPJ6mlOhnCcwi7X7XIyNq9qygtXyeclSIwPcbdVKlnuNdT+V0sfumsd7A rPRuw27FaN46LbuGiV7VBdZU7h1oxbMxoI413ozSHsXieFdGU2esJff6m0BsgtuX2G 5MkuOdSUk4ZlSndpD/Uu6zmpie1oxgh31PGjQ2H8=
Received: from dhcp-89ad.meeting.ietf.org (unknown [172.19.41.73]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 9DB6698082 for <tls@ietf.org>; Thu, 30 Mar 2017 21:54:31 +0000 (GMT)
From: Brian Sniffen <bsniffen@akamai.com>
To: tls@ietf.org
Date: Thu, 30 Mar 2017 16:54:29 -0500
Message-ID: <m27f362zxm.fsf@dhcp-89ad.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MbObam5qEUtczi1N4ydMNmPoIoQ>
Subject: [TLS] security considerations for draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 30 Mar 2017 21:54:37 -0000

I'm trying to understand the adversary model in which Delegated
Credentials are helpful.  It seems like if you weren't going to sign off
on a cloud service provider getting a certificate before, you *probably*
shouldn't let them have a delegated credential now---but if you were
going to do so, *and* you don't believe revocation works (wise!), now
you can offer a delegated credential and be safer?

That corresponds to an adversary who can compromise a cloud service and
learn the customers' private keys---but can only do so rarely.  Now
instead of having ~ 1 year of use of your certificate, that adversary
has a few days of use of your credential.  But if the cloud service
is regularly breached, you're as bad off as before (but no worse?)

It sounds like the first years of delegated credentials will see them
used in tandem with split systems (Lurk, Akamai and Cloudflare's various patented
approaches)---then the primary benefit of delegated credentials is lower
latency for session establishment.

But maybe the idea is to avoid the first circumstance and emphasize that
these are for the second case.  Authors, can you describe what you have
in mind?

Thanks,
Brian

-- 
Brian Sniffen
Akamai Technologies