Encryption Design Team [was: What "mandatory to offer" means]

Eliot,

On 26/08/2013, at 8:02 PM, Eliot Lear <lear@cisco.com> wrote:

> Hi Mark:
> 
>> We have a lot of things to discuss around what that profile looks like; e.g., whether cert validation should take place. Since the negotiation mechanism itself is vulnerable to a downgrade attack, and since HTTP URIs don't have a strong security semantic, it may be reasonable to assume that certs for HTTP URIs shouldn't be validated -- which would ease deployment considerably. Like I said, though, there will need to be a lot of discussion.
> 
> And we discussed this in Paris and rejected it for all the reasons we
> are now revisiting.  And in Paris what we discussed was the fact that
> this will not solve Mike and Roberto's new feature deployment problem on
> port 80, precisely because of the downgrade attack issue.

I'm not saying it wasn't discussed, but it isn't in the minutes, and I don't have a recollection of that conversation. YMMV (my memory is terrible).

>  The other
> issue left is the Starbucks snooping problem, and I still claim that is
> better addressed at other layers.  Finally there is the snooping that
> goes on in the middle of the network, which you raised at the meeting. 
> I don't think this will solve that problem either, but it may cause
> middlebox vendors to sell some additional features to their service
> providers, based on government mandates.

Here's the thing. We argue by assertion a *lot* at the IETF. People come up with very convincing reasoning for why things should be one way or another, and sometimes we make decisions based upon that, because it's all we've got to go on.

OTOH I see a number of browser implementers who want to do something very real here. We haven't yet determined the shape of it yet, and already we have people saying "that won't work!" or "it's theatre!"

It may certainly be that you're right; maybe we won't be able to effect meaningful change within the many constraints we face*.  However, given that we have real implementer interest and willingness to experiment, I think it deserves at least some serious attention -- at least as much as the many hobby horse projects that get spawned without any sign of implementer interest at all. 

Given the risk of this becoming the mother of all ratholes, I'm inclined to think that it might be best to fork this discussion off to a design team, which can talk about it separately and come back to the WG with something more fully baked. Would that work for people, and if so, who would be interested in dedicating substantial time to it?

> I would suggest that a better focus is still honest-to-goodness easing
> of end-to-end authentication issues.  This is where the hard work needs
> to happen, and it will also facilitate dealing with the fundamental
> issues you've raised concerns about.  This, to me, is the high order bit.


If I had confidence that we (the IETF) could get it implemented and deployed, I'd be very much on board. Attending years of countless Bar BoFs, BoFs, WG meetings and other get-togethers hasn't led me to believe that's the case yet. Again, YMMV.

Cheers,


* Personally (and perhaps to Poul-Henning's questions), while I'm very interested in solving specific and immediate problems like the ones you mention, I'm even more interested in rectifying the imbalance between clients and servers regarding how encryption is used; I think that if we do that, it'll be good for the whole Web ecosystem in the (much) longer term.


--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 26 August 2013 10:53:40 UTC