I support adoption of this I-D.
Sorry to be late on this; I was on vacation (again).
Steve
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
Watson,
On Thu, Oct 8, 2015 at 5:03 PM, Stephen Kent wrote:
Watson,
I have two major comments. The draft recapitulates bits and pieces of
the TLS 1.3 draft, but it's not clear why this is done instead of
citing that draft. I also don't understand what it means to support a
bare
Watson,
I have two major comments. The draft recapitulates bits and pieces of
the TLS 1.3 draft, but it's not clear why this is done instead of
citing that draft. I also don't understand what it means to support a
bare public key: what exactly is to be done with this key, how is it
distinguished
Watson,
On Tue, Aug 25, 2015 at 7:06 AM, Stephen Kent wrote:
Watson,
On 8/24/15 4:37 PM, Watson Ladd wrote:
On Mon, Aug 24, 2015 at 1:08 PM, Stephen Kent wrote:
Watson,
based on many years of experience dealin wit this sort of issue
I suggest that the relative merits (strength, etc.) of
Stephen,
On 24/08/15 21:08, Stephen Kent wrote:
Watson,
based on many years of experience dealin wit this sort of issue
I suggest that the relative merits (strength, etc.) of cipher suites
form a lattice, not a total order.
Folks - Steve is I think correct here but I'm quite confused
Watson,
On 8/24/15 4:37 PM, Watson Ladd wrote:
On Mon, Aug 24, 2015 at 1:08 PM, Stephen Kent wrote:
Watson,
based on many years of experience dealin wit this sort of issue
I suggest that the relative merits (strength, etc.) of cipher suites
form a lattice, not a total order.
Every lattice
Watson,
based on many years of experience dealin wit this sort of issue
I suggest that the relative merits (strength, etc.) of cipher suites
form a lattice, not a total order.
Steve
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman
I prefer that both drafts be accepted as WG items, so that we can
evaluate the evolution of both in the WG context.
Steve
Dear all,
**Please use this CORRECTED version, as one option to choose from
below didn't make it into the original.
Thanks to Erik Rescola for pointing this out to me
Martin,
I support your option #1 proposed way forward.
Steve
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
I prefer a TLS-based solution, principally because of the
extensive experience understanding the security aspects of
TLS, and because of the code reuse opportunity.
I am willing to review and comment on future versions of docs
addressing the tcpinc requirements as now stated.
Steve
+1
David,
My view is that this document has to change significantly before we
can discuss adoption. Since this proposal significantly modifies the
TCP protocol and the TCP state engine, I'd really prefer to *first*
have a consistent document and *then* discuss a potential adoption.
If
the c
Joe,
...
I did.
To repeat in summary, the charter mandates a TCP solution based on
deployability to address pervasive monitoring. However:
- unauthenticated anything protects against only shared-media
monitoring. the kind of pervasive monitoring I believe motivated
the BCP is at firewalls or
David,
...
I said benefit each other.
what you said, precisely, was:
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, ...
I just noted that TLS
David,
"...
There are reasons why this is relevant from an IETF standards point of
view. 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
m
Joe,
...
My understanding is that v6 requires IPsec on every node.
The spec did, but that never happened.
IPsec is generally implemented in the v56 context, just not widely used.
So, I would not use the phrase "never happened."
Steve
___
Tcpinc
DKG,
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
In discussing features for the TCPINC work the charter says:
...
- encryption and integrity protection without modifications to the upper
layers (no API changes),
Steve
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/t
+1
On 2014-7-29, at 8:58, marcelo bagnulo braun wrote:
the charter reads:
- must always provide integrity protection of the payload data (it is
open for discussion for the WG if the TCP header should or should not
be protected).
So, I dont think we can clarify this, since it is up to the
Joe,
IMO, if you're not protecting the TCP header the solutions should not
be called TCP anything, nor should it be integrated as a TCP option.
It's basically just TLS with no signature on either end, and that
ought to suffice if that's all you really want.
I think that's an overstatement, e.g.
I believe that this work has been motivated primarily by RFC 7258
(pervasive monitoring).
If folks agree, then it does not seem necessary to protect TCP header
fields, including RST.
I say this because the primary (not sole) attack of concern in the PM
context is passive wiretapping.
Steve
_
20 matches
Mail list logo
