Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Joe Touch]

On 3/7/2017 10:12 PM, David Mazieres expires 2017-06-05 PDT wrote:
> Joe Touch  writes:
>
>> On 3/7/2017 9:45 PM, dm-list-tcpcr...@scs.stanford.edu wrote:
>>> Wesley Eddy  writes:
>>>
>  If a host sends a SYN-only SYN+ENO segment bearing data and
>  subsequently receives a SYN-ACK segment without an ENO option,
>  that host MUST reset the connection even if the SYN-ACK segment
>  does not acknowledge the SYN data...
 Saying "reset the connection" is interesting to me, because technically 
 there is not yet any connection (there are TCBs at each side, but 
 neither has entered ESTABLISHED state).  The reset that's sent should 
 probably *not* acknowledge any data that may have been on the SYN-ACK, 
 which seems important to state.  That way, if some application's 
 transaction erroneously started due to data on the SYN, any response 
 piggybacking the SYN-ACK would not be acknowledged, and the RST should 
 cause the application transaction to fail.
>>> I'm trying to tie up loose ends here, and think this is the only
>>> relevant point from the mailing list that we may have not yet have
>>> satisfactorily addressed in our working draft.  Several points in
>>> section 4.7 use the term "reset the connection."  I've now attempted to
>>> define the term more pedantically the first time I use it.  Here's the
>>> new language:
>>>
>>>If a host sends a SYN+ENO segment with data and receives
>>>acknowledgment for the data, but the SYN TEP governing the data is
>>>not the negotiated TEP (either because a different TEP was negotiated
>>>or because ENO failed to negotiate encryption), then the host MUST
>> FWIW, I would just jump right to the following, which avoids giving
>> unnecessary detail:
>>
>>abort the connection. Proceeding in any other fashion risks
>> misinterpreted SYN data.
> Thanks, that's how we had it before (well, "reset the connection" was
> what we had before).  But Wesley made me worry that the phrase "reset
> the connection" might not be specific enough.  Is "abort" better than
> "reset"?
Per RFC793:

Abort is an event that the TCP API implements (and can be called by
users, the OS, etc.).

Reset is a message that TCP issues/receives, and happens within the
protocol in reaction to message receipt, timer expiration, or API events.

This is why "reset the connection" is imprecise, whereas "abort the
connection" is not. ;-)

>>>reset the TCP connection by transitioning to TCP's CLOSED state and
>>> ^^
>>>responding to the acknowledgment with a reset segment as if the
>>>^^^
>>>connection had never existed.  Proceeding in any other fashion risks
>>>
>>>misinterpreted SYN data.
>> If you do say which state to end up in, I would think you would want to
>> transition to TIME-WAIT, otherwise the connection could reopen using the
>> same socket pair and you may have a hazard condition.
>>
>> See: T. Faber, J. Touch, and W. Yue, “The TIME-WAIT state in TCP and Its
>> Effect on Busy Servers ,” in
>> /Proc. IEEE Infocom/, 1999, pp. 1573-1583.
> Right, this is exactly why I'm worried about getting too specific.  What
> I want to say is something like "abort the connection" with an implicit
> reference to best current practice.  If most people think "abort the
> connection" or "reset the connection" is unambiguous, then I'll go with
> that.
>
> Is there a reason you said "abort" rather than "reset"?  I was thinking
> reset might be better because of reset generation, but would defer to
> you on which word is better.

There is. See above.

Joe

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Joe Touch]

On 3/7/2017 9:45 PM, dm-list-tcpcr...@scs.stanford.edu wrote:
> Wesley Eddy  writes:
>
>>>  If a host sends a SYN-only SYN+ENO segment bearing data and
>>>  subsequently receives a SYN-ACK segment without an ENO option,
>>>  that host MUST reset the connection even if the SYN-ACK segment
>>>  does not acknowledge the SYN data...
>>
>> Saying "reset the connection" is interesting to me, because technically 
>> there is not yet any connection (there are TCBs at each side, but 
>> neither has entered ESTABLISHED state).  The reset that's sent should 
>> probably *not* acknowledge any data that may have been on the SYN-ACK, 
>> which seems important to state.  That way, if some application's 
>> transaction erroneously started due to data on the SYN, any response 
>> piggybacking the SYN-ACK would not be acknowledged, and the RST should 
>> cause the application transaction to fail.
> I'm trying to tie up loose ends here, and think this is the only
> relevant point from the mailing list that we may have not yet have
> satisfactorily addressed in our working draft.  Several points in
> section 4.7 use the term "reset the connection."  I've now attempted to
> define the term more pedantically the first time I use it.  Here's the
> new language:
>
>If a host sends a SYN+ENO segment with data and receives
>acknowledgment for the data, but the SYN TEP governing the data is
>not the negotiated TEP (either because a different TEP was negotiated
>or because ENO failed to negotiate encryption), then the host MUST
FWIW, I would just jump right to the following, which avoids giving
unnecessary detail:

   abort the connection. Proceeding in any other fashion risks
misinterpreted SYN data.

>reset the TCP connection by transitioning to TCP's CLOSED state and
> ^^
>responding to the acknowledgment with a reset segment as if the
>^^^
>connection had never existed.  Proceeding in any other fashion risks
>
>misinterpreted SYN data.
If you do say which state to end up in, I would think you would want to
transition to TIME-WAIT, otherwise the connection could reopen using the
same socket pair and you may have a hazard condition.

See: T. Faber, J. Touch, and W. Yue, “The TIME-WAIT state in TCP and Its
Effect on Busy Servers ,” in
/Proc. IEEE Infocom/, 1999, pp. 1573-1583.

Joe
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[dm-list-tcpcrypt]

Wesley Eddy  writes:

>>  If a host sends a SYN-only SYN+ENO segment bearing data and
>>  subsequently receives a SYN-ACK segment without an ENO option,
>>  that host MUST reset the connection even if the SYN-ACK segment
>>  does not acknowledge the SYN data...
>
>
> Saying "reset the connection" is interesting to me, because technically 
> there is not yet any connection (there are TCBs at each side, but 
> neither has entered ESTABLISHED state).  The reset that's sent should 
> probably *not* acknowledge any data that may have been on the SYN-ACK, 
> which seems important to state.  That way, if some application's 
> transaction erroneously started due to data on the SYN, any response 
> piggybacking the SYN-ACK would not be acknowledged, and the RST should 
> cause the application transaction to fail.

I'm trying to tie up loose ends here, and think this is the only
relevant point from the mailing list that we may have not yet have
satisfactorily addressed in our working draft.  Several points in
section 4.7 use the term "reset the connection."  I've now attempted to
define the term more pedantically the first time I use it.  Here's the
new language:

   If a host sends a SYN+ENO segment with data and receives
   acknowledgment for the data, but the SYN TEP governing the data is
   not the negotiated TEP (either because a different TEP was negotiated
   or because ENO failed to negotiate encryption), then the host MUST
   reset the TCP connection by transitioning to TCP's CLOSED state and
^^
   responding to the acknowledgment with a reset segment as if the
   ^^^
   connection had never existed.  Proceeding in any other fashion risks
   
   misinterpreted SYN data.

I would ideally like to use RFC793 as much as possible as a
"subroutine," because your suggestion of specifying exactly what must be
in the RST segment risks contradicting RFC793.  Hence, my idea that you
can transition to CLOSED and pretend you were closed when you got the
segment.  By maybe I should say "CLOSED or LISTEN" (in keeping with
RFC793), or maybe this is a bad idea for some other reason, so I'd
appreciate some feedback from the list on how best to do this.  Any
feedback helps, but specific wording suggestions are even better...

Thanks,
David

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Wesley Eddy]

On 2/22/2017 1:58 PM, David Mazieres wrote:

Wesley Eddy  writes:


1) edge cases where you're communicating with non-ENO hosts, that do not
discard data on SYNs (for whatever reason), and may pollute the data
stream delivered to the application, breaking the goals of TCPINC to
work without impacting the application's TCP mapping

2) cases where other TCP extensions (perhaps yet to-be-defined) do
something in conflict with that data

Can you make concrete suggestions for wording changes?  In particular,
we intended to address the points you raised with the following language
of section 4.7:

1)

 If a host sends a SYN-only SYN+ENO segment bearing data and
 subsequently receives a SYN-ACK segment without an ENO option,
 that host MUST reset the connection even if the SYN-ACK segment
 does not acknowledge the SYN data...



Saying "reset the connection" is interesting to me, because technically 
there is not yet any connection (there are TCBs at each side, but 
neither has entered ESTABLISHED state).  The reset that's sent should 
probably *not* acknowledge any data that may have been on the SYN-ACK, 
which seems important to state.  That way, if some application's 
transaction erroneously started due to data on the SYN, any response 
piggybacking the SYN-ACK would not be acknowledged, and the RST should 
cause the application transaction to fail.




 To avoid unexpected connection resets, ENO implementations MUST
 disable the use of data in SYN-only segments by default.



In my opinion, it might be better to disable the use of data in SYN-only 
segments unless the peer's ENO capability is already known through some 
means (e.g. TCB cache from prior connections).



___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Joe Touch]

On 2/22/2017 10:58 AM, David Mazieres wrote:
> Wesley Eddy  writes:
>
>> 1) edge cases where you're communicating with non-ENO hosts, that do not 
>> discard data on SYNs (for whatever reason), and may pollute the data 
>> stream delivered to the application, breaking the goals of TCPINC to 
>> work without impacting the application's TCP mapping
>>
>> 2) cases where other TCP extensions (perhaps yet to-be-defined) do 
>> something in conflict with that data
> Can you make concrete suggestions for wording changes?  In particular,
> we intended to address the points you raised with the following language
> of section 4.7:
>
> 1)
>
> If a host sends a SYN-only SYN+ENO segment bearing data and
> subsequently receives a SYN-ACK segment without an ENO option,
> that host MUST reset the connection even if the SYN-ACK segment
> does not acknowledge the SYN data...
>
> To avoid unexpected connection resets, ENO implementations MUST
> disable the use of data in SYN-only segments by default.

It might be useful to explain the rationale briefly.

It might also be useful to explain what happens next. AFAICT, the reset
should just terminate the connection. I.e., a TCP ENO implementation
MUST NOT internally retry a failed ENO connection with a non-ENO
connection (it would break the semantics of of the TCP API to do so with
different source port numbers because the user might have pinned them,
and you can't wait for a retry because that would cause the API to stall
longer than TCP SYN timeouts expect).

> 2)
>
> More specifically, a host that implements ENO MUST discard the
> data in a received SYN+ENO segment if any of the following
> applies:
> ...
> * The SYN segment contains a non-empty TFO option or any other
>   TCP option implying a conflicting definition of SYN data.

MUST discard the data
MUST NOT cache the data, even if not ACKd

And, IMO, SHOULD refuse the connection (the other end is clearly asking
something that could be dangerous and if they don't know better, you
might be better off not trusting that connection to continue)

Joe

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[David Mazieres]

Wesley Eddy  writes:

> 1) edge cases where you're communicating with non-ENO hosts, that do not 
> discard data on SYNs (for whatever reason), and may pollute the data 
> stream delivered to the application, breaking the goals of TCPINC to 
> work without impacting the application's TCP mapping
>
> 2) cases where other TCP extensions (perhaps yet to-be-defined) do 
> something in conflict with that data

Can you make concrete suggestions for wording changes?  In particular,
we intended to address the points you raised with the following language
of section 4.7:

1)

If a host sends a SYN-only SYN+ENO segment bearing data and
subsequently receives a SYN-ACK segment without an ENO option,
that host MUST reset the connection even if the SYN-ACK segment
does not acknowledge the SYN data...

To avoid unexpected connection resets, ENO implementations MUST
disable the use of data in SYN-only segments by default.

2)

More specifically, a host that implements ENO MUST discard the
data in a received SYN+ENO segment if any of the following
applies:
...
* The SYN segment contains a non-empty TFO option or any other
  TCP option implying a conflicting definition of SYN data.

If those aren't clear, the question is how to make them so.

Thanks,
David

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Joe Touch]

> On Feb 15, 2017, at 8:33 PM, Wesley Eddy  wrote:
> 
> I haven't been following the WG discussions closely, so apologize in advance 
> if this has been beat to death ... In reviewing the present draft, section 
> 4.7 seems awkward to me.
> 
> I think the WG should consider taking a position that data-on-SYN for TEPs 
> should only be permitted to be sent if you have some prior indication that 
> ENO is understood by the other end (e.g. via a cache entry from a previous 
> connection, or other means).
> 
FWIW, I don't much care what TCPINC decides, but the decision has 
consequences...
> While the draft correctly says that discarding data on SYNs may already be a 
> common practice, it seems to me that there could be two issues, including:
> 
> 1) edge cases where you're communicating with non-ENO hosts, that do not 
> discard data on SYNs (for whatever reason), and may pollute the data stream 
> delivered to the application, breaking the goals of TCPINC to work without 
> impacting the application's TCP mapping
> 
> 2) cases where other TCP extensions (perhaps yet to-be-defined) do something 
> in conflict with that data
> 
> I think it goes along with being 'conservative in what you send' to only 
> include TEP data on the SYN if ENO is highly likely to be supported by the 
> other side.
> 
I'd prefer to be explicit:

- if non-data info is included in the TCP SYN payload, then this mechanism MUST 
abort SYN-ACKs that do not confirm TCPINC participation (i.e., fallback by 
aborting the current connection), which defeats transparent downgrade to legacy 
listeners.

That rule applies to all TCP extensions, and is discussed in 
draft-touch-tcpm-tcp-syn-ext-opt. 

The potential for other TCP options to have conflicting interpretations for 
that data would need to be dealt with in each such option in the context of 
options defined up to that point, but that seems like an unnecessary swamp to 
enter.

Joe



> 
> 
>> On 1/23/2017 6:15 PM, Kyle Rose wrote:
>> This is a working group last call for the "TCP-ENO: Encryption Negotiation 
>> Option" draft available at 
>> https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/. Please review 
>> the document and send your comments to the list by 2017-February-15.
>> 
>> -Kyle and David
>> 
>> 
>> 
>> ___
>> Tcpinc mailing list
>> Tcpinc@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpinc
> 
> ___
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Holland, Jake]

On 2/4/17, 11:40 AM, "David Mazieres"  wrote:
>   Achieving stronger security with TCP-ENO requires verifying session
>   IDs.  Any application relying on ENO for communications security MUST
>   incorporate session IDs into its endpoint authentication.  By way of
>   example, an authentication mechanism based on keyed digests (such

nit: I think you want an “as” here

>   Digest Access Authentication [RFC7616]) can be extended to include
>   the role and session ID in the input of the keyed digest.

>   Applications MAY use the application-aware "a" bit to negotiate the
>   inclusion of session IDs in authentication even when there is no in-
>   band way to carry out such a negotiation

In this particular sentence (“Applications MAY use the ...”) I would prefer to 
see something like “Higher-layer protocols”, or “Higher-layer authentication 
mechanisms” instead of “Applications”, as the thing which MAY use the ...

The reason is because this negotiation is something that every application 
which connects to the same service has to do in a coherent manner. In other 
words, this is inherently NOT a negotiation that an individual application 
could perform in a different way from another different application that uses 
the same higher layer protocol for communication. Using “Applications” in that 
sentence seems to imply that it’s an application-level negotiation, when in 
fact it’s a higher-layer-protocol negotiation. Using “Applications” might still 
have left some confusion about this point for me on my first reading.

(Also, I still think you’d be better served by changing the name of the a-bit 
from “application-aware” to something like “Legacy protocol updated” or 
“Higher-layer negotiation”, or another phrase that more narrowly describes the 
usage of the a-bit. But outside from this one final mention I won’t quibble 
with your decision.)

Otherwise I’m satisfied with your proposed changes, and thanks again.


___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Scharf, Michael (Nokia - DE)]

[CCing TCPM for the part that matters to TCPM]

> 4. citing drafts in support of future large SYN options:
> “Is there harm in doing this?  E.g., is it bad practice to cite internet
> drafts (non-normatively, of course) in an RFC?”
> 
> 4.a. Citing drafts does go against the current BCP, as I understand it.
> 
> From https://tools.ietf.org/html/rfc2026#section-2.2, in a big star-box:
> “Under no circumstances should an Internet-Draft be referenced by any paper,
> report, or Request-for-Proposal, nor should a vendor claim compliance with an
> Internet-Draft.”
> 
> There’s a partial exception right afterward, which I’m not sure how well it
> applies in this case:
> “
>Note: It is acceptable to reference a standards-track specification
>that may reasonably be expected to be published as an RFC using the
>phrase "Work in Progress" without referencing an Internet-Draft.
>This may also be done in a standards track document itself as long
>as the specification in which the reference is made would stand as a
>complete and understandable document with or without the reference to
>the "Work in Progress".
> “
> 
> 4.b. the moral case for truth in advertising:
> 
> That said, I do think it’s reasonable to make the point that extending SYN
> option space would benefit ENO, and to point to evidence of ongoing work in
> that direction, even if it’s a long shot.
> 
> I also agree that one of the cited drafts is legitimately attempting something
> that would help ENO in this way if it continues to move forward
> (https://tools.ietf.org/html/draft-touch-tcpm-tcp-syn-ext-opt-06). In my
> original comment, one of the 2 alternatives I suggested as an edit was to
> continue to cite that draft, but to point out that it’s experimental.
> 
> However, I think 2 of the citations currently used as evidence are misleading,
> one of them because it shows no signs of moving forward toward any form of
> adoption (https://tools.ietf.org/html/draft-briscoe-tcpm-inspace-mode-tcpbis-
> 00), and the other because it does not apply to SYN or SYN-ACK
> (https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-07), and therefore
> wouldn’t help ENO’s use case. That is why I suggested cutting them out. (Or
> alternatively, if this weakens the point by so much it’s not worth making, to
> cut out the paragraphs that rely on it.)
> 
> My underlying concern here is that someone might take hope from this section
> and try to push their luck by putting keys into the SYN option with a length
> near the lower edge of what’s OK for security, in hopes that by the time it’s
> a real problem they’ll get an extension on the option space, rather than
> wrestling with the likely-harder problem of sending the keys in the payload.
> 
> But in practice, the option space in SYN is likely to be even less than what’s
> pointed out in this draft, because if you leave window-scale, timestamps, and
> sack-permitted out of your SYN, you’re likely to lose more on performance than
> any gains you might have made by getting a key into the SYN.
>
> In my experience, this is exactly the kind of subtle early misunderstanding
> that can lead a team to spend 6+ months developing something, then abort the
> project once they discover it cannot be made both performant enough and secure
> enough under the constraints of an early design decision.
> 
> Therefore, I would prefer this doc not to present a rosier-than-reality
> picture of the likelihood that a future development will make large SYN
> options available.

While TCPM discusses large SYN options (for a long time already), all known 
solutions have downsides. I do not believe that a non-TCPM document should 
speculate on the feasibility solutions.

Michael
 
> To take that a little further, I’d almost rather see an explicit warning that
> provides clear support for a claim like “You cannot fit a cryptographically
> secure key into the SYN option unless and until further standards work makes
> it possible to have more space there. Don’t try, you’ll regret it.”
> 
> It’s kind of a minor point to get this much discussion, but that’s a more
> complete explanation of my objection.
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[David Mazieres]

Okay, here is some proposed language.  For the definition of the "a"
bit:

   a
  Legacy applications can benefit from updating their behavior to
  take advantage of TCP-level encryption, for instance by improving
  endpoint authentication or avoiding double encryption.  The
  application-aware bit "a" is an out-of-band signal that such
  applications can use to indicate support for ENO-specific updates
  when high-layer protocols lack a backwards-compatible means of
  doing so.  Implementations MUST set this bit to 0 by default, and
  SHOULD provide an API through which applications can change the
  value of the bit as well as examine the value of the bit sent by
  the remote host.  Implementations SHOULD furthermore support a
  _mandatory_ application-aware mode in which TCP-ENO is
  automatically disabled if the remote host does not set "a = 1".

For security considerations:

   Achieving stronger security with TCP-ENO requires verifying session
   IDs.  Any application relying on ENO for communications security MUST
   incorporate session IDs into its endpoint authentication.  By way of
   example, an authentication mechanism based on keyed digests (such
   Digest Access Authentication [RFC7616]) can be extended to include
   the role and session ID in the input of the keyed digest.
   Applications MAY use the application-aware "a" bit to negotiate the
   inclusion of session IDs in authentication even when there is no in-
   band way to carry out such a negotiation.  Because there is only one
   "a" bit, however, a protocol extension that specifies use of the "a"
   bit will likely require a built-in versioning or negotiation
   mechanism to accommodate crypto agility and future updates.

Added the third sentence to the first paragraph of 5.1 (Session IDs):

   Each TEP MUST define a session ID that is computable by both
   endpoints and uniquely identifies each encrypted TCP connection.
   Implementations MUST expose the session ID to applications via an API
   extension.  The API extension MUST return an error when no session ID
   is available because ENO has failed to negotiate encryption or
   because no connection is yet established.  Applications that are
   aware of TCP-ENO SHOULD, when practical, authenticate the TCP
   endpoints by incorporating the values of the session ID and TCP-ENO
   role (A or B) into higher-layer authentication mechanisms.

So now it is clear that you can check for an error on the call to
retrieve the session ID (meaning TCP-ENO succeeded if and only if you
get a session ID).

I also got rid of the citations to internet drafts.  Now 7.1 (future
developments) reads:

   Various proposals exist to increase the maximum space for options in
   the TCP header.  Though these proposals are highly experimental--
   particularly those that apply to SYN segments--TCP-layer encryption
   could significantly benefit from the availability of increased SYN
   option space.  In particular, if future TEPs can perform key
   agreement by embedding public keys or Diffie-Hellman parameters
   within suboption data, it will simplify protocols and reduce the
   number of round trips required for connection setup.  With large
   options, the 32-byte limit on length bytes could prove insufficient.
   This draft intentionally aborts TCP-ENO if a length byte is followed
   by an octet in the range 0x00-0x9f.  Any document updating TCP's
   option size limit can also define the format of larger suboptions by
   updating this draft to assign meaning to such currently undefined
   byte sequences.

I also changed manual to explicit, as you suggested.

Thanks,
David

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Holland, Jake]

On 2/3/17, 6:27 PM, "David Mazieres"  wrote:
>"Holland, Jake"  writes:
>> Should my app set the a-bit? I think this version of the ENO draft
>> says yes, because I have altered my behavior in the presence of
>> encrypted TCP (and it wasn’t practical for me to authenticate, so I
>> qualify as an exception for the first SHOULD from 5.1). I publish my
>> app this way, and it’s downloaded by a few hundred folks with
>> accolades about my security-consciousness.
>
>You definitely should not set the "a" bit.  The "a" bit is there if you
>need it, but there is (or should be) no implication that you "SHOULD"
>set it in cases where it is not required.  Header bits are a precious
>resource, so if anything applications SHOULD NOT use the "a" bit if they
>do not need to.

This answer has a big part of the insight I needed, thanks.

>So perhaps the clarification is that you SHOULD avoid using the "a" bit
>unless you absolutely need to, and when you do use it, since there's
>only one "a" bit, you SHOULD slot in a mechanism that has hooks for
>future compatibility.

(UIC = Updated-insight Comment)

UIC #1: Yes, something that conveys the above message effectively would be a 
key edit, I think.

UIC #2: On a related note, I will point to the initial definition for the a-bit 
in section 4.2:
  The application-aware bit "a" is an out-of-band signal indicating
  that the application on the sending host is aware of TCP-ENO and
  has been extended to alter its behavior in the presence of 
  encrypted TCP.  

I think this initial definition doesn’t convey the right semantics for the 
backward-compatibility that you’ve outlined as the primary purpose for this 
bit, and it probably needs to do so. This is the main reason I thought the 
draft said my example app should set the a-bit.

If the a-bit is intended to be used as a mechanism for backward compatibility 
for legacy protocols that didn’t have one built in previously, in order to 
avoid misunderstandings I think you’ll need to make that point in a more 
specific and deliberate explanation of that purpose. Ideally, somewhere there 
will also be good recommendations on how to achieve a smooth transition, and 
probably an applicability paragraph or sub-section that outlines the key 
characteristics of protocols that can derive a benefit.

UIC #3: On another related note, I will also add that I think “application 
aware” is a misnomer for these semantics.

When a higher-level protocol is extended in a way that makes use of this 
feature, the updated protocol specification should define how updated apps must 
behave in order to comply with the updated protocol, and should do so with a 
definition that permits interoperability with the prior version of the protocol.

This is not about any choices an application makes or any awareness that an 
application has, except in the sense that the application risks incompatibility 
if it sets the bit without reference to an updated version of the protocol 
specification that defines semantics for how each side should handle a matched 
a-bit.

So this is perhaps something like a “Legacy protocol upgraded” bit, which 
should be set only when a higher level protocol has been updated by a new 
specification that defines the semantics for how to interpret the bit within 
the new version of that protocol.


I know that’s a lot of wide-ranging edits to propose, and I’m sorry about that. 
But I do think that making this point a lot more clear in the document would 
make a big difference in avoiding confusion.

Thanks for taking the time to understand my objections fully and explain the 
misunderstandings patiently. I think this is a very good doc, and I hope this 
discussion has been helpful in improving it a little further.

- Jake


___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[David Mazieres]

"Holland, Jake"  writes:

> 2.a. A scenario for illustration:
>
> For instance, maybe next year somebody reads about ENO and decides to
> upgrade protocol X, their proprietary gaming application protocol, so
> that Xv2 will be identical except that the passphrase will now be
> HMAC-MD5 of passphrase+sessionID if and only if the remote connection
> sets the a-bit, instead of just the cleartext passphrase. Your example
> exactly, I think.

I guess the problem here is that protocol X might not have a way to
negotiate some new authentication mechanism, so you need some kind of
flag to do this.  The "a" bit solves that problem.  However, as you
point out, the "a" bit is a one-shot mechanism, so whatever behavior
change it triggers should have some crypto agility/negotiation facility.
In the case that you are replacing passwords, I think that's okay,
because an MD5 hash will be 32 hex digits while a SHA-256 one will be
64.  But it would be better to say "md5:XXX" or something for even more
future flexibility.

Would it address your concern if we say that when use of the "a" bit is
required to slot in a new authentication mechanism, the new mechanism
should allow some crypto agility or negotiation mechanism for future
compatibility?

> 2.b. Another different example with a different problem:
>
> Suppose I write an app that talks to servers I don’t own, and my OS
> has the recommended API feature from 4.7 (“implementations MAY provide
> a per-connection mandatory encryption mode that automatically resets a
> connection if ENO fails”), so my app tries one connection with
> mandatory encryption, then on failure with the right error code, I
> retry without encryption and with a reduced feature set of things I’m
> willing to send to the server. However, I don’t have time to implement
> session ID authentication, and the server wouldn’t accept it anyway.

The mandatory encryption mode is not intended to serve a security
function, but rather to enable TEPs to optimize connection setup using
SYN data.  An example use case would be that you are connecting to an
NFS server that you know supports TCP-ENO, so you might as well do the
key agreement right in the SYN exchange if some future TEP supports it.
(We can't allow such an optimization by default because it reduces
backwards compatibility with TCP.)

> Should my app set the a-bit? I think this version of the ENO draft
> says yes, because I have altered my behavior in the presence of
> encrypted TCP (and it wasn’t practical for me to authenticate, so I
> qualify as an exception for the first SHOULD from 5.1). I publish my
> app this way, and it’s downloaded by a few hundred folks with
> accolades about my security-consciousness.

You definitely should not set the "a" bit.  The "a" bit is there if you
need it, but there is (or should be) no implication that you "SHOULD"
set it in cases where it is not required.  Header bits are a precious
resource, so if anything applications SHOULD NOT use the "a" bit if they
do not need to.

So perhaps the clarification is that you SHOULD avoid using the "a" bit
unless you absolutely need to, and when you do use it, since there's
only one "a" bit, you SHOULD slot in a mechanism that has hooks for
future compatibility.

> 2.c. a-bit summary
>
> I think it’s likely I’m missing something, and I’m hoping that a real
> life example and a use case walk-through of a scenario where it’s
> expected to help (and maybe also an explanation of how the scenarios
> like the above 2 are avoided under a correct reading of the draft)
> will help clear things up.

I guess a real-life example might be a kerberos protocol that protects
data with DES encryption and a weak MAC.  You could specify that, when
both sides set the "a" bit, two things happen:

1) the endpoints omit the DES encryption and weak MAC (which are
   superseded by TEP encryption), and

2) the authenticator format is altered to replace the subkey
   field (that, in the absence of TCP-ENO, specifies a key with
   which to encrypt session data) with the TCP-ENO session ID to
   prevent man-in-the-middle attacks.

Obviously this is just an example, and the decision on the exact
interpretation would fall to whoever on the kerberos team is extending
the kerberos protocol.  I'm sure it would involve lots of trade-offs I'm
not thinking of.  But the point is that this is the kind of thing people
might want to do, and they need an extra bit in order to do it.

I don't want to put such a concrete example in the ENO RFC, because we
would be stepping on the toes of the RFC4120 authors.  The point of the
"a" bit is to give people options.  There are scenarios where the "a"
bit can be put to good use.  There are scenarios where the "a" bit is
not needed.  And there are scenarios in which the "a" bit can
effectively be wasted on some trivial feature, leaving people later to
regret that they can't use it for something more important.  

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Holland, Jake]

Hi David,

Thanks for the response.

I’ll try to give a deeper explanation on what I’m thinking on points #2 and #4 
(“a-bit” and the draft-citing), and see if it leads to any further clarity or 
easier consensus.

Sorry for the length, and please don’t feel a need to respond to each 
individual part of this message. This is meant to give a coherent picture of 
the thinking and assumptions behind my objections, in hopes that you can more 
easily narrow in on examples that will best help to clear up any mismatches.


2. a-bit use cases/flag day avoidance:

I’m struggling to think of an example protocol that would need the a-bit to 
implement this kind of incremental increase in security.

The examples I’ve considered that run over TCP all do a feature (or version) 
negotiation in a handshake of some sort, then settle on a set of options that 
both sides understand, specifically so they can avoid flag days when making 
future upgrades.

In protocols that follow that practice, I’d expect that if they upgraded to add 
functionality for using the ENO session ID during authentication, the new 
protocol extension would add a new field type with a very specific meaning, 
probably with more than 1 bit of information (including for example which 
specific hash to use).

I’m also trying to think about the consequences if the protocol X in your 
example made such an extension by relying on the a-bit, and I keep running into 
reasons for concern.

2.a. A scenario for illustration:

For instance, maybe next year somebody reads about ENO and decides to upgrade 
protocol X, their proprietary gaming application protocol, so that Xv2 will be 
identical except that the passphrase will now be HMAC-MD5 of 
passphrase+sessionID if and only if the remote connection sets the a-bit, 
instead of just the cleartext passphrase. Your example exactly, I think.

They roll out the upgrade and tell their boss that even though many kinds of 
upgrades are impossible for them without a flag day, this one is safe and will 
secure their communications, so now they can finally transmit credit card info 
to their servers from clients that are running on an encryption-capable network 
stack. They run it that way for a few months, then a new attack on MD5 is 
discovered, and they realize it really should have been SHA-256 these days. 
Under the same logic that argues protocol X needs the a-bit, would the z1 bit 
in ENO be assigned for a second level of backward compatibility so that 
protocol Xv3 can distinguish between the SHA-256 and the MD5 hashes? I assume 
not, but this is part of why I’m struggling.

This example didn’t seem very compelling to me, so I was hoping that access to 
a real life example that needs the a-bit for this kind of backward 
compatibility would make it easier for me to follow the intended usage.

2.b. Another different example with a different problem:

Suppose I write an app that talks to servers I don’t own, and my OS has the 
recommended API feature from 4.7 (“implementations MAY provide a per-connection 
mandatory encryption mode that automatically resets a connection if ENO 
fails”), so my app tries one connection with mandatory encryption, then on 
failure with the right error code, I retry without encryption and with a 
reduced feature set of things I’m willing to send to the server. However, I 
don’t have time to implement session ID authentication, and the server wouldn’t 
accept it anyway.

Should my app set the a-bit? I think this version of the ENO draft says yes, 
because I have altered my behavior in the presence of encrypted TCP (and it 
wasn’t practical for me to authenticate, so I qualify as an exception for the 
first SHOULD from 5.1). I publish my app this way, and it’s downloaded by a few 
hundred folks with accolades about my security-consciousness.

However, a few years later the owners of the server side read section 9’s 
“applications MAY use the application-aware bit to negotiate the inclusion of 
session IDs in authentication”, and they roll out a new version that uses this 
by folding in new semantics for the authentication field, plus a blog post 
about the new meaning of application-awareness and how to upgrade to a new 
version of someone else’s more-popular app that incorporates these 
authentication semantics, and explains what the authentication using session 
IDs now look like.

Now my app’s authentication has a different meaning from the server’s and I 
start getting rejected on authentication until I can roll out an emergency 
upgrade, because I’m setting the a-bit but I wasn’t coordinated with the 
server’s upgrade.

In this scenario, I think the a-bit hasn’t avoided the flag day, and the reason 
is because of semantic confusion over the proper use of the a-bit, but 
everybody followed the rules as laid out in this draft.

Therefore, there must be some problem either with my understanding of what’s 
allowed or with the rules in the draft.

2.c. a-bit summary

I think it’s likely I’m 

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Holland, Jake]

Hello tcpinc members,

I’m new to the group, and joined at Kyle and David’s invitation to give a 
review of this draft before the WGLC expires:
"TCP-ENO: Encryption Negotiation Option"
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/


The doc mostly looks pretty good to me. I couldn’t find anything that would 
make it impossible to transport data and opportunistically encrypt it with ENO 
where available, nor anything inherently dangerous for an app that doesn’t use 
any ENO-specific API extensions, but which is running on a network stack that 
silently turns on ENO underneath.

A few suggestions that I think might improve the doc:

1. There should be a MUST for an API that an application can use to discover 
whether a connection ended up encrypted, unless it’s there and I missed it. I 
couldn’t find one in the doc, but it seems a likely vital point for anything 
that satisfies the application-aware definition.

2. I’d like to see a section that lists a use case or 2 that can be solved by 
knowing the remote host’s a-bit (or with the mandatory application-aware mode), 
and how the a-bit solves them. I assume I’m missing something obvious, but I 
haven’t been able to come up with a use case that does anything useful with the 
remote a-bit.
(An example guess: is the whole point so that you can avoid sending sensitive 
data if the remote app itself hasn’t done anything to become secure? And if so, 
is there some reason the application-layer protocol shouldn’t be in charge of 
determining that?)

3. All 3 instances of “manual(ly)” in the doc seem better if changed to 
“explicit(ly)” (sections 4.2 and 7.4)

4. In section 7.1, the hopes of increasing TCP’s SYN option space seem 
exaggerated. EDO does not apply to SYN, and of the other 2 cited drafts, one is 
expired over a year ago and the other looks, I guess I’d call it "tricky", in 
addition to being experimental. It might be better to remove the second and 
third paragraphs of section 7.1, or at least reduce to just the one example of 
a live and applicable draft (and maybe noting that it’s experimental).

I hope that helps.

- Jake


___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc