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

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.  

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

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