Subject: Re: [arch-d] Call for Comment: <draft-iab-path-signals-02> (Transport Protocol Path Signals)

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Nov 2018 22:21:38 +0000

On 28/11/2018 21:55, IAB Executive Administrative Manager wrote:
> The Call for Comment will last until 2018-12-25. Please send comments to
> [email-masked] and [email-masked].

Dec 25th, heh. Sorry for sending mine early without any
gift wrapping:-)

Seems fairly reasonable but two comments.

1. I'd recommend avoiding the term consent - IMO our industry
has sullied that term too much for it to be usable. I'm also
not sure whether a machine/program can consent to anything
anyway. Perhaps talk about authorisation instead in your
pinhole example.

2. Integrity protecting explicit signals - I'm not sure we
know how to do that in many or perhaps even most of the
relevant scenarios. What I mean is that arranging keying
so that an endpoint or middlebox can integrity protect
something to be meaningfully verified by another, possibly
unknown, middlebox... is hard. And gets harder if you somehow
need integrity in both "directions." (I've seen that issue
going right back to digital signatures on X.400 delivery
notifications, so it's been around quite a while, without,
IIUC, being solved.) If the IAB feel you know how to do
that then it'd likely be good to say how, or point at some
working solutions illustrating what you mean. If you're
recommending that we do that, and it turns out not to be
easily doable then that might just add to the e2e/middlebox
tussle, instead of helping to resolve it, as I'm sure is the
intent. If you're less sure you know how to solve that one,
then saying that and encouraging work in the space would
seem to be as strong a recommendation as you can make.

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 30 Nov 2018 11:59:03 +0000

> On 28 Nov 2018, at 22:21, Stephen Farrell <[email-masked]> wrote:
> 
> Signed PGP part
> 
> 

I agree that consent is a challenging term, and as used in the document it is implied consent, but not necessarily meaningful consent.  I wonder if intent is a better phrasing.  It too is overused these days, but at least then you can talk about whose intent and whether that person is authorised to even have an opinion ;-)  Is it the intent of the designer of the tool or the intent of the administrator, or someone else?  Intent is sometimes easy to determine and sometimes hard.  For general purposes applications and tools, it may be impossible at scale (I don’t know): today we are all once again witnessing another uPnP fiasco.  And even if there are single-use applications, if they reside on a general use device, it is also quite difficult (albeit perhaps not impossible).

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Fri, 30 Nov 2018 12:51:13 -0800

Thanks to both of you for the review.  Trying to synthesize it, I'm
wondering if the following works, and I'd appreciate your feedback.

3.1.2.  Routability and Intent

   A second common inference that session establishment provides is that
   the communicating pair of hosts can each reach each other and are
   interested in continuing communication.  The firewall example given
   above is a consequence of that inference; because the
   internal host initiates the connection, it is presumed to want
   to receive return traffic.  That, in turn justifies the pinhole.

   Some other on-path elements assume that a host which asked to
   communicate with a remote address has authorized receiving incoming
   communications from any other host (Endpoint-Independent Mapping/
   Endpoint-Independent Filtering).  This is, for example, the default
   behavior in NAT64.

Is this better?

regards,

Ted

On Fri, Nov 30, 2018 at 3:59 AM Eliot Lear <[email-masked]> wrote:

> I agree that consent is a challenging term, and as used in the document it
> is implied consent, but not necessarily meaningful consent.  I wonder if
> intent is a better phrasing.  It too is overused these days, but at least
> then you can talk about whose intent and whether that person is authorised
> to even have an opinion ;-)  Is it the intent of the designer of the tool
> or the intent of the administrator, or someone else?  Intent is sometimes
> easy to determine and sometimes hard.  For general purposes applications
> and tools, it may be impossible at scale (I don’t know): today we are all
> once again witnessing another uPnP fiasco.  And even if there are
> single-use applications, if they reside on a general use device, it is also
> quite difficult (albeit perhaps not impossible).
>
> Eliot
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Nov 2018 20:56:22 +0000

On 30/11/2018 20:51, Ted Hardie wrote:
> wondering if the following works, and I'd appreciate your feedback

Sure, that sorts my first point nicely.

Cheers,
S.

>> and tools, it may be impossible at scale (I donâ€™t know): today we are all

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Fri, 30 Nov 2018 21:21:53 +0000

Yes thank you.

Eliot

On Nov 30, 2018, at 21:51, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

Thanks to both of you for the review.  Trying to synthesize it, I'm wondering if the following works, and I'd appreciate your feedback.

Is this better?

regards,

Ted

On Fri, Nov 30, 2018 at 3:59 AM Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:

> On 28 Nov 2018, at 22:21, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
>
> Signed PGP part
>
>
>> [email-masked]<mailto:[email-masked]> and [email-masked]<mailto:[email-masked]>.
>

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Fri, 30 Nov 2018 13:53:49 -0800

On Fri, Nov 30, 2018 at 12:56 PM Stephen Farrell <[email-masked]>
wrote:

> Thanks for the reminder that the second point hadn't been addressed.  Here
are the relevant pieces of text, along with some comments in-line:

o  The portion of protocol signaling that is intended for end system
      state machines should be protected by confidentiality and
      integrity protection such that it is only available to those end
      systems.

 o  Anything exposed to the path should be done with the intent that
      it be used by the network elements on the path.  This information
      should be integrity protected.

I hope we agree that the first bullet above is sorted, as you get integrity
protection along with confidentiality with TLS.  We can add that to the
bullet if you think it is necessary.

The second bullet is ambiguous.  I and I think others were thinking about
QUIC, where the integrity protection shows the endpoints if mucking about
has been done by network elements along the path, but does not show a
specific element if a prior element along that path has done anything. If
anything has been changed, you would get a fatal alert at the destination
end point, sent up and folded into a QUIC CONNECTION_CLOSE.

You're right that there is also the possibility of producing path signals
whose integrity can be checked by middleboxes with whom keys have been
exchanged, but not by unknown middleboxes.  There are some corner cases
(trust on second use, where the public key is in the first signal to the
path, and all later path signals are integrity protected with it), but they
have serious problems with path changes, early stage attacks, and generally
being worth the effort.

Rather than going into the integrity protection checked by those along the
path and the associated thicket of key management thorns, I personally
think it is better to clarify that we were thinking of the integrity checks
available to the endpoints.  Something like this:

Anything exposed to the path should be done with the intent that
      it be used by the network elements on the path.  This information
      should be integrity protected, so that end systems can detect if path
      elements have made changes in-flight.

 o  Signals exposed to the path should be decoupled from signals that
      drive the protocol state machines in endpoints.  This avoids
      creating opportunities for additional inference.

   o  Intermediate path elements should not add visible signals which
      identify the user, origin node, or origin network [RFC8164].  Note
      that if integrity protection is provided as suggested above, any
      signals added by intermediate path elements will be clearly
      distinguishable from those added by endpoints.

That also requires some changes to the final bullet point, which would then
read something
like:

  o  Intermediate path elements should not add visible signals which
      identify the user, origin node, or origin network [RFC8164].  Note
      that if integrity protection is provided for endpoint-supplied path
      signals as suggested above, any signals added by intermediate path
      elements will be clearly distinguishable from those added by endpoints,

      as they will not be within the integrity protected portion of the packet.

Do these changes make sense to you?  Are they enough, or do we need to say
more?

Ted

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Nov 2018 22:19:28 +0000

Hiya,

On 30/11/2018 21:53, Ted Hardie wrote:
> Do these changes make sense to you?  

Yep.

> Are they enough, or do we need to say
> more?

They're fine by me, thanks.

I would offer one other bit of text, maybe along the
lines of:

"Note: There are significant unsolved problems with
supporting non-endpoints in verifying signal integrity
or being enabled to modify signals while preserving
security. It is therefore likely that integrity
protection can only be applied by, and can only be
verified by, end-points."

But your suggested text is good enough if you'd rather
not add more.

Cheers,
S.