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

On Wed, May 23, 2018 at 12: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.
>

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

> >
>> > 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
>> > Spasm@ietf.org
>> > 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
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>
>