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

[Warren Kumari <[e-mail]>]

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

>
>
> On Wed, May 23, 2018 at 12:31 PM, Warren Kumari <[e-mail]> wrote:
>
>>
>>
>> On Wed, May 23, 2018 at 1:39 PM Yoav Nir <[e-mail]> 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 <[e-mail]> 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.
>

​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
> - 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
>>> > [e-mail]
>>> > 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
>> [e-mail]
>> 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