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

Warren Kumari <warren@kumari.net> Wed, 23 May 2018 21:09 UTC

Return-Path: <warren@kumari.net>
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 9F24312D7F5 for <spasm@ietfa.amsl.com>; Wed, 23 May 2018 14:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 oT3v2UBYH92g for <spasm@ietfa.amsl.com>; Wed, 23 May 2018 14:09:38 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 2A631127010 for <spasm@ietf.org>; Wed, 23 May 2018 14:09:38 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id f8-v6so12866045wmc.4 for <spasm@ietf.org>; Wed, 23 May 2018 14:09:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mtmQteiR0jjhYA+DeOboXH7kABchTzpr8Rip8tZh+Lc=; b=EKkOUhtLSHbGy1W8LxJRjuGLZCahOJbKVD/IVB5u/QGZP5nP4R3MN5/+ZglF8cCfS9 hRTDDrBDG9+hsaAZbeMFk2YtIJtR1dcjRZeW2AveXTFjg6gkQYM02WZS98uGyKR6slm/ P4BtN46NnJZREAZNxgobwh7KGIr+fR6h+es1xOJdFJoxFDqbgeqn372H6UBJUpGyGzAG jDU2HG5b9M/ngJNhjedEpRZKL7vZwbcdKyGMIn1uqHdltlkyYtebxv9JNuxSl46pOnLo hovPxYtjqCWG3kJcsWgwz/KeV7wNxXCrxPC3iuVOFFrtx1LjdB8SCkYOIQoTZqCTmNYG e7Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mtmQteiR0jjhYA+DeOboXH7kABchTzpr8Rip8tZh+Lc=; b=reocl/d1PuKRQLarIyyrPNBzzZ4s26oMBr+6IWv8ftoahQ4yo9bC2ntzEMc+RKpBj7 GtN7sq5i7FuH9pSyfs61WRRBBEX8/X2oFbHvg9eRPu+DekIY7//szga9zjtMla50f8VJ QKcjOGoIbitDsiYERAyhogkwqqqisxsCz5Z9/XHxiXz2Bo2km4Xquf93CswUdx1QphN+ ZyoYe/WbW7iB6jYS+EIv8SiJ8CX3wOdbJZWtW42qaDgXOQGHUAKZQImMwSAA4C17HnTR +pD3sE1dIn54rxyWkK7KSHA3lfPmbYjcV6+PLg7iNwn5ERZjCqkw2NkUuNxK0aM6/pwi EUQA==
X-Gm-Message-State: ALKqPweawXaK3S7/3KtMC4stcys/AvYwPOL9zg2lEBt0zOg10TUieA8e LvDlqmgvqBZROGB6ffTCMIVmhZUMA9CJkSkQ7zZw2ojjoJg=
X-Google-Smtp-Source: AB8JxZpMjaZObfjQ+U8I8JRBeuuvu8vo350BkWAWwGn1myelXSCUt52jI0SE7AQFS3J4qyxCLZYEvD0SiagSEzrftu4=
X-Received: by 2002:a1c:d755:: with SMTP id o82-v6mr4762757wmg.71.1527109776280; Wed, 23 May 2018 14:09:36 -0700 (PDT)
MIME-Version: 1.0
References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> <CAHw9_iJSB2Ui03+-JOtpfXEotqm_2Pm91gpaFbwtx=LbKgQ_Tw@mail.gmail.com> <C3E03496-0C4F-41D2-8927-9BE57512F5C2@vigilsec.com>
In-Reply-To: <C3E03496-0C4F-41D2-8927-9BE57512F5C2@vigilsec.com>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 23 May 2018 17:08:59 -0400
Message-ID: <CAHw9_i+uZr2h6hss89kOX6ig-hC+J6vtDrZLGD1p1AddYn=jTw@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, spasm@ietf.org, lamps-chairs@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bfa01d056ce5f34b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/kFPQuY3Xx0WpJsq0lRq_Py11mjc>
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 21:09:42 -0000

On Wed, May 23, 2018 at 3:53 PM Russ Housley <housley@vigilsec.com> wrote:

> Please see my response at the bottom of the message ...
>
>
​... and mine even further down :-)​

> On May 23, 2018, at 3: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.
>
>
> Warren:
>
> I think the point you are missing is that it take time to process
> revocation and get the CRL published or OCSP responder updated.  This is
> always over a week because people do not revoke without doing due
> diligence.  So, letting the short-lived certificate expire without issuing
> a replacement will actually cause revocation to happen more quickly.
>
>
​I remain unconvinced -- some years ago I purchased a ​DV cert and, though
a series of stupidly I managed to delete the private key[0]. The CA /
reseller I was using had a friendly "Revoke" button which let me upload a
new CSR and get a new cert within a few minutes. I'll happily admit that I
didn't check if they actually added the old one to a CRL, a: I assumed that
they did and b: they did let me reissue without more $$$ - which was the
only bit I actually cared about :-).

Now that I've finished writing this it feels somewhat like: "I just the
other day got… an Internet was sent by my staff at 10 o'clock in the
morning on Friday. I got it yesterday [Tuesday]. Why? Because it got
tangled up with all these things going on the Internet commercially." - Ted
Stevens.

W
[0]: ejabberd wants the key, cert and intermediate certs all in a single
.pem file -- while trying to make this I managed to overwrite the key  (I
did 'cp * > kumari.net-combined.pem' instead of 'cat * >
kumari.net-combined.pem')


> Russ
>
>

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