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

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

Return-Path: <ekr@rtfm.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 8900D12D8CD for <tls@ietfa.amsl.com>; Thu, 7 Jul 2016 15:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrgSGSO9yMVm for <tls@ietfa.amsl.com>; Thu, 7 Jul 2016 15:20:10 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 A841012D635 for <tls@ietf.org>; Thu, 7 Jul 2016 15:20:10 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id l125so26446860ywb.2 for <tls@ietf.org>; Thu, 07 Jul 2016 15:20:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0xFXH7ryjPCipjsFDtlkO+23aAhtK0rugkBVImzTfIw=; b=0oEKTmsEXugwPpMDQ4j1eQv7Ez5eG2jIMlir7IKMb5kgzOc0qEyimo2H/BK7m5FP77 DNxB8i93Rxen61dZsYjMzKICkftvohYQa3Rb/aj4hFO76vnzMZS9A10LuJx4f8IK1hpA UFRq0TUec8lHk78zsT2bBH5GIGpqdj/sy0zxTX/ond7zQkgGNKrtW8tEeCRHFfYqOU7H glOCTJaNgmdRazQaDl3rf4HdprhMxovf7MYDUSJZzSZP+Iz+Oyaiuc6bFzByxEGb7bER +COh1av9y8XtSuJtK+/kR30H+QUxyld/3ZWMM8qhCysfeez8USJnBaDja5qO3Uq4F65e xsqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0xFXH7ryjPCipjsFDtlkO+23aAhtK0rugkBVImzTfIw=; b=GS7cl5LWmNRVaCAuFgoytSslp+GK/dgWQC9f2QMyYZAA/Sg4qjeBbLOtdWYaTBWhI9 2fyclFbQdl8iSyUAovssZ2wRQjzV9Xk0Vci+kS/Oq05edV+tvv2tZFQxSjDI2Ae23u9+ 1Xrlz0JQob7bJt2zjjUG4d2cmFwEzVPpAVPd5kOuIb37tl7q6kmZFwhgA7E+kNEp6o20 M5mV3E4gyYVrgegKXGTMb5G9AhwCN40fhLeTVYDIlNoxYBD98BoE/6UiGsJAze5cecO1 6INaX8sJBZxSJ1SWqvNU5BqwuFzP6SdKCRTD0qjHtf2HPcyXF9gCbddhZL848hRA0m/L 8JsA==
X-Gm-Message-State: ALyK8tJlDvgbDUGmH5pwfs7IQqao15iQxqoh7GkGzOzn/CG3Yogh/FurJ6zsVz81D9DRNYJqfpxP6VfbyR7Flw==
X-Received: by 10.129.55.76 with SMTP id e73mr2407363ywa.16.1467930009882; Thu, 07 Jul 2016 15:20:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.152.13 with HTTP; Thu, 7 Jul 2016 15:19:30 -0700 (PDT)
In-Reply-To: <20160707221324.GA13128@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBP+6AP50L06knsnOmyMqbv3fFw6TrcSrqs0x9FgoxyKcw@mail.gmail.com> <20160707221324.GA13128@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 7 Jul 2016 15:19:30 -0700
Message-ID: <CABcZeBPi5CeKjOR8_66vouoUaG6q3QX6_JNJuTyMZyhEYY2snA@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary=001a1144002ccb851305371316aa
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lan7KBrMMrw2N_0Cz_9azDkbUFk>
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:20:12 -0000

On Thu, Jul 7, 2016 at 3:13 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> 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.
>

This is my sense as well. That text in the document probably needs to be
rewritten.



> 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?


All good catches. This was supposed to be more evocative than definitive,
and
we probably would have been better not providing any definition at all :)

-Ekr


>
> -Ilari
>