Return-Path: 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 0198B124217; Wed, 23 May 2018 18:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HrgE5COq54Nz; Wed, 23 May 2018 18:22:18 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 88B6C1289B0; Wed, 23 May 2018 18:22:18 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id h8-v6so27516208otb.2; Wed, 23 May 2018 18:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kcOHHDm6TAnbHMzgvo5FmF/j9LwqnTogzSKbI3c70rI=; b=BIGogw8pyvQTuwF0wtjmHXYtYlar86nm0QZjnXZzXoI34oF+i6G7dl6dw5cXws6lBd YklcZfCJjnFbGZb62ugj6uQ/3Cc1K4we4/lCRetO36HaxT/84SEO1iXD+MK+Csk+udGu ZyLnZL3Yl2f71PJGvGwbh1cNz3eT4xIUJXlYdyg/uhg+RQ6JtNw/ci3JQepJjU2twwL7 6a8TGFwP8BX8yBpKC3+Bw16o2HRbAblLUai9tFxCZQav3iQErkE2E2ayyOiCq8YQzlkf 0m2VEp/JqEzapNvxH/GCvUwUcW3+HmSHiVM/2Xfe4VEjc2km26SAgVpBAQHCtVaPVJvT zE+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kcOHHDm6TAnbHMzgvo5FmF/j9LwqnTogzSKbI3c70rI=; b=jmHy3gy0wBVGgelnBytXwnT8Mp9UAxifoWo72NldsR6yvGr4qCOhI5uKcLlEpGURVP kp7///et6h8WgOzOABW3WHyBtvgRZ+vjoSceHAZO4YFnOZbcX0sZI6KhU5a1Tfk+uje1 4vYbAx1YSVP6BXJg0mtLPC51DzS7hPX5TUUwDD5Ojk1N23dzuxyWRtqjjjiEYeMvKlwM GppPCUjtIYJoo1iWTzWucQ8WYPoanWm/iidJdRWfXIxWPESSJ+Ycm/MB2we8A9ezStaF n9PnRpFtR+K13tqCrHxi62+Q8EaWuvHZMdtvkaDvzZT/RamWTgrbpBSjOFMVgJKgTD1S j6wA== X-Gm-Message-State: ALKqPwcC49Bs0z4YF25J2HvbFLHffVt/v9z4+9oLzZL9/mE32lrIJsQr s+9h2Yy6hNJ5DdO0r+J83/Bb1rjUG84cqAWFmE0= X-Google-Smtp-Source: AB8JxZom0e/SZv2vzjpHF6GqbIcBUhxutnOo35C10Gw3RwLr2UlEaIuYD1gS9CWbilpZtsQwZWtMxRvcMt5GpWfjKaU= X-Received: by 2002:a9d:2511:: with SMTP id k17-v6mr3043074otb.129.1527124937737; Wed, 23 May 2018 18:22:17 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Wed, 23 May 2018 18:22:17 -0700 (PDT) In-Reply-To: References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> From: Phillip Hallam-Baker Date: Wed, 23 May 2018 21:22:17 -0400 X-Google-Sender-Auth: cD2GCA6Rn9i7DwIZECvXXGNS01w Message-ID: To: Warren Kumari Cc: Russ Housley , SPASM , lamps-chairs@ietf.org, The IESG , Yoav Nir Content-Type: multipart/alternative; boundary="000000000000710b41056ce97b19" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 01:22:21 -0000 --000000000000710b41056ce97b19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2018 at 5:08 PM, Warren Kumari wrote: > > > On Wed, May 23, 2018 at 3:53 PM Russ Housley wrote= : > >> Please see my response at the bottom of the message ... >> >> > =E2=80=8B... and mine even further down :-)=E2=80=8B > >> On May 23, 2018, at 3:31 PM, Warren Kumari wrote: >> >> On Wed, May 23, 2018 at 1:39 PM Yoav Nir 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 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 th= is >>> > 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 tim= e >>> > needed to detect, report, and distribute revocation information, as a >>> > result revoking them pointless." >>> > >>> > This makes me twitch -- how short is "short=E2=80=9D? >>> >>> [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 >>> =E2=80=9Cshort=E2=80=9D 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=E2=80=99s valid for= the working >>> group to leave the cut-off between =E2=80=9Cshort=E2=80=9D and =E2=80= =9Cnot short=E2=80=9D to per-domain >>> profiles, but I don=E2=80=99t 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 ca= n >>> take days on the web. In closed environments there may not be CT at al= l. >>> >>> >> =E2=80=8BSo, 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 wil= l >> be between 1 day and 1 week. [...] , but I don=E2=80=99t 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 shou= ld >> be!) to make sure that this charter doesn't conflict with other work (es= p. >> ops work), that the charter "describes the specific problem or deliverab= les >> (a guideline, standards specification, etc.) it has been formed to addre= ss. >> 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, a= nd >> 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 issui= ng >> a replacement will actually cause revocation to happen more quickly. >> >> > =E2=80=8BI remain unconvinced -- some years ago I purchased a =E2=80=8BDV= 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 th= at > 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=E2=80=A6 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." - T= ed > 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') > =E2=80=8BRevocation at the request of the subject is easy to automate becau= se they gave consent. Revocation for breach of terms of service is much more involved. The complaint may be valid or it may be a DoS attack on the site. =E2=80=8B --000000000000710b41056ce97b19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Ma= y 23, 2018 at 5:08 PM, Warren Kumari <warren@kumari.net> wro= te:


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


=
=E2=80=8B... and mine even fu= rther down :-)=E2=80=8B
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.=C2=A0 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<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/cha= rter-ietf-lamps/
>
>
>
> ------------------------------------------------------------= ----------
> BLOCK:
> ------------------------------------------------------------= ----------
>
> "3. Specify the use of short-lived X.509 certificates for which n= o
> revocation information is made available by the Certification Authorit= y.
> Short-lived certificates have a lifespan that is shorter than the time=
> needed to detect, report, and distribute revocation information, as a<= br> > result revoking them pointless."
>
> This makes me twitch -- how short is "short=E2=80=9D?

[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 =E2=80=9Cshort=E2= =80=9D could be as low as an hour. For typical systems I think the likely l= ifetime will be between 1 day and 1 week.=C2=A0 IMHO it=E2=80=99s valid for= the working group to leave the cut-off between =E2=80=9Cshort=E2=80=9D and= =E2=80=9Cnot short=E2=80=9D to per-domain profiles, but I don=E2=80=99t th= ink anything beyond 2 weeks would ever count as short.

> And how long is the time to
> "detect, report, and distribute revocation information"? Wit= h e.g: CT,
> misissued certificates may be visible before they are used in an attac= k,
> 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-iss= ued. 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 c= opies of older revocation information. Add it up and it can take days on th= e web.=C2=A0 In closed environments there may not be CT at all.=C2=A0


=E2=80=8BI remain unco= nvinced -- some years ago I purchased a =E2=80=8BDV cert and, though a seri= es 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 ne= w 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 assume= d 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=E2=80=A6 an Internet was sent by my staff at 10 o&= #39;clock in the morning on Friday. I got it yesterday [Tuesday]. Why? Beca= use it got tangled up with all these things going on the Internet commercia= lly." - Ted Stevens.

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


=E2= =80=8BRevocation at the request of the subject is easy to automate because = they gave consent.

Revoca= tion for breach of terms of service is much more involved. The complaint ma= y be valid or it may be a DoS attack on the site. =E2=80=8B

=

=C2=A0
--000000000000710b41056ce97b19--