IIUC the idea is that the TLS work is not ended, merely suspended, and will
resume once TLS 1.3 is out the door. Whether that will actually happen is of
course not known.
Yoav
> On 16 Jul 2016, at 6:58 PM, Watson Ladd wrote:
>
> Dear all,
> Originally negotiation was proposed because EKR want
> On 1 Apr 2016, at 12:35 AM, David Mazieres
> wrote:
>
> 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
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.
Yoav
> On 31 Mar 2016, at 10:58 PM, Flemming Andreasen wrote:
>
> I
Hi
I’ve reviewed the tcpcrypt draft. Usual caveat: IANAC, so I won’t comment on
the strength of the algorithms used.
In general, the draft looks OK. There should be clarity improvements, but I
think if I had a TCP stack, this draft and the ENO draft, I could probably
implement this (assuming I
> On 11 Mar 2016, at 11:59 AM, David Mazieres
> wrote:
>
> 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. Co
Hi,
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.
As a protocol, it is more complex than I would have liked, considering that its
entire purpose is to choose between two mechanisms, and that we don’t really
> On 19 Oct 2015, at 6:24 AM, Martin Thomson wrote:
>
> On 18 October 2015 at 16:59, Eric Rescorla wrote:
>> Yeah, I am starting to think I was getting too clever here and it would be
>> better
>> to just say "tear down the connection"
>
>
> I can't think of any situation in which a compliant
Hi
Two things that bothered me that I think have not been mentioned by either
Mirja or David:
Section 2 says: "If the TLS handshake fails for non-cryptographic reasons …
endpoints SHOULD behave as if the the TCP-TLS option was not present.”
I’m missing what counts as “cryptographic” vs not. So
> On Aug 24, 2015, at 5:31 PM, Watson Ladd wrote:
>
> On Mon, Aug 24, 2015 at 7:29 AM, Ilari Liusvaara
> wrote:
>> On Mon, Aug 24, 2015 at 07:22:23AM -0700, Watson Ladd wrote:
>>> On Mon, Aug 24, 2015 at 6:33 AM, David Mazieres
>>>
>>> This is a misreading: I'm proposing that at any time there
> On Aug 3, 2015, at 8:39 PM, David Mazieres
> wrote:
>
> Eric Rescorla writes:
>
>> - ECDH_anon with P256 and Curve25519
>> - AES_128_GCM; AES_256_GCM; ChaCha/Poly1305
>
> This is a naive question, but could we get some guidance from the powers
> that be on what ciphers are and are not appr
> On Jul 31, 2015, at 5:54 PM, Richard Barnes wrote:
>
> I have a pretty strong preference for (a), the Rescorla draft. New code is
> undesirable in security systems -- better to rely on a known, battle-tested
> code base.
The codebase is going to be new anyway. We’re not likely to be abl
> On Jul 31, 2015, at 3:58 AM, Cullen Jennings wrote:
>
>
> I prefer for the WG to select draft a) draft-rescorla-tcpinc-tls-option-03 as
> the starting point.
>
> The track record of security bugs in developing a new security protocol
> result in me having a strong preference for using some
> On Jul 27, 2015, at 8:23 PM, Tommy Pauly wrote:
>
> Start with (b) tcpcrypt, and either adopt (a) once it is more specified or
> try to converge.
>
> Part of this is pragmatic. If we end up with a protocol based on tcpcrypt,
> then we will probably want to have started working earlier since
TCPINC minutes
==
Agenda bashing
Tero: two drafts, trying to select between them: tcpcrypt and TLS-based. Lots
of ADs in the room.
Andrea about tcpcrypt
Encrypt payload, MAC some of the options. The MAC is in a TCP option
Brian Trammell: tcpcrypt MAC'd the header. Do you have d
Hi Brian, Valery
FTP comes in two varieties: active and passive. There is no issue in passive
mode FTP with tcpinc, as the client opens all the connections. For active,
there is an issue with using tcpinc on the control connection, but no issue for
the data connection.
AFAIK (and according to
On Aug 3, 2014, at 9:20 PM, David Mazieres
wrote:
>
> Skeeter and Bubba are kind of an inside joke,
Blue Thunder [1] reference?
Yoav
[1] The TV show, not the movie
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcp
On Aug 3, 2014, at 3:27 AM, Watson Ladd wrote:
>>
>>> Why don't we attempt to determine which shortcomings need to be
>>> addressed and how to fix them with tcpcrypt, instead of design
>>> by committee?
>>
>> The WG now has four proposals to deal with. In a way that's a good
>> thing as it indi
On Aug 3, 2014, at 12:33 AM, Watson Ladd wrote:
> On Sat, Aug 2, 2014 at 2:03 PM, Yoav Nir wrote:
>>
>> On Aug 2, 2014, at 11:43 PM, John-Mark Gurney wrote:
>>
>>> Yoav Nir wrote this message on Sat, Aug 02, 2014 at 23:09 +0300:
>>>> The chart
On Aug 2, 2014, at 11:43 PM, John-Mark Gurney wrote:
> Yoav Nir wrote this message on Sat, Aug 02, 2014 at 23:09 +0300:
>> The charter calls for the group to ?develop the TCP extensions to provide
>> unauthenticated encryption and integrity protection of TCP streams? and
Hi Watson.
The charter calls for the group to “develop the TCP extensions to provide
unauthenticated encryption and integrity protection of TCP streams” and “define
an unauthenticated key exchange mechanism." This pretty much calls for design
by committee.
As for shortcomings of tcpcrypt, ther
On Jul 28, 2014, at 5:28 PM, Watson Ladd wrote:
>
> On Jul 28, 2014 7:18 AM, "Eggert, Lars" wrote:
> >
> > On 2014-7-28, at 16:00, Erik Nygren wrote:
> > > I do wonder if protecting RSTs and thus other parts of the header as well
> > > is more tractable with both endpoints using IPv6 (where
21 matches
Mail list logo
