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 C494512D7E6 for ; Wed, 23 May 2018 14:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 Bfff3qSYvdQc for ; Wed, 23 May 2018 14:18:35 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49EE31201F8 for ; Wed, 23 May 2018 14:18:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2F9CE300558 for ; Wed, 23 May 2018 17:18:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QmHIvwEEfKKk for ; Wed, 23 May 2018 17:18:30 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 7CD8E3002C6; Wed, 23 May 2018 17:18:30 -0400 (EDT) From: Russ Housley Message-Id: <27DB472B-5905-4D3D-87C6-0A407B4BF0F4@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CC835D67-0BA0-4247-B773-C4F2250CF8E4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 23 May 2018 17:18:31 -0400 In-Reply-To: Cc: SPASM , IESG To: Warren Kumari References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> X-Mailer: Apple Mail (2.3273) 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: Wed, 23 May 2018 21:18:38 -0000 --Apple-Mail=_CC835D67-0BA0-4247-B773-C4F2250CF8E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please see my response at the bottom of the message ... >> On May 23, 2018, at 3:31 PM, Warren Kumari > wrote: >>=20 >> On Wed, May 23, 2018 at 1:39 PM Yoav Nir > wrote: >> Hi Warren. >>=20 >> Since it was my draft and presentation at SecDispatch that led to = this item, I feel I can answer this. Inline. >>=20 >> > On 23 May 2018, at 20:10, Warren Kumari > wrote: >> >=20 >> > Warren Kumari has entered the following ballot position for >> > charter-ietf-lamps-02-00: Block >> >=20 >> > 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.) >> >=20 >> >=20 >> >=20 >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/charter-ietf-lamps/ = >> >=20 >> >=20 >> >=20 >> > = ---------------------------------------------------------------------- >> > BLOCK: >> > = ---------------------------------------------------------------------- >> >=20 >> > "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." >> >=20 >> > This makes me twitch -- how short is "short=E2=80=9D? >>=20 >> [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. >>=20 >> > 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. >>=20 >> [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. =20 >>=20 >>=20 >> =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 will be between 1 day and 1 week. [...] , but I don=E2=80=99t = think anything beyond 2 weeks would ever count as short." >>=20 >> "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. >=20 > Warren: >=20 > 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. >=20 >=20 > =E2=80=8BI remain unconvinced -- some years ago I purchased a =E2=80=8BD= V 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 :-). >=20 > 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." - Ted Stevens. >=20 > 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') You needed a replacement certificate associated with a new key pair = because the private key was lost. You were not worried about someone = else using the private key in a malicious manner. I do not think this = work item will make that easier or harder. Russ --Apple-Mail=_CC835D67-0BA0-4247-B773-C4F2250CF8E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Please see my response at the bottom of the message ...

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=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 = can take days on the web.  In closed environments there may not be = CT at all. 


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


=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 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'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')

You needed a replacement certificate = associated with a new key pair because the private key was lost. =  You were not worried about someone else using the private key in a = malicious manner.  I do not think this work item will make that = easier or harder.

Russ

= --Apple-Mail=_CC835D67-0BA0-4247-B773-C4F2250CF8E4--