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
_
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 fi
"Holland, Jake" writes:
> A few suggestions that I think might improve the doc:
Thanks for going through the document.
> 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 o
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 pa
"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 passphras
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 exc
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
appli
[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 under
"Scharf, Michael (Nokia - DE)" writes:
> 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, what do you think of the new proposed wording?
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 mec
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
> 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
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
>
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
>> w
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 impact
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...
>
>
>
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
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
FWIW, you might add "and not attempt to open the connection with
different parameters (e.g., the same socket pair with ENO off, a
different socket pair with ENO off)."
The former is not safe and the latter changes the semantics of the TCP
API incorrectly.
Joe
On 3/7/2017 10:38 PM, David Maziere
19 matches
Mail list logo
