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

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 08 July 2016 10:21 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 E3AA112D14F for <tls@ietfa.amsl.com>; Fri, 8 Jul 2016 03:21:17 -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 o8yPeXYIyi1e for <tls@ietfa.amsl.com>; Fri, 8 Jul 2016 03:21:15 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7A13712D0B3 for <tls@ietf.org>; Fri, 8 Jul 2016 03:21:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id AF51D1194; Fri, 8 Jul 2016 13:21:13 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id DVhHa61hwAw7; Fri, 8 Jul 2016 13:21:13 +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-smtp2.welho.com (Postfix) with ESMTPSA id 4B55421C; Fri, 8 Jul 2016 13:21:13 +0300 (EEST)
Date: Fri, 08 Jul 2016 13:21:10 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20160708102110.GB14077@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBP+6AP50L06knsnOmyMqbv3fFw6TrcSrqs0x9FgoxyKcw@mail.gmail.com> <CACsn0ck3wtyS9awSOADmm_pG5ZhE8ZSbwtGpATGEooYA7Y3mKQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CACsn0ck3wtyS9awSOADmm_pG5ZhE8ZSbwtGpATGEooYA7Y3mKQ@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/iTOR6Fb1wJzl4TB4ee4HioSJQwQ>
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: Fri, 08 Jul 2016 10:21:18 -0000

On Thu, Jul 07, 2016 at 07:29:08PM -0700, Watson Ladd wrote:
> On Jul 7, 2016 12:29 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:
> 
> 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.

You mean ECDSA legacy signature type (TLS_ECDHE_ECDSA_WITH_*
ciphersuites)? There's EdDSA too (and it would meet the above definition)?

New extension would need CAs to issue it, and getting them to do that
could be, erm... "laborious".

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

Or use POSIX time notation if you can tolerate being off by a second
due to leap secods.

Then the proposal had server name or server name list. Dunno if those
are needed.

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

The nasty Chrome on WinXP bug I was aware of was that WinXP code couldn't
handle certificates that were like "allow all, except .foo". LE X1
intermediate hit that bug, causing lots of trouble, even with WinXP being
EoL'd.



-Ilari