On Tue 2017-02-28 17:42:08 -0800, dm-list-tcpcr...@scs.stanford.edu wrote:
> I'm incredibly sad to report that Andrea Bittau died in a motorcycle
> accident on Saturday.
I'm really sorry to hear this. I always enjoyed my interactions with
Andrea, both in conversation and in exchange of code. He
On Mon 2016-07-25 07:29:23 -0400, Kyle Rose wrote:
> Here is a list of questions posed at the Berlin session, along with the
> rough consensus established among those in the room. Please respond to each
> by number if you were not in attendance and have an opinion, especially if
> that differs from
On Tue 2015-09-15 04:43:07 -0400, Mirja Kühlewind wrote:
> I'd like to start a call to ask for adoption as working group document of
>
> draft-bittau-tcpinc-tcpeno-02.
I support this draft's adoption by the tcpinc working group.
--dkg
signature.asc
Description: PGP signature
__
On Thu 2015-08-13 17:05:38 -0400, Kyle Rose wrote:
> This can't be the case if, for instance, the session IDs are signed in
> batches as proposed in the tcpcrypt paper.
You seem to be assuming that peer authentication will happen by an
cryptographic public-key signature over the session id. In th
On Wed 2015-08-12 20:08:28 -0400, David Mazieres wrote:
> Kyle Rose writes:
>> 4.1: Do you want to add the additional requirement that session IDs be
>> public, i.e., not be secret to endpoints/applications?
>
> This was the intent of the following bullet in section 4.1:
>
>o The session ID M
On Sun 2015-08-02 14:52:18 -0400, Eric Rescorla wrote:
> - ECDH_anon with P256 and Curve25519
> - AES_128_GCM; AES_256_GCM; ChaCha/Poly1305
> - SHA256 for the PRF
> - Session hash
> - No renegotiation [Banned in TLS 1.3]
> - No compression [Banned in TLS 1.3]
> - RFC5705 tickets [or PSK in 1.3]
Th
On Thu 2015-07-30 18:26:03 -0400, David Mazieres wrote:
> The new draft, called draft-bittau-tcpinc-tcpeno-00 (TCP-ENO), is
> available at the following URL:
>
> https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpeno/
I like this proposal and i think it should be adopted by the WG. I
On Tue 2015-03-31 10:02:38 -0400, Eric Rescorla wrote:
> On Tue, Mar 31, 2015 at 7:01 AM, Eric Rescorla wrote:
>> Either that or (my preference) specify an AEAD (combined encryption
>> and integrity) algorithm such as AES-GCM or ChaCha/Poly1305.
>> It's always hard to read community consensus, but
On 07/31/2014 06:28 PM, Yoshifumi Nishida wrote:
> My naive question here is do we really need to distinguish header and
> payload when we apply protections?
> I mean, if there's no significant overhead differences, why bother
> checking the boundary between header and payload, or checking TCP
> f
On 07/30/2014 02:50 PM, David Mazieres wrote:
> Daniel Kahn Gillmor writes:
>
>> I like this analysis. Is there any reason we can't apply it to the
>> items in category 2 as well as RST?
>
> The reason it applies to RST only and not other data is that any
> aut
On 07/30/2014 01:15 PM, Kevin Glavin wrote:
> The linked document [1] provides data around the deployment of middleboxes
> in enterprise networks. Its does not provide a complete picture of the
> internet at large but for a population of tcp users both inside the
> enterprise and originating insid
On 07/30/2014 01:55 PM, David Mazieres wrote:
> The good news is that whether or not to require RST protection is a
> purely local decision made by the recipient. Senders should always
> protect RST bits when possible, and obviously not protect them when not
> possible. The best solution (modulo
On 07/30/2014 01:39 PM, Martin Thomson wrote:
> I see two potential failure paths here: in one, hosts adaptively
> respond to damage by reducing what is protected. That is in line with
> the opportunistic nature of the mechanism, but it allows an attacker
> to erode any optional protections.
What
On 07/29/2014 05:13 PM, Bodo Moeller wrote:
> I think that *optional* protection against further attacks is desirable
> (allowing applications to request further protection, which will
> potentially be detrimental to interoperability -- but won't hinder
> widespread deployment of default encryption
On 07/29/2014 07:36 AM, Tero Kivinen wrote:
> Martin Thomson writes:
>> 4. Able to access peer authentication credentials (often in
>> combination with 3)
>
> This one is quite hard in practice, and will depend a lot about the
> actual protocol we select. In the tcpcrypt there is no way to do
>
On 07/29/2014 04:20 PM, Stephen Kent wrote:
> In discussing features for the TCPINC work the charter says:
>
> ...
>
> - encryption and integrity protection without modifications to the upper
> layers (no API changes),
I take this to mean that no additional API should be required for this
feat
hi folks--
At the end of the wg meeting in toronto, Sharon Liu asked (as noted in
the minutes):
> Can this problem be resolved in a different way? Why isn't IPsec used more
> widely?
If this isn't feasible as an option, i think it's worth explicitly
stating why we're ruling it out.
Clearly, I
17 matches
Mail list logo
