Subject: Re: [Uta] (extra) WGLC for draft-ietf-uta-tls-bcp-07.txt

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 01 Dec 2014 18:40:25 -0700

On 11/13/14, 8:47 AM, Salz, Rich wrote:
>> That said, I'm not confident I know the impact of the change to 7.5
>> (the OCSP stuff) as I've not gone looking at code nor thought about
>> any ops issues that could arise, but it looks reasonable for sure,
>> so is probably ok unless someone yells.
>
> I just re-read the document, particularly 7.5.  I'd move the two CRL
> bullets together (i.e., "and the last shall be second" as it were).
> And in the second (to become third) bullet, I think the privacy
> issues are particularly important for non-heavy-traffic web servers,
> so I'd remove that whole when close at the end of the first
> sentence.

Noted, thanks!

> But other than those two minor quibbles, it looks very good.  +1 ( I
> was pleasantly surprised to see my name in sec 8 :)

I believe in acknowledging people who help. :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 01 Dec 2014 19:01:53 -0700

On 11/13/14, 7:59 PM, Dr. Massimiliano Pala wrote:
> Hi all,
>
> If it is not too late... regarding Session 7.5 - first bullet point: the
> text seems a bit too restrictive. Probably in the context of current Web
> Browser CRLs are not used today, but other environments still make a
> wide use of CRLs. I also would like to add a privacy consideration about
> the use of CRLs vs. other mechanisms.
>
> For this I would the text from:
>
>     Certificate Revocation Lists (CRLs) are not scalable and therefore
>     rarely used.
>
>
> to something like the following:
>
>     Certificate Revocation Lists (CRLs) provide the most supported
>     revocationinformation distribution mechanism. Although updates to
>     the CRLformat (e.g., partitioned CRLs, delta CRLs) have been defined
>     toaddress scalability issues, they are rarely used in favor of more
>     compact formats. However, it is important to notice that the use of
>     CRLs might provide better privacy-preserving properties than other
>     protocols (e.g., OCSP), especially when considering the validation of
>     client-side certificate.
>
> The last consideration stems from the fact that by using CRLs, a service
> does not need to communicate to the certificate issuing authority (e.g.,
> the CA or the entity running an OCSP server) and disclose the
> certificate for which the revocation status is requested.

How about this?

    o  Although Certificate Revocation Lists (CRLs) are the most widely
       supported mechanism for distributing revocation information, they
       have known scaling challenges that limit their usefulness.
       However, CRLs might provide better privacy-preserving properties
       than other techniques (e.g., OCSP), since there is no need to
       communicate with a third party regarding the certificate that a
       client is checking.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 1 Dec 2014 22:24:13 -0500

> >     protocols (e.g., OCSP), especially when considering the validation of

Are you using CRL as a generic term -- to include tihngs like CRLset, for example?  If so, then this makes sense. But if so, then I think the wording needs to be tweaked, since portioning and delta CRL's are only for the classic X.509 CRL structures.But then if it does include generic, then Chrome support for CRLSet is a pretty widely deployed use on the Web.  The private point raised is important. Not sure if it's important for client certificates (since you've already decided to give the server your cert); I do think it is VERY important for server-side certificates, where not letting national-scale adversaries know where you might be connecting is (well, er) key.
 
--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 1 Dec 2014 23:39:01 -0500

Hi Rich, Peter, all,

Thanks for the comments. My suggestions were more related to X.509 CRLs, which are the ones we standardized in PKIX. 

Personally, I do not think that CRLSet is something that we should really be concerned with at IETF. In particular, I think that CRLSet is a bad and fast fix to a real problem that (a) is available from one single vendor, (b) completely ignores the golden rule about PKIs by substituting the real source of trust (the CA) with an application-level (chrome) decision (not even user-driven!), and (c) is an ad-hoc not-standardized solution.

For client side certificates, I think that checking the revocation status in that environment carries even more privacy concerns. This might be true especially when the certificate to be checked is issued by a CA that is not connected to the services offered by the server.

For example, if you are checking the revocation from a 3rd party CA (e.g. for granting access to a building), checking the revocation status of that certificate might reveal the user's position or even its activity (e.g. logging into her e-mail or accessing a building) to the CA's revocation servers - they have no business knowing that information and that info might even be disclosed to passive attackers that monitor the traffic. Another example, can be when using client-side certificates for WiFi roaming.

Therefore I think that also for client-side certificates the privacy issue is quite relevant.

Just my two cents...

Cheers,
Max

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 1 Dec 2014 23:43:09 -0500

Hi Peter, all,

It looks ok.. although I would have preferred to maintain some kind of reference to partitioned and delta CRL with reference to X.509 (PKIX) - since we are talking about TLS, x.509 is the standard of reference for client and server certificates.

Just my 2 cents...

Cheers,
Max

> On Dec 1, 2014, at 9:01 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:
>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 02 Dec 2014 17:21:35 -0700

> It looks ok.. although I would have preferred to maintain some kind of reference to partitioned and delta CRL with reference to X.509 (PKIX) - since we are talking about TLS, x.509 is the standard…

You're right, it would be good to include that.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Brian Smith <[email-masked]>
Date: Tue, 2 Dec 2014 18:08:56 -0800

Peter Saint-Andre - &yet <[email-masked]> wrote:
>> It looks ok.. although I would have preferred to maintain some kind of
>> reference to partitioned and delta CRL with reference to X.509 (PKIX) -
>> since we are talking about TLS, x.509 is the standard of reference for
>> client and server certificates.
>

I'm not sure it is good to spend effort on recommending CRL stuff in
an the current draft, when the trend seems to be towards applications
realizing CRLs don't work well and moving away from them. I think what
the current draft says about CRLs is better.

Cheers,
Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 Dec 2014 21:25:22 -0500

I agree that we don't want to spend lots of time discussing CRL's and variants since we're staying they don't work well.

---

From: Ralph Holz <[email-masked]>
Date: Sat, 6 Dec 2014 13:49:10 +1100

I +1 that - discussing CRLs is like rearranging the deck chairs on RMS
Titanic, as PG once put it. Talking about delta CRLs seems rather esoteric,
too.

On 3 December 2014 at 13:25, Salz, Rich <[email-masked]> wrote:

> I agree that we don't want to spend lots of time discussing CRL's and
> variants since we're staying they don't work well.
>
> --
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Rick Andrews <[email-masked]>
Date: Mon, 8 Dec 2014 12:33:23 -0800

Still, I wouldn’t remove the discussion of CRLs. It’s possible that they will prove better than alternatives in some IoT applications.

From: Ralph Holz [mailto:[email-masked]]
Sent: Friday, December 05, 2014 6:49 PM
To: Salz, Rich
Cc: [email-masked]; Brian Smith
Subject: Re: [Uta] (extra) WGLC for draft-ietf-uta-tls-bcp-07.txt

I +1 that - discussing CRLs is like rearranging the deck chairs on RMS Titanic, as PG once put it. Talking about delta CRLs seems rather esoteric, too.

On 3 December 2014 at 13:25, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:
I agree that we don't want to spend lots of time discussing CRL's and variants since we're staying they don't work well.

--
Principal Security Engineer, Akamai Technologies
IM: [email-masked]<mailto:[email-masked]> Twitter: RichSalz
_______________________________________________
Uta mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/uta

---

From: "Robin Alden" <[email-masked]>
Date: Mon, 8 Dec 2014 15:39:02 -0500

+1

From: Uta [mailto:[email-masked]] On Behalf Of Rick Andrews
Sent: 08 December 2014 15:33
To: Ralph Holz; Salz, Rich
Cc: [email-masked]; Brian Smith
Subject: Re: [Uta] (extra) WGLC for draft-ietf-uta-tls-bcp-07.txt

---

From: Richard Moore <[email-masked]>
Date: Mon, 8 Dec 2014 21:20:32 +0000

On 8 December 2014 at 20:33, Rick Andrews <[email-masked]> wrote:

> Still, I wouldn't remove the discussion of CRLs. It's possible that they
> will prove better than alternatives in some IoT applications.
>
>
>
Really? I'm not sure how small devices will even be able to hold the CRLs
given the size let alone process them? I'd have thought something along the
lines of the must-staple certificate extension would be a lot more
practical there.

Rich.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 08 Dec 2014 18:26:40 -0700

On 12/8/14, 2:20 PM, Richard Moore wrote:
>
>
> On 8 December 2014 at 20:33, Rick Andrews <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Still, I wouldn’t remove the discussion of CRLs. It’s possible that
>     they will prove better than alternatives in some IoT applications.____
>
>
>
> Really? I'm not sure how small devices will even be able to hold the
> CRLs given the size let alone process them? I'd have thought something
> along the lines of the must-staple certificate extension would be a lot
> more practical there.

The authors have no plan to remove text about CRLs. But, in any case, 
I'd encourage folks who care about the IoT use cases to write a BCP that 
applies specifically to that application domain.

Peter

---

From: Rick Andrews <[email-masked]>
Date: Tue, 9 Dec 2014 13:40:02 -0800

Rich, if the device itself does cert validation, yes, I would agree with you. But there may be other options where head ends or some other kind of proxy (more capable than the devices themselves) perform validation on behalf of downstream devices. In such cases, CRLs might be more efficient than issuing many unique OCSP requests.

From: Richard Moore [mailto:[email-masked]]
Sent: Monday, December 08, 2014 1:21 PM
To: [email-masked]
Subject: Re: [Uta] (extra) WGLC for draft-ietf-uta-tls-bcp-07.txt

On 8 December 2014 at 20:33, Rick Andrews <[email-masked]<mailto:[email-masked]>> wrote:
Still, I wouldn't remove the discussion of CRLs. It's possible that they will prove better than alternatives in some IoT applications.

Really? I'm not sure how small devices will even be able to hold the CRLs given the size let alone process them? I'd have thought something along the lines of the must-staple certificate extension would be a lot more practical there.

Rich.