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

[Ted Hardie <[e-mail]>]

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.



> 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?

Ted


> On Fri, Dec 22, 2017 at 12:00 AM, Eliot Lear <[e-mail]> 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: <[e-mail]>
> > Date: Thu, Nov 30, 2017 at 3:39 PM
> > Subject: New Version Notification for draft-hardie-path-signals-02.txt
> > To: Ted Hardie <[e-mail]>
> >
> >
> >
> > 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
> > [e-mail]
> > https://www.iab.org/mailman/listinfo/stackevo
> >
> >
> >
> > _______________________________________________
> > Stackevo mailing list
> > [e-mail]
> > https://www.iab.org/mailman/listinfo/stackevo
> >
>