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

Kyle Rose <krose@krose.org> Fri, 08 July 2016 13:03 UTC

Return-Path: <krose@krose.org>
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 2E65512D1EA for <tls@ietfa.amsl.com>; Fri, 8 Jul 2016 06:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 xn35mBLcYpsz for <tls@ietfa.amsl.com>; Fri, 8 Jul 2016 06:03:38 -0700 (PDT)
Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (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 2331F12B03A for <tls@ietf.org>; Fri, 8 Jul 2016 06:03:37 -0700 (PDT)
Received: by mail-qk0-x241.google.com with SMTP id n132so8904499qka.0 for <tls@ietf.org>; Fri, 08 Jul 2016 06:03:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=waGPqy9ugQit7i5LQ/P7eskGcG8twixUF0s52DopdEo=; b=ciaAck0RjDGQZupZwzCCDwAvuX09lLUIglwTg76KkLU2MK+blUKqHM+/P7uyYcwBoU b9Kr1RIFPZh/U9n3RW5KCVoqpxkZ4+5zgds+oCltm1wIdlsIBctoEgG2DYfTGYZ7st61 a1aAjutI0f1EnbPzmOATdj4hSLfDIvKvrL17o=
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=waGPqy9ugQit7i5LQ/P7eskGcG8twixUF0s52DopdEo=; b=Ipo4quChh/5S66uFGXMvPoUd3zKglvCx0ES73qM2RFJDtAwKqkUjnKO5Gdy7x4oufn jje6NxD1XosD7LynTZQ7aT87SmS6Ao1C1vy8Z3QDzlBuM7SIJIm4dsmoSuckA7QNo8y8 GNtegFwvidL8nM5tSGJbJPJYc6YSObwyVK2xEpMa2KUhbSuGquXrYpsPk5RqEsl/X+FD C0o/0hD4864qDBDNTI0gewtEHEEU44Dvb1pmx4p0Ts1vxXxOK+4l5skX175O9FRoWerG ECuLJTfX6PrKOFlWmnu6VvU1Vp1Bn2Q7FsKezzh4JgpXSA0fVpHra5mZxkMdCkE5aQPJ alMg==
X-Gm-Message-State: ALyK8tIS2BRX2PHWUY8h1gDL7DxSMR8qcBtOZUlQzHj4avCkR9O/rm7bK+F7OA6jbkRhjcWZIqHOp7ix/QJKnA==
X-Received: by 10.55.207.81 with SMTP id e78mr7075424qkj.75.1467983016827; Fri, 08 Jul 2016 06:03:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.195.1 with HTTP; Fri, 8 Jul 2016 06:03:36 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:713a:86d:a34a:1966]
In-Reply-To: <20160708100934.GA14077@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBP+6AP50L06knsnOmyMqbv3fFw6TrcSrqs0x9FgoxyKcw@mail.gmail.com> <20160707221324.GA13128@LK-Perkele-V2.elisa-laajakaista.fi> <CAJU8_nWvqcAPiT03eLrvYGxFYf3hL4QpLw529yVS+f1hgBpycA@mail.gmail.com> <20160708100934.GA14077@LK-Perkele-V2.elisa-laajakaista.fi>
From: Kyle Rose <krose@krose.org>
Date: Fri, 08 Jul 2016 09:03:36 -0400
Message-ID: <CAJU8_nVv2Nq82C6bTuL=RQiiSEQQ75QrSpVfm5nQ6BfXDqXnww@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="001a1145ae064152ef05371f6e61"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/T9JzJsBeCOoDuMogRZYh28cCdpk>
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 13:03:46 -0000

On Fri, Jul 8, 2016 at 6:09 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

>
> There is validity start time in there, the relative end time would
> be relative to that.
>
> That is, instead of saying "this is valid from t1 to t2", saying "this
> is valid from t to t+dt".
>
> No real perference either way, it was just an experiment to play with
> time notations.
>

I think either would be fine, but once we start playing with the units
(e.g., decaseconds), we're probably likely to increase errors. The nice
thing about (t,dt) is that of the required checks:

t <= now
now <= t+dt
dt <= 7 days

the complex case (doing arithmetic on timestamps, for some value of
"complex") has a straightforward backup control with no arithmetic and with
comparison to a static value: dt <= 604800. With (t1,t2), the 7 day hard
limit is the more complex check.

That said, anyone hacking on security software probably shouldn't screw
this up in either case. I'm even struggling to imagine a system library
that could lead to unexpected errors here, given that the values are just
epoch times.

Kyle