Eric Rescorla writes:
> On Sun, Nov 4, 2018 at 5:29 AM David Mazieres <
> dm-list-tcpcr...@scs.stanford.edu> wrote:
>
>> I've posted a new draft in the usual place:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/
>>
>
I've posted a new draft in the usual place:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/
Please let us know if the diffs satisfy your concerns:
https://www.ietf.org/rfcdiff?url1=draft-ietf-tcpinc-tcpcrypt-13&url2=draft-ietf-tcpinc-tcpcrypt-14&difftype=--html
Tha
Eric Rescorla writes:
>When a frame is received, tcpcrypt reconstructs the associated data
>and frame ID values (the former contains only data sent in the clear,
>and the latter is implicit in the TCP stream), computes the nonce "N"
>as above, and provides these and the ciphertext
I've posted what I hope is a final draft of the tcpcrypt spec, at the
usual place:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/
The main open issue was the length of the resumption nonce, and the
concern that recommending 4 bytes was not a good length, so we have
increased
Eric Rescorla writes:
> This is looking good. A few small comments:
Thanks. I just uploaded draft 17, which should address all these
comments. The changes are small, so the easiest way to check this is
probably the following "word diff" link:
https://www.ietf.org/rfcdiff?url1=draft-ietf-tcpin
Amanda Baber writes:
> I guess if we want expert review for non-IETF stream docs it actually
> would be „IETF Review or RFC Required with Expert Review“… Amanda,
> does that still makes sense to you?
>
> [AB] That works for us too. I think that in that case we would call it
> “IETF Review or Expe
Amanda Baber writes:
> Hi David,
>
> See [AB] below for a note about registration procedures.
Okay, thanks. Here is my new proposed language for the end of IANA
considerations. This also reflects a change to address Benoit Claise's
concern that 95 TEP identifiers could prove too few.
Thi
Eric Rescorla writes:
> To be honest, I think this document is working too hard in both cases to
> try to legislate that people don't do things that we think are bad. The
> bottom
> line is that in both cases the boundaries around what we think is OK and
> what we think is not are kind of fuzzy (
"Black, David" writes:
> This is entirely editorial about word choice - "permit the
> negotiation" sounds like a runtime requirement to me, whereas this
> section is entirely design requirements. Using "support" instead of
> "permit the negotiation of" is among the ways to make this clearer,
> I
"Black, David" writes:
> I found something useful, as it turns out that I’ve seen this before in
> dealing w/another draft …
>o TEPs MUST NOT permit the negotiation of any encryption algorithms
> with significantly less than 128-bit security.
> To begin with, “permit the negotiation”
David Mazieres expires 2018-02-10 PST
writes:
>> The problem is that "govern" is not very clear. It's clearer to link the
>> requirement
>> here to the specific feature of the packet.
>
> Okay, let me futz with the language a bit and try to get rid of or
Eric Rescorla writes:
>> >connection or when there is any ambiguity over the meaning of the SYN
>> >data. This requirement applies to hosts that implement ENO even when
>> >ENO has been disabled by configuration. However, note that
>> > I think you may mean to say "when the last SYN
Hi, Eric. Thanks for your review. Let me go through the discuss
points, but then below I have just a couple of questions about your
feedback. Most of your points I was able to address straight-forwardly.
Eric Rescorla writes:
> -
Kathleen Moriarty writes:
> Thanks for your work on this draft and experiment. I just have one
> comment that I don't think has been mentioned already. In section 4,
> could you include reference to Opportunistic security, RFC7435. The
> definition has changed slightly over time and it would be
Adam Roach writes:
> --
> COMMENT:
> --
>
> Thanks for a well-thought-out and well written document. I'm looking
> forward to seeing how this experiment goes. I
Min Ye writes:
> I have some minor concerns about this document that I think should be
> resolved before it is submitted to the IESG.
>
> Comments:
>
> - May be the document can document if there is any modification for
> what concerns closing of connections (in its current version the
> document
Spencer Dawkins writes:
> --
> COMMENT:
> --
>
> This draft was fairly easy for me to follow. I do have some questions, of
> course, but I'm a Yes.
Thanks for t
iang writes:
> In general +1.
>
> The only quibble I would have is that 2. Curve448 should be a MAY.
> Firstly, a caveated SHOULD becomes a MAY, at some level of
> approximation. Secondly, if we manage to convince an enemy to crunch
> Curve25519 then we have won a great victory, and we can up
Rene Struik writes:
> Hi David:
>
> This should be okay as long as people are painfully aware that
> implementations should take algorithm agility into account [1]. In
> particular, no complaining about vested interests down the road, in case
> a suite change should be required. The protocol s
We are considering the following proposal for MTI key exchange protocols
in tcpcrypt:
1. Implementations MUST support Curve25519.
2. Implementations SHOULD support Curve448 to the extent that suitable
implementations are available.
3. Implementations MAY support P256 and P521 (particu
There's a new TCP-ENO draft in the usual place:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/
This draft addresses last call comments we received. Other than some
typos, the main changes are to update the requirements language (section
1) to use RFC8174 and to add a new sect
Watson Ladd writes:
> Dear all,
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG ch
Some of the tcpcrypt authors have talked over the proposal to make
ECDHE-Curve25519 MTI instead of P256 and P521. We think this argment
has merit if it won't hamper standardization and adoption of the
protocol at this juncture.
One of the original motivations for making P256 MTI was that if P256
"Mirja Kuehlewind (IETF)" writes:
> Yes, it’s better. It doesn't redefines what to do with the FIN, so
> that’s good. For the first sentence it now sounds like this is
> independent of the FIN in the regular TCP. Is there a reason why you
> don’t want to go for a phrasing as I proposed where you
"Mirja Kuehlewind (IETF)" writes:
> This is what early allocation is for. We could have also asked for
> early allocation for tcpinc as soon as the spec was reasonably stable
> but given there was no-one who was actually about to deploy this in
> the Internet, it was probably not necessary.
Is t
Kyle Rose writes:
> Does it make sense to allocate a few TEP IDs (e.g., 0x7c-0x7f) as explicit
> "for testing purposes: not for production use" IDs that implementors can
> use in testing? Another alternative is an explicit ExID-like mechanism, but
> that seems far too heavy-weight for something l
"Mirja Kuehlewind (IETF)" writes:
> I’m afraid we need a new revision before IETF Last Call because the
> RFC should only specify the actually TCP option and not the
> experimental one. So you can simply remove the experimental one in
> Figure 1, 2 and 3 (as well as sec 4.8) and only note in the
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
>
"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?
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
"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
"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
There is a new draft of TCP-ENO, here:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/
There are very few changes from the previous draft, and most of them are
just cosmetic improvements or clarifications. At the last meeting,
there was some discussion about whether the draft
We just posted a new TCP-ENO draft in the usual place:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/
We tried to reflect all of the discussion so far. In particular, a
bunch of SHOULDs are now MUSTs, and the remaining ones are coupled with
a clearer exception. If you don't
Joe Touch writes:
> The point of the API is to indicate how the layer above TCP interacts
> with TCP.
>
>> An
>> embedded single-purpose network device might not be implemented in terms
>> of sockets or anything else, but rather might have the device
>> functionality completely intermingled with
Joe Touch writes:
>> * Many of the uses concern APIs that implementations SHOULD provide.
>> The reason for the SHOULD is that in some cases this may be impossible
>> or inapplicable. For example, if you are implementing TCP-ENO inside
>> a dedicated NAS server, there might not be the same
"Black, David" writes:
> Hi David,
>
> This looks good, although I think this "SHOULD" requirement ought to be a
> "MUST":
>
>> >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 SHOULD reset t
Okay, guys. Thanks for the feedback. Here's yet another attempt at
revamping the section. I made sure each SHOULD is followed by an
exception. Note I made one other change, which is to allow SYN-form ENO
options with no suboptions. Before that didn't make sense, but now it
does as a way of say
Oops, I failed to notice that you had in-line comments as well. Please
read this instead of the previous version.
Sorry,
David
4.7. Data in SYN segments
TEPs MAY specify the use of data in SYN segments so as to reduce the
number of round trips required for connection setup. The meaning
Okay, guys. This is getting long and feels a bit pedantic, but how
about the following?
David
4.7. Data in SYN segments
A SYN segment containing an ENO option MUST NOT include a TCP Fast
Open (TFO) option [RFC7413]. However, TEPs MAY specify the use of
data in SYN segments to achiev
Joe Touch writes:
>> On Jul 30, 2016, at 10:20 AM, David Mazieres
>> wrote:
>>
>> And mandating no
>> buffering of discarded SYN data is a good way to do that...
>
> You can do that for ENO, but you cannot assert requirements for legacy
> stacks.
>
Jeremy Harris writes:
> On 29/07/16 20:41, Kyle Rose wrote:
>> Right, I get that for interoperability with ENO-unaware stacks there is no
>> way to change data presented in the SYN. In the case where both ends
>> understand ENO but the server is not negotiating it, we can define TCP SYN
>> payloa
Joe Touch writes:
> Fair enough, but then you really need to re-implement the bulk of what
> TFO does if you intend to act on previous state as if it were known for
> future connections.
Yes, except the reimplementation may turn out to be simplified by the
fact that A) TEPs have a cryptographica
Joe Touch writes:
> Hi, all,
>
> I'm very confused by the new SYN data text.
>
> First, if you really want state based on previous connections that
> allows early use of SYN data before the 3WHS, that seems to be the very
> definition of TFO. So declaring that this solution is valid only where
>
Joe Touch writes:
> FWIW, IMO the best wording would:
>
> - start with the simplest case, i.e., NOT trying to optimize EDO to use
> SYN data
>
> - present the use of SYN data with EDO as an optimization
> that optimization might be a MAY or SHOULD, but not a MUST
>
> Otherwise, you're nee
How about the following wording?
A SYN segment containing an ENO option MUST NOT include a TCP Fast
Open (TFO) option [RFC7413]. However, TEPs MAY specify the use of
data in SYN segments to achieve similar benefits to TFO.
The last TEP identifier suboption in host A's SYN segment is
Joe Touch writes:
> On 7/24/2016 4:45 PM, Kyle Rose wrote:
>> In the absence of a TFO cookie, what is the behavior of TCP in the
>> presence of data in the SYN packet? The ability of ENO to send early
>> data on session resumption to servers that potentially don't
>> understand ENO depends on the
Kyle Rose writes:
> do we need some explicit signaling from the server on a prior
> connection for when SYN data on resumption attempts is okay, or is
> "...but SHOULD limit such usage..." good enough?
This is precisely the question on which some input from more experienced
members of the workin
Kyle Rose writes:
> This is really good information: thanks! I think if tcpinc decides to
> pursue early data, we'll want to learn as much as possible from your
> experience.
So just to scope what we had in mind, "pursue early data" sounds a bit
aggressive. What I think we had in mind is just s
Watson Ladd writes:
> Dear all,
> Originally negotiation was proposed because EKR wanted to use TLS.
> That has now ended, but we are retaining the negotiation layer with
> far more generality then required. I'm not sure why that is.
> Sincerely,
> Watson
As already noted by Yoav, TLS is just su
We've incorporated most of the recent feedback from the last TCP-ENO
draft a few days ago and uploaded a new draft:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/
Specifically, this contains a first attempt at a reasonable IANA
considerations section (though I'm sure we'll get
Joe Touch writes:
> On 7/1/2016 11:20 PM, David Mazieres wrote:
>> So from my limited experience, it seems like one is supposed to ask IANA
>> for a specific number to which they reply yes or no, rather than asking
>> them to choose the number.
> You can (but aren't
Kyle Rose writes:
> This is a review of the latest TCP-ENO draft (02). I am acting as member,
> not chair.
Hi, Kyle. Thanks for the review. We've addressed most of your
comments, so I'll append a diff. Since we are probably going to upload
another draft when we get Jana's review, plus we have
We've just posted the latest revision of TCP-ENO here:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/
It makes the following changes to the wire protocol:
* Reflects the new ExID we have been allocated, and specifies
implementations MUST NOT use the old option kind 69 unles
"Black, David" writes:
> I'm likely to be the shepherd for this draft (but if anyone else is
> interested, please email the WG chairs - tcpinc-cha...@ietf.org).
Thanks for the feedback. We're about to release a new draft of TCP-ENO.
I'll try to incorporate some of your feedback, but want to get
"Scharf, Michael (Nokia - DE)" writes:
>> But more to the point, what is your concrete proposal?
>
> 1. Get an ExId from IANA. I think filling out
> http://www.iana.org/form/protocol-assignment can be done in 5min. This
> can be done by anybody interested in experimenting with TCP options,
> bec
"Scharf, Michael (Nokia - DE)" writes:
> 1. Get an ExId from IANA. I think filling out
> http://www.iana.org/form/protocol-assignment can be done in 5min. This
> can be done by anybody interested in experimenting with TCP options,
> because it is clear that there is a need to experiment with TCP
Christoph Paasch writes:
> Hello,
>
> I have read through the TCP-ENO draft and have a few comments:
>
>
> First, am wondering whether there might be an issue when the third ACK
> gets lost.
>
> Specifically, the draft says that a host MUST disable ENO if the
> following condition is met:
>
>
Joe Touch writes:
>> In the absence of working group consensus, we decided to maintain the
>> status quo and keep squatting. Since IANA tacitly acknowledges and
>> documents option squatting,
>
> Got an RFC for that? IANA recognizes that it happens but it's not
> endorsed and not typically con
"Scharf, Michael (Nokia - DE)" writes:
>> First, I'm fine with not further discussing as you suggest. However,
>> IANA does assign TCP option kinds to experimental RFCs (e.g.,
>> RFC6824, with option kind 30 for multipath TCP, and I hope one day
>> TCP-ENO as well). So I hope it's not completel
"Scharf, Michael (Nokia - DE)" writes:
>> Another approach here would be to make it easy for other RFC authors to
>> leverage tcpcrypt to protect the privacy of there options. For any
>> options that are tied to data, moving them in-band to special TLV
>> frames
>> might make the most sense.
>
>
Mirja Kühlewind writes:
> To my understanding the reason to not encrypt the header was that some of the
> header information is need to pass middleboxes, such as for sure the ports
> but also some of the flags and maybe even the seq#. However, I think options
> or at least some of the options
Joe Touch writes:
> Hi, all,
>
> TCPINC decided not to include any protection for the TCP header.
>
> TCP options are part of the TCP header.
>
> Sorry, but I have absolutely no idea why they would be asking now for a
> way to protect part of the TCP header when they've already so clearly
> decid
Mirja Kühlewind writes:
> Hi all,
>
> I briefly brought this up in the last meeting and would like to start
> the discussion on the mailing list now. The working group decided that
> tcpinc will not encrypt the TCP header for good reasons. However, it
> would still be possible to encrypt TCP opti
"Scharf, Michael (Nokia - DE)" writes:
> Has the WG discussed the applicability of
> https://www.ietf.org/iesg/statement/writable-mib-module.html to
> Section 2.2?
>
> I know that this question may be a bit unusal for TSV area and even
> more unusal for this specific use case ;-)
>
> Also, it may
Yoav Nir writes:
> It’s been discussed extensively on the IETF and attendees lists.
>
> The requirement has been lifted on March 24th. People who have already
> paid will not get their money back, but the airlines should not
> require proof anymore.
Thanks. Sorry to have hijacked the tcpinc li
Hi, everybody. I know this is the wrong forum for this discussion, but
it's the widest distribution list of interested parties to which I have
access. The IETF 95 web site suggests that people traveling on US
passports must pay a reciprocity fee before leaving for Argentina. I
was about to pay t
Yoav Nir writes:
> I’ve reviewed version -01 of the TCP-ENO draft. In general I find it
> understandable enough that I could implement it from the spec.
Thanks for the detailed feedback. Comments and clarifications in line.
For some of these points, I think improvements to the draft are obvious
David Mazieres writes:
> * The discussion of STUN-like path-checking servers has been split off
>into a separate "best current practices" document (which will be
>uploaded as soon as the API reference updates on xml2rfc).
Just to follow up, the document is h
We've uploaded a new informational draft for the TCP-ENO proposed
interface extensions. This draft incorporates the feedback we received
at the last meeting and afterwards. Specifically:
* There is now a separate default setting for active and passive
connections.
* There are new socket op
Hi, everyone. We have just uploaded a new draft of TCP-ENO. Sorry for
the delay. The new draft incorporates the feedback from the last IETF
meeting and the mailing list. Here is a summary of the changes:
* A SYN segment can now contain at most one TCP-ENO option, because
order matters an
"Black, David" writes:
> Reminder: The expert reviews should be starting soon.
>
> Would the draft authors please reply to the list on when the next version
> of each draft will be posted, or in the alternative to say that the current
> version of the draft is stable and suitable for external exp
Bryan A Ford writes:
> On 11/19/15 11:46 PM, David Mazieres wrote:
>> C5. Leave it to individual encryption specs to make TCP-SO work
>> automatically. For DH-based specs, there may be an easy trick.
>> However, for public-key-based specs--such as those relying o
Bryan A Ford writes:
> I never saw any response to my Nov 6 E-mail on "specific ways to evolve
> the TCP-ENO spec". I would especially like to hear any of the spec's
> authors address these particular concerns at the end of the E-mail,
> especially the first, which seems like a potentially signi
Yuchung Cheng writes:
> For C2, does that requires "every" TCPINC application to specify its
> roles SO or not? i.e., both sides need to setsockopt("I am [AB]")?
If you are using simultaneous open, exactly one side must specify that
it wants the B role, which requires sending a general suboption
"Black, David" writes:
>> I'm definitely in favor of polling the working group about TCP-SO, but
>> I'd like to suggest that we make the question much more precise. As it
>> stands I don't really know what "support" means in this context.
>
> Really? The above summary up to the point of plug-pu
"Black, David" writes:
> TCP-SO is detectable at runtime - SYN sent followed by SYN received
> for the same connection causes a TCP connection state machine
> transition that is unique to TCP simultaneous open. More background
> on TCP-SO (and its interaction with NATs) can be found in sections
Kyle Rose writes:
> What exactly is the issue here? You mentioned a client being tricked
> into thinking it has connected to itself, but I think I need you to
> spell out the worry here. In my earlier post, I was thinking it was
> sufficient for an application to know it is (at least) one end of
Bryan Ford writes:
> At any rate, to reiterate, having multiple TCP-ENO options floating
> around in one TCP header and expecting different implementations to do
> something sensibly consistent with them sounds terrifying, especially
> when the common - and thus only well-tested - case will almos
Bryan Ford writes:
>> And where did A get B's public key? By that point an asymmetric
>> protocol would probably have allowed B to send data. Besides, why pay
>> the price of two RSA decryptions when you only need one?
>
> A sends it to B in its INIT message (and vice versa).
>
> And yes, it co
Bryan Ford writes:
> There are two simple ways of handling authentication, in this
> scenario, depending on whether and how much you care about
> distinguishing “which endpoint is which” in the process.
Exactly. The fact that applications currently have to chose between
multiple ways of doing t
Wednesday, Tero brought up the prospect of middleboxes reordering
back-to-back unknown options. This would currently mess up the ENO
transcript. Obviously middleboxes can process and manipulate options
they know about. The question is whether anyone has knowledge of a
middlebox that would flip t
Kyle Rose writes:
>> Having two session IDs could also make things a lot more
>> complicated for applications.
>
> I don't know that there's any particular reason to have unidirectional
> SIDs, only a way to construct a single SID in a way that does not
> depend on designating either end of the c
Bryan Ford writes:
> So again, it feels to me like this all would strictly simplify the
> protocol, make it more consistent with TCP’s symmetric design style,
> and would make TCP simultaneous open “just work” with no extra
> tie-breaking complexity or attendant risks of fail-open. Is there an
>
"Black, David" writes:
> Lars,
>
> Mirja explained the path forward in this case in the adoption calls
> for both drafts:
Suppose we go down path 3, namely to publish both approaches as
different versions of tcpinc. Is it required that both be published
simultaneously? If we can just publish e
Kyle Rose writes:
> If a client opens two connections to a previously-known server in a short
> period of time, what is the intended behavior of implementations?
The keys are derived in such a way that you can precompute serveral
session IDs and associated keys without harming privacy. So you c
Matt Corallo writes:
> Am I incorrect in reading that both tls-option and tcpcrypt require a
> full three-way-handshake, and then the client is unable to send data for
> another round-trip as it must wait for another response from the server
> before session keys have been agreed upon?
In tcpcry
Yuchung Cheng writes:
> Section 2: tcp-crypt avoid unnecessary round trips. not clear which
> RTTs it saves?
I guess this is compared to other hypothetical designs that maybe incur
an additional round trip to negotiate a public key algorithm or that
don't support session caching. Admittedly thi
Joe Touch writes:
>> However, the fact that TCPINC does not protect headers does not mean
>> that TCP-ENO cannot be used to negotiate protocols other than TCPINC
>> that do protect the header.
>
> TCP-ENO can't protect the SYN headers except if there are already
> protections in place (ala TCP-AO
Joe Touch writes:
>> AO is an authentication option rather than an encryption spec.
>> AO-encrypt in ENC-BTNS mode probably doesn't meet the security
>> requirements of ENO (the 16-byte ECDH limit could be problematic at a
>> time when even 32-byte curves are starting to be deprecated, at least
>
Joe Touch writes:
> This appears to presume that tcp-eno is used only to negotiate tcptls.
>
> Given tcp-eno cannot be used for TCP-AO, what's the point of having a
> protocol to negotiate only one of three security mechanisms?
What are the three? I think Mirja's proposal is that TCP-ENO could
Eric Rescorla writes:
>> The libc implementation won't work with unmodified applications, because
>> it will break when sharing/passing/inheriting file descriptors across
>> processes, a common pattern for Unix servers.
>>
>
> Hmm... I've seen designs where this should work, for instance where
>
Eric Rescorla writes:
> I don't think this follows at all. The charter doesn't say anything
> about kernel implementations. It says "The protocol must be usable by
> unmodified applications"...
> Another concrete scenario (which is attractive for a TLS
> implementation) is to use a minimal kerne
Eric Rescorla writes:
> My sense is that this is over-design and it would be better just for
> A to send a list and B to pick out of the list. I'm not very compelled by
> the "static option" reason. That's certainly not something I am excited
> about, and I tend to think it would be easier to hav
Unsurprisingly, I support adoption of draft-bittau-tcpinc-tcpcrypt-04.
Tcpcrypt is simple, relatively self-contained, and custom tailored to
the goals of the TCPINC working group. It has no external dependencies
that could block progress. Tcpcrypt is also well suited for
implementation in TCP st
Eric Rescorla writes:
> I wonder if the WG needs to have some non-normative discussion about
> ways to bootstrap up from unauthenticated modes to authentication.
I think the informational API document should include examples of this.
We made a preliminary stab at it here:
https://datatr
This is my review of draft-rescorla-tcpinc-tls-option-04.txt.
Circumstances were such that I had to print it out and review it on
paper. Given the tight dependency on TLS1.3, this means my review is
light on the question of integration with TLS, and more geared towards
interaction with sockets and
"Scharf, Michael (Michael)" writes:
> I have read draft-bittau-tcpinc-tcpeno-02, given that the topic seems
> related to other TCP modifications. Below are a couple of comments;
> some could be more major than others. Disclaimer: I don't have much
> cycles to look into tcpinc, i.e., I apologize i
Mirja Kühlewind writes:
> Hi all,
>
> I'd like to start a call to ask for adoption as working group document of
>
> draft-bittau-tcpinc-tcpeno-02.
Not surprisingly, I support adoption of the document.
David
___
Tcpinc mailing list
Tcpinc@ietf.o
Eric Rescorla writes:
> On Wed, Aug 26, 2015 at 10:28 PM, David Mazieres <
>> Can you demonstrate simultaneous open without stable NAT bindings? I
>> don't see how that could work.
>
>
> The issue is how stable they are over time. My point is that you need
>
1 - 100 of 167 matches
Mail list logo
