[TLS] draft-rescorla-tls-subcerts

Eric Rescorla <ekr@rtfm.com> Thu, 07 July 2016 19:29 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7568412D1DD for <tls@ietfa.amsl.com>; Thu, 7 Jul 2016 12:29:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UvqnsTG9m8uO for <tls@ietfa.amsl.com>; Thu, 7 Jul 2016 12:29:14 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5804B12D17A for <tls@ietf.org>; Thu, 7 Jul 2016 12:29:14 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id b72so22958310ywa.3 for <tls@ietf.org>; Thu, 07 Jul 2016 12:29:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=iC05CogrxNasYOCxHgYf/EoAWvxQBu98/0+rrPDct/U=; b=NNWFrgZh7geEjXrFPE8X0f+nE6lxpsi7ACI2wnyouScVENvfc7LPUWiy5+/3/TB3R9 ponohElbrmtkXUndY9xF2HIUil2jKzttqYpYehhEgCjX7x79v+px1h5yUKWoqGDKw3v2 MKiP8poLBkE/iuV4ryL3WvnYZkeVNIQW/Sz8Hs7p+qvI0+/bR+6SCRFgKok1T+sAEgCg QXLzwCQR6GTk3D8lqbraQph3qRtS4AHauS4UiDMW6jvXFhuZdl4m2ahj0fpYkzsbQdMk Uedq9WeyZtu5xtS46ExLOqC5HtW44RfgrhgEL09j8JkdqIBsVSSqmoLQNSeAkAPJGa5e uORg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=iC05CogrxNasYOCxHgYf/EoAWvxQBu98/0+rrPDct/U=; b=CZNB5Fa8Q7neT98fsQJqiFPUTloBZ8wlm7aaOmGPC9Qidm2mqSZaWlGgHcaxUqXF4/ D7fVDt2PT/9pTuPph8q0BoEfOwWv2ayVmieafhGyR+wLSCd/db8M9rZPGXRqJJVvjHtz zRDP4/099dfRw7/0rFVfSdFPR2fc9qEAaXHJ5SQizN67STMOwzX09yDophJLAPXImlP1 PLZtCCQdRX9zlAfVAZSSAUrfgV2ZWni0jd/KPKi2lJ01QmTX58ZCwDqytIY9ZgpoS/pR Mo9S7LyD7BIRpvWXLdfkwM8eM9QyktUWEj7E58Et7c9VJNt9I0E7GTfvGisOLBXJOgH6 /C3w==
X-Gm-Message-State: ALyK8tL+fmD2xHr9hCkYULrZOCJdS/Dgf7x3C4TqWrz3/cz1Y/oSEv+fncw8kbt5UvsMyRDd+KfEbFTYsPD7XQ==
X-Received: by with SMTP id u84mr1869155ywu.214.1467919753382; Thu, 07 Jul 2016 12:29:13 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 7 Jul 2016 12:28:33 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 07 Jul 2016 12:28:33 -0700
Message-ID: <CABcZeBP+6AP50L06knsnOmyMqbv3fFw6TrcSrqs0x9FgoxyKcw@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114140ba75be55053710b30c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/szrFjD4mpgSIayQm2MGpF8ZblaY>
Subject: [TLS] draft-rescorla-tls-subcerts
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: Thu, 07 Jul 2016 19:29:16 -0000

We've talked several times about designing some sort of TLS delegation
mechanism. A few of us got together and put together some initial thoughts
about the options at:

The general idea here is to have some mechanism for allowing what
are effectively end-entities to issue short-lived credentials that allow
entities to act on their behalf (e.g., for CDN use cases).
Comments welcome.

In terms of the security analysis, it's obviously very important that this
not present a risk to existing TLS servers. The mechanism designed here is
intended to be future safe in that sense, though perhaps we've missed

I also wanted to clarify a couple points about attacks where the
certificate that signs the delegated credential is also used for ordinary
TLS operation (which generally is a practice that's pretty scary). As noted
above it's important that existing certs not be usable this way, but maybe
future certs would be.

1. It's important to construct the delegated credential in such a way that
you can't use a TLS server as a signing oracle. If you choose "option 2"
where you define a new structure, then it's probably sufficient to use the
TLS 1.3 "context-including" digitally-signed production proposed by AGL. If
you you choose "option 1" where the delegated credential is an X.509 cert,
then you'd need to make some rules about fixing portions of the cert that
the TLS client can't control.

2. If you're concerned about attacks like those of Jager et al. which
exploit RSA decryption, what's important is that the attacker not be able
to get the server to do TLS 1.2-style static RSA with the key. Playing with
the usage bits definitely makes it harder to configure the server this way
(because it's likely to cause bustage) but may not be enough, because
sufficiently busted clients and server might be willing to use them that
way anyway.

In the next rev, we'll update the draft to make these points more clearly.