Subject: Re: https at ietf.org

From: [email-masked] (Noel Chiappa)
Date: Thu, 7 Nov 2013 12:33:46 -0500 (EST)

> From: Chris Inacio <[email-masked]>

    > To that effect, if we're really serious about this stuff, shouldn't
    > we want all email on the lists signed as well?

?? That would provide authentication. I thought the issue on the table was
privacy?

	Noel

---

From: Chris Inacio <[email-masked]>
Date: Thu, 7 Nov 2013 19:34:44 +0000

If people can tamper with the process without traceability, is the process open?

In order to be sure that you’ve produced an open result, should the activities of the process happen in secret?  What assurance would that give you in the result?  If the process is completely without merit - then what difference is it how (or if) someone might get the result?

Encrypting the process of getting the result is only working on the very last piece of the issue - isn’t it?  What use would that be without doing the other work to make the process trustable and robust?

HTTPS conveys to me that I have some level of trust in that I am communicating with the service I intended.  (I’m ignoring, completely that not all CA’s are equal and that DNS might completely lie to me along the way.)  That, for me at least, doesn’t necessarily create trust in the “product” of the service.

I buy crappy stuff from Amazon all the time, I’m just attempting to achieve that (1) it’s a little difficult to steal my credit card # (2) Amazon is forced to comply with PCI by the credit card processing companies.  The thing I order from Amazon may still be a total piece of junk.

HTTPS protects a user (presumably) from someone knowing which standard that downloaded or which mailing list archive they might have read.  If there is pervasive passive monitoring, it doesn’t protect them from being recognized as having gone to IETF.  And if you really have enough passive monitoring - determining which standard gets downloaded might be possible too, watch for the traffic spike, and check the size.  (It’s really easy for those reading NFS :) .)  Because the passive monitor can get all the standards too, and know their size just as well.

--
Chris Inacio
[email-masked]

---

From: [email-masked]
Date: Thu, 07 Nov 2013 12:15:11 -0800 (PST)

> If people can tamper with the process without traceability, is the process

OK, let me see if I understand what you're saying. You're saying that because
of the lack of protection on just one of the many means of getting public
information the IETF has produced, that someone is going to take advantage of
this to make some sort of nefarious change to some standards document, draft,
etc. and by doing so manage to change the outcome of a standards process.

If this is what you mean, then we've move to discussing what Bruce Scheier
calls a "movie-plot threat", and I suggest that you enter your idea into the
into the next contest Bruce runs.

It should do well there.

> ...

> HTTPS protects a user (presumably) from someone knowing which standard that
> downloaded or which mailing list archive they might have read.  If there is
> pervasive passive monitoring, it doesn’t protect them from being recognized as
> having gone to IETF.  And if you really have enough passive monitoring -
> determining which standard gets downloaded might be possible too, watch for the
> traffic spike, and check the size.  (It’s really easy for those reading NFS :)
> .)  Because the passive monitor can get all the standards too, and know their
> size just as well.

Which is why we should - and do - offer https access. And prefer it, if
possible.

But as you note - and as I have noted previously - this doesn't do squat about
traffic analysis, including but not limited to size checks. Perhaps rsyncing
the entire document collection is the best approach if size checks really are a
concern.

				Ned