Re: [TLS] draft-rescorla-tls-subcerts

Watson Ladd <> Fri, 08 July 2016 02:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E410612B05B for <>; Thu, 7 Jul 2016 19:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ekKWCvzD0Knl for <>; Thu, 7 Jul 2016 19:29:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8C82126FDC for <>; Thu, 7 Jul 2016 19:29:09 -0700 (PDT)
Received: by with SMTP id v6so44374540vkb.2 for <>; Thu, 07 Jul 2016 19:29:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0furfjwqS/k4u4QH9uMjG23Jin43+gfacPNCswP1owM=; b=XMmLkfbaT+aB6lB3N7qdmhx+bcmy68N2pBvGU0hrL+uCrskKO4sbVttbFD5R7iBwZi f03yvUAyYfz8EhLzVTiVlkB6kKw7NFW5nsEifyGNUYf5ljy30v9iDFYEYwKyWcf6p2cs 4TW2SCRYhNwkV1MlvbnoedWAr2KlFmcvI6S8rhDcf4JgTDGIJPQXqIXn2wLt6EuhmTBm ciJEj7K3m8Rln0n+tbmn23v42Svd3Rxuh6laV/9okv/7N3NE1FMom8tKIsOWwTPnh4M8 380mP1nBpOjm/lmPYX7JnKZ5KXtTzysQLKnye+FbZOGfwj8DX6Igzd0QaKrqbDvRfq0z fKLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0furfjwqS/k4u4QH9uMjG23Jin43+gfacPNCswP1owM=; b=WSGZTpnL5KfHzlXj3mRPdqkaE1dFP0WCm3ARSZCWejNFvWzhLnn/tlW86ZVaB3vejg vpsAJ/hHD4FoU7ByAG/TqNipoJqgNomKC50dpFgNHIeT2G5fR+DcE3V79Y4qsuLh9JXB +MjZKO7Za6EqySQOvoL9uQOosCyzHHqv8fvuRNB6PplFF8Hod+jogfN31IVg3jN03Z2k JiiKRNS39vy6HUaFJanG+osAsXazVVj2hhSsYabJTpENMzVv01pB3Bql998yrJZU8asZ lzyFA9ppiopiZZQoYPfgMBQknRXS3nGZ72jtYIGQXhA/7rnm/siZ3jrPH0mmVd5uunHA gNVA==
X-Gm-Message-State: ALyK8tKXo04G7wRrF9hcKIro4inOri7XEZYKCclj6r1WFmoj2oW//MZbtlUZfzIwTHwalBf6FTx6TfDWVbzBdg==
X-Received: by with SMTP id q70mr1449018uaq.16.1467944948608; Thu, 07 Jul 2016 19:29:08 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 7 Jul 2016 19:29:08 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Watson Ladd <>
Date: Thu, 07 Jul 2016 19:29:08 -0700
Message-ID: <>
To: Eric Rescorla <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] draft-rescorla-tls-subcerts
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jul 2016 02:29:12 -0000

On Jul 7, 2016 12:29 PM, "Eric Rescorla" <> wrote:
> 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 other
> 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 mechanism
> 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 something.
> 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.

How about limit to ECDSA certificates? This eliminates the
Bleichenbacher issues. We can also make this opt in via an extension
to the EE certificate: since the certificate is not a CA certificate
(even if used that way) the extension can be noncritical.

As for format we know we have a TLS 1.3 signed structure that doesn't
overlap. Option 2 is easy: throw a key and TAI seconds for interval
start and end. I hope we won't need more structure then that. Using
X509 runs a risk of cross-format issues, and showing there aren't any
is likely to be hard.

I don't think we can use name constraints here. Yes, they are opt-in
and clients can indicate support, but it may well be that a TLS
implementation doesn't know if its X509 validation code will support
them as it hands the certificate to a system provided validator. (I
believe there was a longstanding Chrome on Windows XP bug for a
similar reason).


> In the next rev, we'll update the draft to make these points more clearly.
> -Ekr
> _______________________________________________
> TLS mailing list