Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 23 May 2018 20:30 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09E312E873 for <spasm@ietfa.amsl.com>; Wed, 23 May 2018 13:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 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, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable 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 9r5FjF_JBPMX for <spasm@ietfa.amsl.com>; Wed, 23 May 2018 13:30:03 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 C9C7E12D7F0 for <spasm@ietf.org>; Wed, 23 May 2018 13:29:59 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id t27-v6so20716212oij.9 for <spasm@ietf.org>; Wed, 23 May 2018 13:29:59 -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=44fa8+bey6HlJBqubo3TArsxNZfayDLWVGEEkePqAWw=; b=BSzarVtECt5rW4awliQdZwQjcX8hT3vCwrwHyqCZoKOuysvOQWDR8OuzYdk10b+2vI 99jYFIbM46iYKEZH2m33Gmfw5v54jxmV+eJD+E2lyVLxtsuNrkLjQ+qIOV76ctGBfQGA dL4W9Cu4Sf1VE2+8UtCnwbDNzalZsP4n80x1gOjWOGepksyRlzJKqoRpw96nIcDtJsuN lmhzSM7VDLSImgXQaUfi+UCTpgynW68aQSDcgDEA/nerkcwWgk7Z938bKoiKKM4auVIr +2D2ZEBLEAA30m+XDH3nax54kYHHSGDPK/KsWvw5BKMfWsdqpQOFTwrssT4btyUkOAH2 gU7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=44fa8+bey6HlJBqubo3TArsxNZfayDLWVGEEkePqAWw=; b=MTfuTiVHADvdDWzfrj3CFT2JPZYwfz2iEovO6tfZlGC/ux9UKYnCRIyUacxAwLSv/y nevOmGfXCp2EMQslxjtiYSrJsf4bqSCVS97ehrhzL+OIvhFBsag3n0Zb/8YiAWCnoggG 8TxYTAPknO1lcc5p6oNFzNpIe613WZXFKO+UzF2xs5mQIiArA1zYeTFeS5s2cz3O8wyT m1FTWvcPyhSWLiHgUtZl3FFj+yNhJCFNqpWxJQu4nHErvjzTYhkgcy2Cgu0m4Np0p6N1 gNSAVYLy1sQFPgW9uG/o7qSIiD1U6kKOkBhtPePAjDGT5O2tXjTd+2SnBkznrMOo4C8S +ACg==
X-Gm-Message-State: ALKqPwd+F+DhJ8lSQtdHAiAAyKN2a9a/4/SW1A/yzAmVApQVrxa96MnA ZXjK7B9TvPbyHo7mpW0CZKT0SeSdiHG9wlbv8d1YsQ==
X-Google-Smtp-Source: AB8JxZoluyW4sruoeJK4QcjGQxBgBf1ezeHLrFrqXicEOU8MuMXpsRWputtur8ZhcL62/FYS2pirrtbxH/BZQlZ3F/c=
X-Received: by 2002:aca:d10:: with SMTP id 16-v6mr2454602oin.108.1527107399162; Wed, 23 May 2018 13:29:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Wed, 23 May 2018 13:29:18 -0700 (PDT)
In-Reply-To: <CAHw9_iJSB2Ui03+-JOtpfXEotqm_2Pm91gpaFbwtx=LbKgQ_Tw@mail.gmail.com>
References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> <CAHw9_iJSB2Ui03+-JOtpfXEotqm_2Pm91gpaFbwtx=LbKgQ_Tw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 23 May 2018 13:29:18 -0700
Message-ID: <CABcZeBOue9JU4v=EP++VUicS=0ZcM5fW0iCw5v1n63Z__ON6hA@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: Yoav Nir <ynir.ietf@gmail.com>, SPASM <spasm@ietf.org>, lamps-chairs@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000fb4ad056ce56626"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/6ov7-8wvvMnuA1Pq5uDL8H-NXaA>
Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2018 20:30:06 -0000

On Wed, May 23, 2018 at 12:31 PM, Warren Kumari <warren@kumari.net> wrote:

>
>
> On Wed, May 23, 2018 at 1:39 PM Yoav Nir <ynir.ietf@gmail.com> wrote:
>
>> Hi Warren.
>>
>> Since it was my draft and presentation at SecDispatch that led to this
>> item, I feel I can answer this.  Inline.
>>
>> > On 23 May 2018, at 20:10, Warren Kumari <warren@kumari.net> wrote:
>> >
>> > Warren Kumari has entered the following ballot position for
>> > charter-ietf-lamps-02-00: Block
>> >
>> > When responding, please keep the subject line intact and reply to all
>> > email addresses included in the To and CC lines. (Feel free to cut this
>> > introductory paragraph, however.)
>> >
>> >
>> >
>> > The document, along with other ballot positions, can be found here:
>> > https://datatracker.ietf.org/doc/charter-ietf-lamps/
>> >
>> >
>> >
>> > ----------------------------------------------------------------------
>> > BLOCK:
>> > ----------------------------------------------------------------------
>> >
>> > "3. Specify the use of short-lived X.509 certificates for which no
>> > revocation information is made available by the Certification Authority.
>> > Short-lived certificates have a lifespan that is shorter than the time
>> > needed to detect, report, and distribute revocation information, as a
>> > result revoking them pointless."
>> >
>> > This makes me twitch -- how short is "short”?
>>
>> [YN] I expect this to be contentious within the working group, and I
>> expect the exact cut-off point to be different from one use-case to
>> another. For highly reliable systems with good clock synchronization
>> “short” could be as low as an hour. For typical systems I think the likely
>> lifetime will be between 1 day and 1 week.  IMHO it’s valid for the working
>> group to leave the cut-off between “short” and “not short” to per-domain
>> profiles, but I don’t think anything beyond 2 weeks would ever count as
>> short.
>>
>> > And how long is the time to
>> > "detect, report, and distribute revocation information"? With e.g: CT,
>> > misissued certificates may be visible before they are used in an attack,
>> > decreasing the detection time.
>>
>> [YN] Someone needs to see the certificate to add it to the log, and
>> someone needs to find the certificate on the log and understand that it is
>> mis-issued. And then someone needs to add it to the CRL / database that
>> feeds the OCSP responder. And when this is updated, relying parties may
>> have cached copies of older revocation information. Add it up and it can
>> take days on the web.  In closed environments there may not be CT at all.
>>
>>
> ​So, here you say: "Add it up and it can take days on the web." and above
> that you say: "For typical systems I think the likely lifetime will be
> between 1 day and 1 week.  [...] , but I don’t think anything beyond 2
> weeks would ever count as short."
>
> "1 week" minus "days" is still greater than zero, and so it still *seems*
> to me that removing revocation is a bad idea -- but, my role is (or should
> be!) to make sure that this charter doesn't conflict with other work (esp.
> ops work), that the charter "describes the specific problem or deliverables
> (a guideline, standards specification, etc.) it has been formed to address.
> WG charters state the scope of work for group, and lay out goals and
> milestones that show how this work will be completed." It is (IMO) the
> sponsoring ADs, the WGs and IETFs decision as to if the ideas themselves
> are acceptable.
> I'm not (yet!) so arrogant that I'm sure I know the right answer to
> everything, so I'd like to discuss this with EKR on the call tomorrow, and
> will clear my block once I've been assured process is being followed
> / this has been considered.
>

Thanks. I think the thing that's important to understand is that revocation
on the Web is badly broken. The two primary standardized ways to deal with
revocation are:

- OCSP -- but it's so brittle that people won't hard fail, so it's not very
good
- OCSP stapling - which has a lifetime of around a week or so, and so
basically has the same security properties as short-lived certs.

-Ekr


> >
>> > Also, I would figure that it is still useful to know that a certificate
>> was
>> > revoked and didn't just expire -- if I see a certificate which expired
>> 10
>> > minutes ago I may be willing (after some consideration, checking my
>> clock, etc)
>> > to decide to trust it anyway (even if that's a bad idea!), but a revoked
>> > certificate is a clear indication that something bad happened, and
>> changes my
>> > risk assessment.
>>
>> [YN] Yes, and the candidate draft has a SHOULD-level requirement to not
>> allow any grace periods for such certificates. One of the feedbacks I got
>> was that this should be upgraded to MUST (or rather MUST NOT)
>>
>>
> Ok. That helps.
>
> Thanks!
> W
>
> >
>> > It's entirely possible that there is a really good reason why I'm wrong
>> / that
>> > this argument doesn't make sense in some use cases (or just that I'm
>> nuts!)
>>
>> [YN] There was some push-back about the name. The important point is not
>> so much that the lifetime is short, but that there is no revocation
>> information. We want these certificates because we don’t want to deal with
>> revocation information. Non-revocation is the end.  Making them short-term
>> is the means, or rather the sacrifice we need to make to make (other)
>> security people happy.
>>
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> >
>> >
>> > Also, "revoking them pointless" does not parse - perhaps "revoking them
>> is pointless"?
>> >
>> >
>> > _______________________________________________
>> > Spasm mailing list
>> > Spasm@ietf.org
>> > https://www.ietf.org/mailman/listinfo/spasm
>>
>>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>    ---maf
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>
>