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

[Martin Thomson <[e-mail]>]

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.