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

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 07 July 2016 22:13 UTC

Return-Path: <ilariliusvaara@welho.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 A062F12D14D for <tls@ietfa.amsl.com>; Thu, 7 Jul 2016 15:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 tKeQM7bJeiSh for <tls@ietfa.amsl.com>; Thu, 7 Jul 2016 15:13:28 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id B82DA12D100 for <tls@ietf.org>; Thu, 7 Jul 2016 15:13:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 52B4684AC; Fri, 8 Jul 2016 01:13:27 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id C7L3K5V_XxqJ; Fri, 8 Jul 2016 01:13:27 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EDD482310; Fri, 8 Jul 2016 01:13:26 +0300 (EEST)
Date: Fri, 8 Jul 2016 01:13:24 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20160707221324.GA13128@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBP+6AP50L06knsnOmyMqbv3fFw6TrcSrqs0x9FgoxyKcw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBP+6AP50L06knsnOmyMqbv3fFw6TrcSrqs0x9FgoxyKcw@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/apJ6_R29avS4So4Y2KPRuUc3IHs>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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 22:13:31 -0000

On Thu, Jul 07, 2016 at 12:28:33PM -0700, 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:
> https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
> 
> 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 think most browsers ignore KeyUsage presently, allowing the broken RSA
  key exchange even when KeyUsage does not permit it. And as for server side,
  I don't think many server products check the certificate they try to load,
  just serve it mostly blindly.
- I would definitely use TLS 1.3 signature construct for digitally-signed
  instead of TLS 1.2 one, as it mitigates some attacks (oh, you arlready
  mentioned it below).

Also, instead of extension one way that came to mind would be a new
CertficateType, where Cert#0 is the delgated credential and Cert#1 is
X.509 EE cert, and then comes the normal CA certs. Dunno which would be
better.

I also checked if one could do some funky stuff with credential lifetime
notation to limit the lifetime. Nothing came up (apart for using 16-bit
count in decaseconds (das) only allowing presenting lifetimes up to 7
days, 14 hours, 2 minutes and 30 seconds). :->


Also, what is the ServerNameList for? As far as I see, the delegated
credential structure only contains one name. Or was it supposed to have
multiple, but there was a typo in definition?

Also why "SignatureScheme algorithm;" ... Doesn't digitally-signed already
have a algorithm field?

Also, doesn't digitally-signed "eat" all the fields inside? So if you
want to actually transfer the data, you need the actual fields the second
time?


-Ilari