Re: [TLS] comments on draft-ietf-tls-tls13-19

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 23 April 2017 10:34 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 4C4381276AF for <tls@ietfa.amsl.com>; Sun, 23 Apr 2017 03:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 65I225fbcN_V for <tls@ietfa.amsl.com>; Sun, 23 Apr 2017 03:34:48 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id C51CA1252BA for <tls@ietf.org>; Sun, 23 Apr 2017 03:34:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 211C621AA4; Sun, 23 Apr 2017 13:34:45 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id ZS42TjHD3YqY; Sun, 23 Apr 2017 13:34:44 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id B3450C4; Sun, 23 Apr 2017 13:34:44 +0300 (EEST)
Date: Sun, 23 Apr 2017 13:34:42 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Kurt Roeckx <kurt@roeckx.be>
Cc: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20170423103442.GA16936@LK-Perkele-V2.elisa-laajakaista.fi>
References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <CABcZeBMCZrVKM959F3ycKN_WAky2NAZTy9OOetnC+KJAj3L+Pw@mail.gmail.com> <1492786351.14070.2.camel@redhat.com> <CABcZeBOe4-yEW8r15fsOtHJbQrnqGJ6oUaGYjoUwYS0MQE-rHQ@mail.gmail.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <20170422214205.bxu5whfqzy5kshsw@roeckx.be>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/p_SZ5TZ3nyli9K8Rui7NiJHcyVg>
Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 23 Apr 2017 10:34:50 -0000

On Sat, Apr 22, 2017 at 11:42:06PM +0200, Kurt Roeckx wrote:
> On Sat, Apr 22, 2017 at 03:00:17PM +0300, Ilari Liusvaara wrote:
> > On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote:
> > > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos <nmav@redhat.com>
> > > wrote:
> > > 
> > > > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote:
> > > >
> > > > > Do you have any thoughts on what text we should insert here? I admit
> > > > > to being not that familiar with the practical matters of OCSP
> > > > > stapling.
> > > >
> > > > My issue with OCSP when used under TLS was how to determine the
> > > > validity of the response when the nextUpdate field is missing. I've
> > > > added some text for that introducing an (arbitrary) upper limit at:
> > > > https://github.com/tlswg/tls13-spec/pull/974
> > > 
> > > 
> > > This text looks good to me, but it is is a normative change and we've
> > > been through WGLC so I'd like to hear from a few other people that they're
> > > OK
> > > with it (or have the chairs tell me that silence is consent). David
> > > Benjamin?
> > > Richard Barnes? Ryan Sleevi?
> > 
> > I searched what minimum standards for "public" CAs say. The maximum
> > lifetime there is 10 days (but IIRC some widely-used root program has
> > lower limit, might have been 7 days)..
> > 
> > Anybody happens to know a CA that doesn't put NextUpdate in? If so,
> > what's the OCSP issuance frequency?

> <Snip BR rules>

I meant if anyone has seen a OCSP response from "public" CA lately that
lacks NextUpdate.

And the 12 month update interval for intermediates is IMO just crazy,
and won't work properly in TLS 1.3, now that multistaple is pretty much
a baseline feature.

Looking at those rules, 7 day default would still work fine with 4 day
issue frequency. And 7 days also seems to be the limit for various
kinds caching (e.g. tickets, subcerts, etc...) that circumvent
revocation in various drafts and specs.


As for what the TLS library I have written does if OCSP staple lacks
NextUpdate, it outright causes handshake failure and fatal alert.


-Ilari