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

From: Warren Kumari <[email-masked]>
Date: Wed, 23 May 2018 10:10:37 -0700

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

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.

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Also, "revoking them pointless" does not parse - perhaps "revoking them is pointless"?

---

From: Yoav Nir <[email-masked]>
Date: Wed, 23 May 2018 20:39:50 +0300

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 <[email-masked]> wrote:
> 
> 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

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

> certificate is a clear indication that something bad happened, and changes my

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

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

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Warren Kumari <[email-masked]>
Date: Wed, 23 May 2018 15:31:26 -0400

On Wed, May 23, 2018 at 1:39 PM Yoav Nir <[email-masked]> wrote:

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

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

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

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

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 23 May 2018 12:53:10 -0700

On May 23, 2018 at 3:32:21 PM, Warren Kumari ([email-masked]) wrote:

Hi!

"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
<http://airmail.calendar/2018-05-24 12:00:00 EDT>, and will clear my block
once I've been assured process is being followed
/ this has been considered.

I agree with Warren’s assessment.

However, I also think that a charter may give undue validation to items
that would benefit from at least a little more description or
consideration.  IOW, adding (to the charter) a longer description, and
listing which things should be satisfied, or at least considered, seems
like a good idea to me.

Alvaro.

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 May 2018 15:53:38 -0400

Please see my response at the bottom of the message ...

> On May 23, 2018, at 3:31 PM, Warren Kumari <[email-masked]> wrote:
> 
> On Wed, May 23, 2018 at 1:39 PM Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Warren.
> 
> > On 23 May 2018, at 20:10, Warren Kumari <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > https://datatracker.ietf.org/doc/charter-ietf-lamps/ <https://datatracker.ietf.org/doc/charter-ietf-lamps/>
> > 
> > 
> > 
> ​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

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.

Russ

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 23 May 2018 16:23:35 -0400

On Wed, May 23, 2018 at 3:53 PM, Alvaro Retana <[email-masked]>
wrote:

> <http://airmail.calendar/2018-05-24%2012:00:00%20EDT>, and will clear my
> block once I've been assured process is being followed
This was my request in
https://mailarchive.ietf.org/arch/msg/spasm/paYqxqRL1LEEPgwOuGmUVB8V6lE/?qid=356aa0482508fa29bf866d05ea1981e6
and Stephen Farrell's agreement in
https://mailarchive.ietf.org/arch/msg/spasm/Evk_hbJsHBuBGEnNaMCqaQEVceI

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 May 2018 13:29:18 -0700

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

> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 May 2018 16:52:28 -0400

On Wed, May 23, 2018 at 1:10 PM, Warren Kumari <[email-masked]> wrote:

> "3.
> ​​
> Specify the use of short-lived X.509 certificates for which no
> Short-lived certificates have a lifespan
> ​​
> that is shorter than the time

​How about ​
​"
​
Specify the use of "short-lived" X.509 certificates that are issued with
validity intervals that fall within the validity window for reporting
revocation
information permitted by the application, thus obviating the need for
online certificate status reporting"

Note:

* Yeah, 'obviating', sorry but it does not necessarily eliminate the OCSP
requirement for legacy reasons but it makes using the service pointless.

​* Such certificates may still be listed in CRLs but the treatment of these
is likely to be different.

* At least one browser provider still believes in certificate revocation
and is looking to support short lived certificates as part of a strategy
that provides for much more aggressive revocation than is currently
possible. That is within minutes rather than days.​ So this is not really
about killing revocation, it is about superseding OCSP.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 23 May 2018 17:08:59 -0400

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

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 23 May 2018 17:15:35 -0400

On Wed, May 23, 2018 at 4:29 PM Eric Rescorla <[email-masked]> wrote:

>> ​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
> Thanks. I think the thing that's important to understand is that
> revocation on the Web is badly broken.
>

​Ok. *That* I'll buy... :-)

It sounds like the WG / people more knowledge about the subject than me
(i.e. everyone :-)) has considered this, and I'm in the rough / it isn't as
scary as I'd though.

I just cleared my Block, thank you everyone for the education,
W

> 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

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 May 2018 17:18:31 -0400

>> On May 23, 2018, at 3:31 PM, Warren Kumari <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> ​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')

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 May 2018 21:22:17 -0400

> kumari.net-combined.pem')

​Revocation at the request of the subject is easy to automate because 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. ​