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

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.  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.)

On Fri, Dec 22, 2017 at 12:00 AM, Eliot Lear <lear@cisco.com> wrote:
> Hi Ted,
>
> Following up on Brian's comment, as I wrote to you the last time, I really
> like this draft.  For some reason, Section 3.1.1 seems to have suffered
> editorially and needs just a bit of work.
>
> Eliot
>
>
> On 01.12.17 00:40, Ted Hardie wrote:
>
> As discussed in the last meeting, I have updated this slightly and brought
> it back into circulation.  The changes are very small (updating a reference,
> slightly enlarged pointer to fingerprinting risk).
>
> Hack away,
>
> Ted
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Thu, Nov 30, 2017 at 3:39 PM
> Subject: New Version Notification for draft-hardie-path-signals-02.txt
> To: Ted Hardie <ted.ietf@gmail.com>
>
>
>
> A new version of I-D, draft-hardie-path-signals-02.txt
> has been successfully submitted by Ted Hardie and posted to the
> IETF repository.
>
> Name:           draft-hardie-path-signals
> Revision:       02
> Title:          Path signals
> Document date:  2017-11-30
> Group:          Individual Submission
> Pages:          8
> URL:
> https://www.ietf.org/internet-drafts/draft-hardie-path-signals-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-hardie-path-signals/
> Htmlized:       https://tools.ietf.org/html/draft-hardie-path-signals-02
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hardie-path-signals-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-hardie-path-signals-02
>
> Abstract:
>    TCP's state mechanics uses a series of well-known messages that are
>    exchanged in the clear.  Because these are visible to network
>    elements on the path between the two nodes setting up the transport
>    connection, they are often used as signals by those network elements.
>    In transports that do not exchange these messages in the clear, on-
>    path network elements lack those signals.  This document discusses
>    the nature of the signals as they are seen by on-path elements and
>    reflects on best practices for transports which encrypt their state
>    mechanics.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> Stackevo mailing list
> Stackevo@iab.org
> https://www.iab.org/mailman/listinfo/stackevo
>
>
>
> _______________________________________________
> Stackevo mailing list
> Stackevo@iab.org
> https://www.iab.org/mailman/listinfo/stackevo
>