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
On Mon, Aug 3, 2015 at 12:08 PM, John-Mark Gurney wrote:
> Eric Rescorla wrote this message on Mon, Aug 03, 2015 at 04:16 -0700:
> > On Sun, Aug 2, 2015 at 11:24 PM, John-Mark Gurney
> wrote:
> >
> > > Eric Rescorla wrote this message on Sun, Aug 02, 2015 at 11:52 -0700:
> > > > things so it's n
Eric Rescorla wrote this message on Mon, Aug 03, 2015 at 04:16 -0700:
> On Sun, Aug 2, 2015 at 11:24 PM, John-Mark Gurney wrote:
>
> > Eric Rescorla wrote this message on Sun, Aug 02, 2015 at 11:52 -0700:
> > > things so it's not obvious to others. In any case, what you'd want is
> > > something
> 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 Mon, Aug 3, 2015 at 10:39 AM, David Mazieres <
dm-list-tcpcr...@scs.stanford.edu> 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
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 appropriate for an experimental
TCPINC protocol document?
Technically, Curv
On Mon, Aug 3, 2015 at 8:44 AM, Daniel Kahn Gillmor
wrote:
> 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]
> > -
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
Hi Ekr,
> Am 02.08.2015 um 22:21 schrieb Eric Rescorla :
>
> I'm not sure what you mean by "isn't committing". The question of exactly what
> parameters go in the profile is, as Ted has observed repeatedly, ultimately a
> WG decision,
> not my personal decision, so I'm not sure how I could commi
On Mon, Aug 3, 2015 at 5:02 AM, Eric Rescorla wrote:
>
>
> On Mon, Aug 3, 2015 at 4:58 AM, Mirja Kühlewind <
> mirja.kuehlew...@tik.ee.ethz.ch> wrote:
>
>> Hi ekr,
>>
>> as an individual contributor: I believe the wg would like to see (1) in
>> the next version of the draft. However, please keep
On Mon, Aug 3, 2015 at 4:58 AM, Mirja Kühlewind <
mirja.kuehlew...@tik.ee.ethz.ch> wrote:
> Hi ekr,
>
> as an individual contributor: I believe the wg would like to see (1) in
> the next version of the draft. However, please keep in mind that a lot of
> the people in the wg are not TLS experts but
Hi ekr,
as an individual contributor: I believe the wg would like to see (1) in the
next version of the draft. However, please keep in mind that a lot of the
people in the wg are not TLS experts but rather come from the transport
community. Even though a self-contained document is not required,
On Sun, Aug 2, 2015 at 11:24 PM, John-Mark Gurney wrote:
> Eric Rescorla wrote this message on Sun, Aug 02, 2015 at 11:52 -0700:
> > things so it's not obvious to others. In any case, what you'd want is
> > something
> > like:
> >
> > - ECDH_anon with P256 and Curve25519
> > - AES_128_GCM; AES_25
Eric Rescorla wrote this message on Sun, Aug 02, 2015 at 11:52 -0700:
> things so it's not obvious to others. In any case, what you'd want is
> something
> like:
>
> - ECDH_anon with P256 and Curve25519
> - AES_128_GCM; AES_256_GCM; ChaCha/Poly1305
> - SHA256 for the PRF
> - Session hash
> - No re
On Sun, Aug 2, 2015 at 2:25 PM, Christian Huitema wrote:
> On Sunday, August 2, 2015 1:37 PM, Watson Ladd wrote:
>>
>> On Sun, Aug 2, 2015 at 1:30 PM, Christian Huitema
>> wrote:
>> > On Sunday, August 2, 2015 12:52 PM, John-Mark Gurney wrote:
>> >>
>> >> ...
>> >> It's sounds like you view TLS-u
On Sunday, August 2, 2015 1:37 PM, Watson Ladd wrote:
>
> On Sun, Aug 2, 2015 at 1:30 PM, Christian Huitema
> wrote:
> > On Sunday, August 2, 2015 12:52 PM, John-Mark Gurney wrote:
> >>
> >> ...
> >> It's sounds like you view TLS-use-TCP as doing full certificate parsing
> >> and validation in th
On Sun, Aug 2, 2015 at 1:30 PM, Christian Huitema wrote:
> On Sunday, August 2, 2015 12:52 PM, John-Mark Gurney wrote:
>>
>> ...
>> It's sounds like you view TLS-use-TCP as doing full certificate parsing
>> and validation in the kernel, is this correct?
>
> There are multiple ways to implement a s
On Sunday, August 2, 2015 12:52 PM, John-Mark Gurney wrote:
>
> ...
> It's sounds like you view TLS-use-TCP as doing full certificate parsing
> and validation in the kernel, is this correct?
There are multiple ways to implement a shim between application and TCP. If I
implemented this in the Win
On Sun, Aug 2, 2015 at 12:51 PM, John-Mark Gurney wrote:
>
> TLS-use-TCP still doesn't have a profile.. ekr gave a profile "like"
> something today, he isn't committing to it, or even suggesting that
> be the profile...
Well, I certainly was suggesting that as a starting point for the modes and
Christian Huitema wrote this message on Sun, Aug 02, 2015 at 19:07 +:
> On Sunday, August 2, 2015 11:12 AM, David Mazieres wrote:
> > Richard Barnes writes:
> >
> > > I have a pretty strong preference for (a), the Rescorla draft. New code
> > > is undesirable in security systems -- better t
On Sunday, August 2, 2015 11:52 AM, Eric Rescorla wrote:
> On Sun, Aug 2, 2015 at 11:11 AM, David Mazieres
> wrote:
>> Well, a priori, one can argue that even though TCP-use-TLS may require
>> more engineering effort in absolute terms than tcpcrypt, the delta
>> between application-level TLS (re
On Sunday, August 2, 2015 11:12 AM, David Mazieres wrote:
> Richard Barnes writes:
>
> > 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. So it seems like a no-brainer to us
On Sun, Aug 2, 2015 at 11:11 AM, David Mazieres <
dm-list-tcpcr...@scs.stanford.edu> wrote:
>
> Well, a priori, one can argue that even though TCP-use-TLS may require
> more engineering effort in absolute terms than tcpcrypt, the delta
> between application-level TLS (required anyway) and transport
Richard Barnes writes:
> 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. So it seems like a no-brainer to use TLS as the
> starting point and making the minimum set of changes
> 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 Aug 2, 2015 5:57 AM, "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. So it seems like a no-brainer to use TLS as the
starting point and making the min
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. So it seems like a no-brainer to use TLS as the
starting point and making the minimum set of changes needed.
--Richard
__
On Jul 31, 2015 3:38 AM, "Stephen Farrell" wrote:
>
>
> As previously stated I think tcpcrypt is a better starting point
> for tcpinc.
>
> For those confused about this poll, I'm not sure if this will help
> but when we hummed in the room about which document to start from,
> and the chairs didn't
As previously stated I think tcpcrypt is a better starting point
for tcpinc.
For those confused about this poll, I'm not sure if this will help
but when we hummed in the room about which document to start from,
and the chairs didn't see rough consensus in the room, they were
asked to confirm that
I prefer:
b) draft-bittau-tcpinc-tcpcrypt-03
DISCLAIMER: I am working on the tcpcrypt project and so am perhaps
biased. Reasons I support tcpcrypt include:
- simpler
- less dependence on other WGs or legacy standards/formats
- adds to the diversity of protocols
- more likely to make it into a
I too am confused about this poll, since it seemed clear in Prague that we
had
consensus to provisionally move forward with both.
With that said, I prefer (a) draft-rescorla-tcpinc-tls-option-03, for the
reasons I
laid out previously: I believe it's a simple and direct application of TLS
to this
u
Here are the two drafts:
a) draft-rescorla-tcpinc-tls-option-03
b) draft-bittau-tcpinc-tcpcrypt-03
on wether you prefer
- either draft a) or b)
- both drafts (a & b) as WG items
- or none
to be accepted as WG item(s).
Please write also your brief reasoning on why you made your choice.
Please
> 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
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
I am in favor of pursuing both drafts, mostly because I think each
group has something to offer, and they are disparate-enough camps that
it's unlikely the tcpinc effort would be slowed by pursuing both.
IMO, tcpcrypt provides what we really need: a clean break with legacy
systems, a simple, easil
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 something where lots of people have
spent a lot of time looking at the alg
Martin Stiemerling wrote this message on Fri, Jul 24, 2015 at 04:16 -0500:
> a) draft-rescorla-tcpinc-tls-option-03
> b) draft-bittau-tcpinc-tcpcrypt-03
>
> Please respond to the tcpinc wg mailing list until
>
> July 31st, 2015
> 1pm CEST
>
> on wether you prefer
> - either draft a) or b
> 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
Greetings, all,
My opinion is close enough to Ted's for me to quote it:
> On 27 Jul 2015, at 18:40, Ted Hardie wrote:
>
> Since there was a request to restate viewpoints on the list even for those of
> us vocal at the meeting, my current preference is for moving forward with
> both, with an a
I prefer adoption of A (tcpinc-tls-option), because:
* I believe a profile of tls can be produced that will be acceptable to
kernel developers and can satisfy the "short, simple security proof"
goal described by proponents of tcpcrypt, and
* I believe that a solution based on that profile of TLS
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 there is more
content to review. Even if the drafts merge, to h
Since there was a request to restate viewpoints on the list even for those
of us vocal at the meeting, my current preference is for moving forward
with both, with an aim toward convergence if possible.
I think both provide a reasonable starting point, with the trade-offs
between the two being diff
uot;
> To: "tcpinc@ietf.org"
> Subject: [tcpinc] CORRECTION: Reminder: Ongoing Working Group Last Call
> about drafts to choose as WG item
> Date: Fri, Jul 24, 2015 11:17 AM
>
>
> Dear all,
>
> **Please use this CORRECTED version, as one option to choose from below
t;
Subject: [tcpinc] CORRECTION: Reminder: Ongoing Working Group Last Call about
drafts to choose as WG item
Date: Fri, Jul 24, 2015 11:17 AM
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 fo
Hi Eric,
Am 24.07.15 um 11:28 schrieb Eric Rescorla:
On Fri, Jul 24, 2015 at 11:24 AM, Ted Hardie mailto:ted.i...@gmail.com>> wrote:
Hi Martin,
Thanks for the correction, but I confess I'm still a little
confused. I understood in the room that you saw rough consensus on
the l
Am 24.07.15 um 12:19 schrieb Ted Hardie:
Hi Martin,
On Fri, Jul 24, 2015 at 11:33 AM, Martin Stiemerling mailto:mls.i...@gmail.com>> wrote:
This call is a simple procedural step:
There were hums in the session on whether to go for just a), just
b), or both. This call is sim
Martin Stiemerling writes:
> b) draft-bittau-tcpinc-tcpcrypt-03
As you would expect since I am a co-author, I prefer this option. My
reasons are that it increases diversity, is more specifically suited to
TCP, is simpler and more self-contained, and--because it isn't anchored
to another working
b) draft-bittau-tcpinc-tcpcrypt-03
As being in one complete document it'll be easier to comprehend,
there is some current runing code, and it strikes me a more
likely to see actual deployment than the 'use TLS' approach,
especially in a kernel.
DF
___
b
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
On Fri, Jul 24, 2015 at 12:19 PM, Ted Hardie wrote:
> Hi Martin,
>
> On Fri, Jul 24, 2015 at 11:33 AM, Martin Stiemerling
> wrote:
>
>>
>>
>> This call is a simple procedural step:
>> There were hums in the session on whether to go for just a), just b), or
>> both. This call is simply to confi
Hi Martin,
On Fri, Jul 24, 2015 at 11:33 AM, Martin Stiemerling
wrote:
>
>
> This call is a simple procedural step:
> There were hums in the session on whether to go for just a), just b), or
> both. This call is simply to confirm the hums out of the WG session on the
> list, no more.
>
> Every
Hi Ted,
Am 24.07.15 um 04:24 schrieb Ted Hardie:
Hi Martin,
Thanks for the correction, but I confess I'm still a little confused. I
understood in the room that you saw rough consensus on the list to go
forward with both, based on the call that went to the list and ended on
the 20th. This was
On Fri, Jul 24, 2015 at 11:24 AM, Ted Hardie wrote:
> Hi Martin,
>
> Thanks for the correction, but I confess I'm still a little confused. I
> understood in the room that you saw rough consensus on the list to go
> forward with both, based on the call that went to the list and ended on the
> 20t
Hi Martin,
Thanks for the correction, but I confess I'm still a little confused. I
understood in the room that you saw rough consensus on the list to go
forward with both, based on the call that went to the list and ended on the
20th. This was something Mirja and I both argued for, and the minut
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 directly.
This point got lost on the mailing list, but it has been decided in the
WG session here at IETF-93 that there w
55 matches
Mail list logo
