Re: [Stackevo] Fwd: New Version Notification for draft-hardie-path-signals-02.txt

[Ted Hardie <[e-mail]>]

The new repo is at:

https://github.com/hardie/path-signals

PR away....

Ted

On Tue, Jan 2, 2018 at 1:34 PM, Martin Thomson <[e-mail]>
wrote:

> On Wed, Jan 3, 2018 at 4:51 AM, Ted Hardie <[e-mail]> wrote:
> > On Mon, Jan 1, 2018 at 9:14 PM, Martin Thomson <[e-mail]
> >
> > wrote:
> >>
> >> I also think that we should explicitly identify not encrypting as an
> >> option.  We could still have integrity protection.  Of course, we
> >> should then make it clear that rampant misguided inference is why we
> >> are encrypting.  I'd put something in the introduction to Section 4
> >> there.
> >>
> >> I have one consideration to add, probably to security considerations
> >> (more on that below).  Explicit signals can be disconnected from the
> >> protocol signaling machinery.  Doing so might be necessary to avoid
> >> path entities inferring more from the signal than is intended.
> >
> >
> > As a confirmation/friendly amendment, does rephrasing this as "protocol
> > state machinery" work for you?  If so, I would actually strengthen this
> to
> > "should be disconnected".  Ideally, I would like the path elements to
> > consume the signals explicitly for them even if there is an unencrypted
> > portion of a flow; inferring from that tends to ossify things and
> avoiding
> > that is a key part of our aim.
>
> Sure, the point is that the signaling that drives the protocol state
> machinery at either end is distinct from the explicit signals to the
> path.  I'd say that should is appropriate (even in the 2119 sense).
>
> >> If
> >> QUIC takes a spin bit, that's a clear example of where we take RTT
> >> information and signal that, but we separate that signal from all of
> >> the rich acknowledgment information the protocol really needs.
> >> However, this split creates a potential for those signals to be
> >> incorrect or even for them to be falsified, presumably with the intent
> >> of manipulating path entities in some way.
> >>
> >> I don't think that we need any specific mitigation, but we should
> >> recognize that this is a natural consequence of the recommendations in
> >> the draft.  That isn't strictly a negative outcome either.  One
> >> conceivable - but actually highly unlikely - outcome of designing
> >> explicit signals is that intermediaries might insist on a certain set
> >> of signals before a packet is allowed to pass ("give me SNI or I kill
> >> your flow").  A signal that isn't directly coupled to the actual
> >> protocol machinery can be falsified to appease a middlebox, even in
> >> cases where the endpoint might otherwise prefer not to provide the
> >> information.  I wouldn't include all that exposition though, just note
> >> that falsification is possible, without affecting the e2e protocol
> >> operation.
> >>
> >> On structure, I think that the bulk of the security considerations are
> >> better moved elsewhere.  The bullet list seems to belong in Section 5.
> >>
> >> (I agree with Eliot regarding editing.  There are quite a number of
> >> typos that I would have sent a PR for, had there been a destination
> >> that a PR could be directed toward.)
> >>
> >
> > I'll get it onto github.  Since I generally start that by cloning one of
> > your repos, which is the current one to crib from?
>
> I generally point people at
> https://github.com/martinthomson/i-d-template/
> blob/master/doc/REPO.md#fast-setup
> now.  But you can crib from
> https://github.com/martinthomson/postel-was-wrong/ which I keep up to
> date.
>