On Wed, Jun 20, 2018 at 03:21:52PM -0400, Paul Wouters wrote:
> On Wed, 20 Jun 2018, Eric Rescorla wrote:
> 
> > I thought I had made clear what was bothering me, so I suppose we must be 
> > talking past each other. I read this text as saying that there are
> > important cases where in fact the client will not have any reasonable  way 
> > of knowing which domains to accept from the server, which, it seems
> > to me, contradicts the claim above that it's practical. You obviously think 
> > i'm wrong, so how should I be reading this text?
> 
> I understand what bothers you. You see browsers getting non-public TLSA
> answers and you are concerned about webpki bypass and enterprise
> meddling.
> 
> I see text restricting and notifying users of the domain names that will
> be part of the IKE configuration or negotiation allowing them to reject
> inappropriate domains.
> 
> You fear the user will just click yes. Then you somehow would like to

This seems like the main fear, yes, but perhaps not exclusively so.
It's kind of how users "always" click through certificate warnings in
browsers, or "alway" grant a mobile app all the requested permissions.
If, to expand unreasonably upon a previous example, connecting to the Red
Hat VPN wanted to take over redhat.com, openstack.com, rhbz.com,
rhmail.com, rh.zone, redhat.googleapps.com, rh.googleapps.com,
realham.googleapps.com, freeipa.com, freeipa.org, and centos.org, is it
reasonable to expect the user to look at the list and pick out
"realham.googleapps.com" as not belonging?  Maybe they think it's a
codename for some Red Hat project, but maybe it's something totally
unrelated and reflects overreach by the VPN provider.

It seems to border on unreasonable to have such a long list and expect user
knowledge.  On the one hand, the VPN provider "ought to know" what domains
it's responsible for (and are on the internal view), but on the other hand
this is essentially a self-certification and does not inherently have any
level of trust.  It would be great if there was some third party that could
provide some certification that the list of controlled domains is valid, or
at least not present in the public view and controlled by someone else
(since there will presumably be cases when internal names are not expected
to be visible in the public view at all).  I'm not coming up with a great
technical solution off the top of my head, though.  "Something in the public
DNS" might work, if you can forgive the incredibly vague idea.

> know how common this new behaviour would be and how reasonable it is
> for a client to understand what is happening. I cannot answer how common
> this would be other than stating in the past this wasn't possible at
> all. And that client understanding could be presented cleanly and I gave
> an example.

I think it will be very common for users to "click through" without
actually looking at the list, with fairly high confidence.  I expect (but
at a lower level of confidence) that it will also be common for enterprises
to have lists of more than three domains in the internal view.

-Benjamin

> To me, the only question is how to change the text so this is all clear
> to you, but you say you are still gathering facts and you are not ready
> yet to evaluate any proposed changes.
> 
> Maybe some other people can chime into this discussion and/or provide
> text to clarify things to you better than I am able to.
> 
> Paul

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to