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 B09E312E873 for ; Wed, 23 May 2018 13:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 9r5FjF_JBPMX for ; Wed, 23 May 2018 13:30:03 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C7E12D7F0 for ; Wed, 23 May 2018 13:29:59 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id t27-v6so20716212oij.9 for ; Wed, 23 May 2018 13:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=44fa8+bey6HlJBqubo3TArsxNZfayDLWVGEEkePqAWw=; b=BSzarVtECt5rW4awliQdZwQjcX8hT3vCwrwHyqCZoKOuysvOQWDR8OuzYdk10b+2vI 99jYFIbM46iYKEZH2m33Gmfw5v54jxmV+eJD+E2lyVLxtsuNrkLjQ+qIOV76ctGBfQGA dL4W9Cu4Sf1VE2+8UtCnwbDNzalZsP4n80x1gOjWOGepksyRlzJKqoRpw96nIcDtJsuN lmhzSM7VDLSImgXQaUfi+UCTpgynW68aQSDcgDEA/nerkcwWgk7Z938bKoiKKM4auVIr +2D2ZEBLEAA30m+XDH3nax54kYHHSGDPK/KsWvw5BKMfWsdqpQOFTwrssT4btyUkOAH2 gU7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=44fa8+bey6HlJBqubo3TArsxNZfayDLWVGEEkePqAWw=; b=MTfuTiVHADvdDWzfrj3CFT2JPZYwfz2iEovO6tfZlGC/ux9UKYnCRIyUacxAwLSv/y nevOmGfXCp2EMQslxjtiYSrJsf4bqSCVS97ehrhzL+OIvhFBsag3n0Zb/8YiAWCnoggG 8TxYTAPknO1lcc5p6oNFzNpIe613WZXFKO+UzF2xs5mQIiArA1zYeTFeS5s2cz3O8wyT m1FTWvcPyhSWLiHgUtZl3FFj+yNhJCFNqpWxJQu4nHErvjzTYhkgcy2Cgu0m4Np0p6N1 gNSAVYLy1sQFPgW9uG/o7qSIiD1U6kKOkBhtPePAjDGT5O2tXjTd+2SnBkznrMOo4C8S +ACg== X-Gm-Message-State: ALKqPwd+F+DhJ8lSQtdHAiAAyKN2a9a/4/SW1A/yzAmVApQVrxa96MnA ZXjK7B9TvPbyHo7mpW0CZKT0SeSdiHG9wlbv8d1YsQ== X-Google-Smtp-Source: AB8JxZoluyW4sruoeJK4QcjGQxBgBf1ezeHLrFrqXicEOU8MuMXpsRWputtur8ZhcL62/FYS2pirrtbxH/BZQlZ3F/c= X-Received: by 2002:aca:d10:: with SMTP id 16-v6mr2454602oin.108.1527107399162; Wed, 23 May 2018 13:29:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Wed, 23 May 2018 13:29:18 -0700 (PDT) In-Reply-To: References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> From: Eric Rescorla Date: Wed, 23 May 2018 13:29:18 -0700 Message-ID: To: Warren Kumari Cc: Yoav Nir , SPASM , lamps-chairs@ietf.org, The IESG Content-Type: multipart/alternative; boundary="0000000000000fb4ad056ce56626" 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 20:30:06 -0000 --0000000000000fb4ad056ce56626 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2018 at 12:31 PM, Warren Kumari wrote: > > > On Wed, May 23, 2018 at 1:39 PM Yoav Nir 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 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 thi= s >> > 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 Authorit= y. >> > 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=9C= not short=E2=80=9D to per-domain >> profiles, but I don=E2=80=99t think anything beyond 2 weeks would ever c= ount 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 attac= k, >> > 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." a= nd 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 bey= ond 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 shoul= d > be!) to make sure that this charter doesn't conflict with other work (esp= . > ops work), that the charter "describes the specific problem or deliverabl= es > (a guideline, standards specification, etc.) it has been formed to addres= s. > 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, an= d > 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 certificat= e >> 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 revok= ed >> > 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 go= t >> 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 wron= g >> / 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=E2=80=99t want to= deal with >> revocation information. Non-revocation is the end. Making them short-te= rm >> 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 the= m >> 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 > > --0000000000000fb4ad056ce56626 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 23, 2018 at 12:31 PM, Warren Kumari <<= a href=3D"mailto:warren@kumari.net" target=3D"_blank">warren@kumari.net= > wrote:


On Wed, May 23, 2018 at 1:39= PM Yoav Nir <y= nir.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.=C2=A0 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<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/cha= rter-ietf-lamps/
>
>
>
> ------------------------------------------------------------= ----------
> BLOCK:
> ------------------------------------------------------------= ----------
>
> "3. Specify the use of short-lived X.509 certificates for which n= o
> revocation information is made available by the Certification Authorit= y.
> Short-lived certificates have a lifespan that is shorter than the time=
> needed to detect, report, and distribute revocation information, as a<= br> > 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 l= ifetime will be between 1 day and 1 week.=C2=A0 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 th= ink anything beyond 2 weeks would ever count as short.

> And how long is the time to
> "detect, report, and distribute revocation information"? Wit= h e.g: CT,
> misissued certificates may be visible before they are used in an attac= k,
> 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-iss= ued. 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 c= opies of older revocation information. Add it up and it can take days on th= e web.=C2=A0 In closed environments there may not be CT at all.=C2=A0


=E2=80=8BSo, here you say: "Add it up and it can = take days on the web." and above that you say: "For typical syste= ms I think the likely lifetime will be between 1 day and 1 week. =C2=A0[...= ] , but I don=E2=80=99t think anything beyond 2 weeks would ever count as s= hort."

"1 week" minus "days" is still great= er than zero, and so it still *seems* to me that removing revocation is a b= ad idea -- but, my role is (or should be!) to make sure that this charter d= oesn't conflict with other work (esp. ops work), that the charter "= ;describes the specific problem or deliverables (a guideline, standards spe= cification, etc.) it has been formed to address. WG charters state the scop= e of work for group, and lay out goals and milestones that show how this wo= rk will be completed." It is (IMO) the sponsoring ADs, the WGs and IET= Fs 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 cl= ear my block once I've been assured process is being followed
/ this= has been considered.

Tha= nks. I think the thing that's important to understand is that revocatio= n on the Web is badly broken. The two primary standardized ways to deal wit= h revocation are:

- OCSP -- but it's so brittl= e that people won't hard fail, so it's not very good
- OC= SP stapling - which has a lifetime of around a week or so, and so basically= has the same security properties as short-lived certs.

<= /div>
-Ekr


>
> Also, I would figure that it is still useful to know that a certificat= e was
> revoked and didn't just expire -- if I see a certificate which exp= ired 10
> minutes ago I may be willing (after some consideration, checking my cl= ock, etc)
> to decide to trust it anyway (even if that's a bad idea!), but a r= evoked
> certificate is a clear indication that something bad happened, and cha= nges my
> risk assessment.

[YN] Yes, and the candidate draft has a SHOULD-level requirement to not all= ow 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= 9;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 informati= on. We want these certificates because we don=E2=80=99t want to deal with r= evocation information. Non-revocation is the end.=C2=A0 Making them short-t= erm is the means, or rather the sacrifice we need to make to make (other) s= ecurity people happy.

> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
>
> Also, "revoking them pointless" does not parse - perhaps &qu= ot;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 whe= n it was obviously a bad idea in the first place.
This is like putting r= abid weasels in your pants, and later expressing regret at having chosen th= ose particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf=

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm


--0000000000000fb4ad056ce56626--