Re: SSL/TLS everywhere fail

> On 7 Dec 2015, at 12:13, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> 
> --------
> In message <AD5923A5-875D-4A3B-AFFF-26CE042934FC@lukasa.co.uk>, Cory Benfield writes:
> 
>>> I am not sure I understand why you consider that an "absurd flaw"
>>> and I have not been able to find any mail-discussion where such
>>> a critique is raised.
>>> 
>>> Can you summarize the argument ?
> 
> Thanks for the summary.
> 
> I find it a bit harsh to say that the proposed header/signature
> format has an "absurd flaw" when the flaw complained about is
> really "key distribution is hard".
> 
> Yes, key-distribution can be hard, but that is a separate issue.

I don’t think I’m quite complaining about “key distribution is hard”. If the draft had any text talking about the importance of key distribution, that would be a fair characterisation, but it contains nothing at all.

I agree that key distribution is hard, it’s terribly hard, and I need to say up from that I’m nowhere near smart enough to solve it. However, I think it is a dereliction of duty for this WG to not address the requirements of a key distribution system in anything we want to standardise.  We don’t need to solve it, and we don’t even need to be particularly strict, but we have a duty of care to ensure that systems we build for security actually *are* secure when implemented by people who don’t have the expertise of the people in this channel.

If we can’t solve the problem (and we certainly can’t *today*), then our mission should be to provide guidance and criteria by which key distribution mechanisms should be judged. Ideally we’d go further and recommend one for general use, because an RFC is useless unless you can use it to build something that has a reasonable shot at interoperating with other implementations.

I think the fairest criticism is actually that “Martin probably hadn’t got there yet”. I believe that Martin is aware of these problems, and I suspect my language was too aggressive, so I’m sorry for that Martin.

> 
>> As a result, I consider it extremely important that any implementation
>> we have either be TOFU and have a normative requirement to cache that
>> key indefinitely, or that it use some out-of-band key distribution
>> mechanism. Otherwise, all an attacker needs to do is sit on the
>> connection and replace both the body *and* the key: a relatively trivial
>> thing to do.
> 
> Again, this is the general key-distribution problem which have no
> "ideal" and often not even "adequate" solutions.
> 
> But there are large swatches of the HTTP traffic where there are
> perfectly good and workable key-distribution mechanisms, and holding
> them up, waiting for a solution to an unsolveable problem makes no
> sense.

Sure, but please understand me: I don’t want “perfect”. I want *any guidance at all*. I want the draft to say *something* about the risks inherent in key distribution and the problems that a suitable key distribution mechanism must solve. Again, I don’t believe that any of the people in this WG would get this wrong, but we should write for people who are not us.

> To take one example:  API and IoS HTTP traffic almost always have
> the ability to implement PSK, and key distribution doesn't get
> any better than that.

Yes, PSK is clearly totally acceptable. The draft should say so.

> There are also a lot of creative ways that key-distribution can
> be boot-strapped in the browser-centric HTTP universe.
> 
> For instance I could open a HTTPS to a newspaper, and one of the
> things I get back is the instruction:  "When you pick up our stuff
> from the 3rd party CDN, the content must be signed with this key”.

Good idea: in fact, I seem to recall that that was my item (1) in my list of key distribution techniques! However, that message needs to be standardised as being applicable to this draft. Perhaps some kind of registry of RFCs that talk about how keys can be distributed for signing purposes, which would allow both new mechanisms (like this one) and making existing mechanisms (the CA system) applicable for signing.

Basically what I’m saying is: I don’t want us to solve the key distribution problem. I want us to address the fact that it *is* a problem, so that implementers are not caught off-guard because they haven’t thought about it. I would like us to propose solutions to this problem. I think that generating standards that basically say “here’s a cool thing you can do if you have secure keys” without alluding to the problems of obtaining and controlling the use of those keys is insufficient.

Cory