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

i can work on the proposed design team.


On Mon, Aug 26, 2013 at 6:53 AM, Mark Nottingham <mnot@mnot.net> wrote:

> 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/
>
>
>
>
>