On 27 April 2016 at 16:50, Mirja Kühlewind
wrote:
> 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
On 19 November 2015 at 18:38, Kyle Rose wrote:
> This differs from the situation for TCP-SO, in which a "No+Abandoned"
> decision means that tcpinc itself is explicitly breaking TCP-SO.
If you know you are doing SO beforehand (in the cases I know of, this
is true), then you can disable the crypto
On 21 October 2015 at 01:49, Mirja Kühlewind
wrote:
> please indicate if you support adoption of
> draft-rescorla-tcpinc-tls-option-05 as a tcpinc working group item
Yeah, we should do this.
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/
On Oct 18, 2015 9:31 PM, "Yoav Nir" wrote:
>
>
> > On 19 Oct 2015, at 6:24 AM, Martin Thomson
wrote:
> > I can't think of any situation in which a compliant, valid ServerHello
> > would induce that behaviour. It would have to be busted somehow, I
>
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, valid ServerHello
would induce that behaviour. It would have to b
On 16 October 2015 at 07:01, Ilari Liusvaara wrote:
> AFAIK, they are going to wait for TRON[1], which is late February
> And then if everything goes well, push the draft forward
> (everything technical should be in place by then).
The plan is to have the draft stable a long time before TRON.
Oth
On 24 August 2015 at 14:20, Watson Ladd wrote:
> So this protocol negotiates how to negotiate?
That's my read on it. That's a natural consequence of layering. You
can make your own assessment about whether that is too much, but in
this case, I don't think that it is.
_
On 14 August 2015 at 11:30, wrote:
> Do you think TCP-ENO should specify the
> mechanism or the requirement?
Perhaps neither. At one level, this need only negotiate what crypto
is in effect.
At this stage, not knowing what is going to happen where, bundling
things together doesn't help.
_
On 14 August 2015 at 11:05, David Mazieres
wrote:
> If we don't specify requirements for the session ID, then applications
> will have to be knowledgeable about what encryption spec they are using.
> That means if we get large SYN options down the line and massively
> optimize TCPINC, applications
, which is part of what
Section 4 attempts to do. But you'd be better off doing so in a
straightforward fashion.
On 14 August 2015 at 10:25, David Mazieres
wrote:
> Martin Thomson writes:
>
>> I didn't suggest that you reduce entropy. My point was that you are
>> crea
On 13 August 2015 at 16:42, David Mazieres
wrote:
> Martin Thomson writes:
>
>> Don't call out the first byte. The whole thing is what will matter
>> here. As long as two session IDs are indistinguishable from each
>> other, I think that we're OK.
>
&g
On 13 August 2015 at 15:22, David Mazieres
wrote:
>
> * Unless and until applications disclose information about the session
> ID, all but the first byte MUST be computationally indistinguishable
> from random bytes to a network eavesdropper.
Don't call out the first byte. The whole thing i
In the interest of factual accuracy, and because I didn't have a
chance to refute these arguments previously...
On 3 August 2015 at 08:15, Mirja Kühlewind
wrote:
> a) TCP-use-TLS
> Contra:
> - dependency on TLS and update cycles of other working group
Also a Pro. We know that TLS is going to ge
I have only had a quick skim of the draft.
Firstly, I think that this is the right sort of split to make if we hope to
make progress here.
However, in my view, the design (and the draft) could be made considerably
smaller and less complex.
A simpler design would mimic ALPN. The initial SYN, wou
I think that Cullen said everything I intended to. See also Mark Twain when
it comes to eggs and baskets.
And then there is the part where I express confusion about this poll. The
working group seemed to have consensus on something else.
On Jul 31, 2015 2:58 AM, "Cullen Jennings" wrote:
>
> I pr
TLS has a TLV format already. Are you suggesting that tcpcrypt adopt that?
To be more precise, the TLS application data type is the three byte
sequence: 23, 3, 1. The length is a two byte value that follows it.
Handshakes use the 3 byte sequence: 22, 3, 1.
On 27 March 2015 at 07:45, Tim Shepard
On 17 March 2015 at 08:17, Ilari Liusvaara wrote:
> Heck, there's an RFC about attacks against TLS. Less than half year
> since last update, but:
>
> - Contains an attack that is only fixed in TLS 1.3 draft (not even
> draft extension to fix it in TLS 1.2).
> - Contains an attack that has no sta
On 16 March 2015 at 08:43, marcelo bagnulo braun wrote:
> https://datatracker.ietf.org/doc/draft-rescorla-tcpinc-tls-option/
I'd prefer doing less work overall. Due diligence on the tcpcrypt
security analysis can't be cheap.
"Put all your eggs in one basket and then watch that basket."
___
On 11 February 2015 at 18:55, David Mazieres
wrote:
>> I mean, if we protect the FIN and RST bit,s once the security
>> association between the endpoints has ocurred, an external attacker is
>> unable to disable the encryption, i believe.
>
> I agree, which is why I would like to see an option for
On 10 February 2015 at 21:52, marcelo bagnulo braun wrote:
> C decides then to send a FIN (or a RST) with the expectation to force the
> restart of the connection.
Unless peers are authenticated somehow, or peers are able to make some
sort of commitment to a key, then this seems like a plausible
On 13 October 2014 11:37, Joe Touch wrote:
>
> That requires TCP-level indication that TLS is being used. That requires
> indicating the use of the additional layer of TLS somewhere - in the
> port number, in a TCP option, etc. - but NOT in the data stream because
> AFAICT we can't tell the differ
On 13 October 2014 11:22, Christian Huitema wrote:
>> I.e., any option-based solution might not work through a middlebox -
>> including the one that signals the use of TCPINC. At that point, we're
>> back to running TLS, and it seems pointless to discuss this as a TCP
>> variant, IMO.
>
> I agree
On 13 October 2014 06:20, Brandon Williams wrote:
> I prefer option 1 for the reasons that John and Michael state.
My analysis of the header (which I can share) indicates that there is
very little value in protecting anything in the header (or
pseudoheader, which I note was not considered in the
On 21 August 2014 14:44, John-Mark Gurney wrote:
> Only on first connect to server... after that, you cache the results...
That's not particularly safe either. That assumes that you are
actually hitting the exact same software each time.
___
Tcpinc ma
On 3 August 2014 09:19, Watson Ladd wrote:
>
>
> Somehow I missed this mistake: the client does wasted work,
> potentially very expensive wasted work.
> But yes, it does reduce the game theory problem.
That's a tradeoff that completely empowers the client. Computation
costs in key generation pro
On 1 August 2014 14:41, Nico Williams wrote:
> Well, with DANE in mind... if the RST sender is the server, it could
> sign it.
At the point that you are authenticating the connection, I think that
many of our assumptions change.
___
Tcpinc mailing lis
On 1 August 2014 14:28, Eric Rescorla wrote:
> The issue isn't middleboxes; it's that if you require integrity protection
> for RSTs, then there's no way for a box that reboots to send you an
> RST.
I'm starting to think that we might need something more nuanced here.
The existence of race condi
On 1 August 2014 12:07, ianG wrote:
> I agree. May the best proposal win: choose the one that best serves
> the overall needs of competing proposals.
For the record, contests like this that I've been involved with in the
past have produced bad results. I hope that we can do better than
that.
On 31 July 2014 09:30, David Mazieres wrote:
> Because TLS, despite the name, is not really at the same layer as
> TCP, it will be difficult to use in conjunction with other layer-4
> standards such as TCP minion, fast open, and multipath, while there are
> more or less straight-forward ways to ex
On 30 July 2014 11:12, Daniel Kahn Gillmor wrote:
> I note that we won't be able to fold these headers into a standard AEAD
> construction with this approach, since stuffing RST and category 2
> headers into the AD spot will mean that any munging of the protected
> header info would cause the payl
On 30 July 2014 11:29, Daniel Kahn Gillmor wrote:
> We know that middleboxes exist; what we won't know without more
> measurements is what sort of damage they will inflict on adopters of any
> of the proposed forms of tcpinc.
Google did some research on this from an HTTP perspective when
research
On 30 July 2014 10:25, Daniel Kahn Gillmor wrote:
> saying "optional protection" implies a bunch of complexity that bears on
> interoperability and negotiation issues; those really need to be nailed
> down to be evaluated properly.
One of those pieces of complexity is the handling of failures.
Ob
On 29 July 2014 10:09, Ted Hardie wrote:
> Not to cross the streams or anything, but I'm wondering why an API
> requirement to protect the headers couldn't be inserted here. Obviously
> there are costs in latency in some of the RST cases described, but if it is
> an available knob, presumably it
On 28 July 2014 12:04, Bodo Moeller wrote:
>> - Protecting the sequence number. For example, the TCP-Minion group
>> is very keen on being able to decrypt and use TCP packets out of
>> order. Protecting the sequence number is one way for them to
>> achieve that goal.
>
>
> Payload
On 28 July 2014 09:45, Bodo Moeller wrote:
> I'd like to see a more coherent and more complete story.
pseudoheader_v4 = source_address(32) + destination_address(32) +
zero(8) + protocol(8) + tcp_length(16)
pseudoheader_v6 is essentially identitcal to _v4.
tcp_heade
On 28 July 2014 09:44, Eric Rescorla wrote:
> We can certainly explore this. The tcpcrypt API looked basically fine, and
> it
> seemed like it would be an OK match with my draft, but I admit I haven't
> actually tried to do the detail work.
That was my take as well.
The API we're talking about h
36 matches
Mail list logo
