[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
- [TLS] security considerations for draft-rescorla-… Brian Sniffen
- Re: [TLS] security considerations for draft-resco… Subodh Iyengar
- Re: [TLS] security considerations for draft-resco… Benjamin Kaduk
- Re: [TLS] security considerations for draft-resco… Simon Friedberger
- Re: [TLS] security considerations for draft-resco… Salz, Rich
- Re: [TLS] security considerations for draft-resco… Simon Friedberger
- Re: [TLS] security considerations for draft-resco… Subodh Iyengar
- Re: [TLS] security considerations for draft-resco… Benjamin Kaduk
- Re: [TLS] security considerations for draft-resco… Stephen Farrell
- Re: [TLS] security considerations for draft-resco… Subodh Iyengar
- Re: [TLS] security considerations for draft-resco… Simon Friedberger
- Re: [TLS] security considerations for draft-resco… Stephen Farrell
- Re: [TLS] security considerations for draft-resco… Watson Ladd