Re: [tcpinc] Review of draft-ietf-tcpinc-tcpeno-10

[Watson Ladd]

On Thu, Oct 19, 2017 at 2:34 AM, David Mazieres <
dm-list-tcpcr...@scs.stanford.edu> wrote:

> Watson Ladd <watsonbl...@gmail.com> writes:
>
> > Dear all,
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should treat
> > these comments just like any other last call comments.
> >
> > The summary of the review is that the writing and most of the
> > structure is fine, but I am a bit confused by some of the security
> > properties and how they are stated. It is not clear to me why the
> > unpredictability of generated session IDs is required.
>
> Thanks for your review.
>
> Unpredictability of session IDs is required because doing so is not
> particularly burdensome and because it's a very strong property that
> subsumes the security requirements of a broad range of cases where
> things might otherwise go wrong.  For example, the TEP has to be 33
> bytes, and we don't want the last 16 of them being zeros.  Moreover, if
> people sign session IDs for authentication, we want to be absolutely
> sure they don't mess up the domain separation.  As another example,
> someone might use a session ID on one connection to try to authenticate
> a session ID on another.  Do you buy this rationale?  And is it
> important enough that you think we need to add a subsection to the
> rationale section discussing it?
>

More rational for the requirement would I think help.

> It is also not clear to me that the requirement that a TEP produce
> > different keys for different transcripts is strong enough: we need to
> > ensure that every TEP produces different keys (with high probability)
> > (and session identifiers) for different transcripts to prevent
> > cross-protocol attacks.
>
> Do you mind clarifying this comment?  I assume it's in relation the
> following two paragraphs from sections 4.8 and 10 respectively?
>
>To defend against attacks on encryption negotiation itself, a TEP
>MUST with high probability fail to establish a working connection
>between two ENO-compliant hosts when SYN-form ENO options have been
>altered in transit.  (Of course, in the absence of endpoint
>authentication, two compliant hosts can each still be connected to a
>man-in-the-middle attacker.)  To detect SYN-form ENO option
>tampering, TEPs must reference a transcript of TCP-ENO's negotiation.
>
>...
>
>Because TCP-ENO enables multiple different TEPs to coexist, security
>could potentially be only as strong as the weakest available TEP.  In
>particular, if session IDs do not depend on the TCP-ENO transcript in
>a strong way, an attacker can undetectably tamper with ENO options to
>force negotiation of a deprecated and vulnerable TEP.  To avoid such
>problems, TEPs MUST compute session IDs using only well-studied and
>conservative hash functions.  That way, even if other parts of a TEP
>are vulnerable, it is still intractable for an attacker to induce
>identical session IDs at both ends after tampering with ENO contents
>in SYN segments.
>
> The goal here is indeed to thwart both cross-TEP attacks and TEP
> downgrade attacks, but to do so without mandating a particular hash
> function for all TEPS, because that would severely hamper crypto
> agility.  The extra byte in session IDs should save us from cases where
> somehow both SHA-512 and Keccac are secure, but someone found two inputs
> x and y such that SHA-512(x)==SHA-3(y) causing reuse of Session IDs
> across TEPs.  So I can't figure out the attack you are worried about...
>

Ah, that does work. Thanks for responding to my review.


>
> Thanks,
> David
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

[tcpinc] Why retain negotatiation

[Watson Ladd]

Dear all,
Originally negotiation was proposed because EKR wanted to use TLS.
That has now ended, but we are retaining the negotiation layer with
far more generality then required. I'm not sure why that is.
Sincerely,
Watson

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] Call for adoption of draft-bittau-tcpinc-tcpcrypt-04

[Watson Ladd]

On Thu, Oct 22, 2015 at 6:19 PM, Derek Fawcus
 wrote:
> On Tue, Oct 20, 2015 at 06:47:43PM +0200, Mirja Kühlewind wrote:
>> please indicate if you support adoption of draft-bittau-tcpinc-tcpcrypt-04 as
>> a tcpinc working group item,
>
> I support its adoption.

I support adoption
>
> ___
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[Watson Ladd]

On Tue, Aug 25, 2015 at 7:06 AM, Stephen Kent k...@bbn.com wrote:
 Watson,

 On 8/24/15 4:37 PM, Watson Ladd wrote:

 On Mon, Aug 24, 2015 at 1:08 PM, Stephen Kent k...@bbn.com 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 has a compatible total order

 more properly, a total order can be imposed on a lattice.

I don't see the difference between these two statements, and I don't
see the relevance.

 , and preferences are
 expressed as total orders.

 The issue here is that reasonable people can disagree about
 the total order imposed on the lattice.

 Could you explain how your supposed insight

 supposed insight seems rather pejorative; better watch out for the
 IETF mail list PC police

Earlier people raised examples of ciphersuites with no comparison
between them. Why does what you are saying matter more? What's the
connection between being a lattice, and picking just one ranking not a
good idea.


 into the reality of comparing ciphersuites justifies exposing all
 possible ciphersuites, and permitting specifying arbitrary preferences
 among them?

 The preferences of others are arbitrary but yours are not?

Of course it's an arbitrary choice! My question is why is it not a
good idea to pick a single nothing-else-is better suite. and have a
mechanism designed to support migration if weaknesses are discovered?
So far as I can tell the argument has been that people have different
orderings, and should be allowed to express them. But this doesn't
actually get to the fundamental issue: how much more secure are people
if they will use X instead of Y if the other side wants it, then if
they prefer Y instead of X?

What happens in practice is that we end up with copypasta in config
files. And then when we do need to have a migration, instead of the
next version of the software automatically prefering the new thing,
configurations need to be changed. Of course you can always wash your
hands of this by saying software could have expressed the preferences
differently. But if software is going to do that, then we might as
well chop down on what the mechanism needs to express. There are real
benefits from shrinking code and reducing the complexity of the
versioning mechanism.

Downthread David Menzies is saying we only need three ciphersuites,
with one explicitly as a backup for the other. So what's gained from
being able to reverse that ordering? I do think we can't actually
specify a backup until the primary is weak: remember when RC4 was the
solution for Bard's attack on TLS 1.0?

Sincerely,
Watson Ladd

 Steve

 ___
 Tcpinc mailing list
 Tcpinc@ietf.org
 https://www.ietf.org/mailman/listinfo/tcpinc



-- 
Man is born free, but everywhere he is in chains.
--Rousseau.

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[Watson Ladd]

On Mon, Aug 24, 2015 at 7:29 AM, Ilari Liusvaara
ilari.liusva...@elisanet.fi 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 is only one
 suite that everyone uses, and versioning is just for transitions.

 This becomes highly problematic when one needs to:
 - Support multiple security levels.
 - There isn't one technically (meaning, ignore legal constraints)
   superrior algorithm.

In case of point 2, why is there a need to use multiple algorithms?

As far as point 1 goes, if you want data to only travel over one
security level, you cannot support two security levels.



 -Ilari



-- 
Man is born free, but everywhere he is in chains.
--Rousseau.

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[Watson Ladd]

On Mon, Aug 24, 2015 at 6:33 AM, David Mazieres
dm-list-tcpcr...@scs.stanford.edu wrote:
 Watson Ladd watsonbl...@gmail.com writes:

 Actually, people have *very* strong opinions about crypto and are
 willing to lobby pretty hard for particular algorithms and protocols.
 We should ensure such lobbying is directed towards OS vendors *after*
 TCP-ENO is standardized, not towards the working group beforehand (where
 it will further slow us down undermine TCP-ENO's goal of breaking the
 working group deadlock).

 Who are people?

 For example, the Russians vs. the US.  The Russians require that banks
 and any products purchased by the government employ the GOST cipher.  In
 the US, AES is effectively required.  According to wikipedia, the best
 known attacks on the two are roughly comparable, though GOST is easier
 to misuse (by setting bad S-boxes) and has only a 64-bit block size.

 Now if I go visit a Russian bank (e.g., https://www.sberbank.ru), my
 browser (which doesn't support GOST) happily chooses AES as the cipher.
 Similarly, I'm sure Russian bank employees get AES when talking to US
 institutions.  But according to the amended presidential decree number
 334, it seems the banks have to use GOST internally because the
 Russians don't trust our crypto (which at the time of the decree was
 DES, and at the time it was amended was AES).  Of course, if you are
 paranoid maybe you think the Russian government can break GOST and/or
 the US government can break AES.

Let's look at an actual Russian bank website, and see which
ciphersuites are enabled.
https://www.ssllabs.com/ssltest/analyze.html?d=http%3A%2F%2Fwww.sberbank.ru%2F

Please point out the GOST ciphersuite being used. Even if internal
tools (which won't rely on easily disabled tcp encryption) used GOST,
clearly this isn't actually applying to the website.


 Certainly not the people willing to use the alternative algorithm if
 they have to.

 Yes the people willing to use the alternative algorithms, as evidenced
 by Russian web sites willing to use AES with me.

 The problem is with the existence of sites where only one algorithm
 must be used, and the OS is configured accordingly.

 Hard-coding global cipher priority is likely to exacerbate this problem.
 If the only way to prefer GOST is to disable AES entirely, well, then
 Russian institutions will disable AES.

 The fact that we have way too many encryption options floating around
 does not mean all ciphersuites can be strictly ordered by security, for
 the simple reason that nobody can predict the future.  Cryptanalysis may
 alter the relative security of different algorithms at any time.  Or
 some NIST scandal might erupt casting doubt on the design methodology of
 P-512 compared to the nominally weaker Curve25519.  At such points, OS
 vendors need the ability to re-prioritize cipher suites without breaking
 backwards compatibility.

 Am I proposing a fixed, static ordering?

 It certainly sounds like it.

This is a misreading: I'm proposing that at any time there is only one
suite that everyone uses, and versioning is just for transitions.


 No. I'm proposing that in response to cryptanalysis we have a
 functional migration plan, and the negotiation mechanism to support
 it. We start with version 1, when that becomes untenable move to
 version 2. This has eliminated SSHv1 from the Internet. The
 alternative plan has never eliminated any cipher completely.

 But SSH has had the same kind of mix-and-match crypto you have been
 decrying.  In context, that was a good thing.  For years SSH shipped a
 broken stream cipher mode that used the same key in both directions.  A
 lot of people used SSH'S ARC4 mode because it was super fast.
 Fortunately, when it was found insecure, vendors simply removed support
 for that mode and security was restored where either endpoint had an
 upgraded SSH.  If people had disabled other modes to prefer ARC4,
 obviously the upgrade path would have been much harder, as SSH would
 have been unusable during the transition.

No, I'm proposing introducing a new version done correctly in
response. RC4 should never have been used in the first place. This
migration hasn't taken place in SSL, despite a similar negotiation
mechanism.


 The upgrade from SSH version 1 to version 2 was not primarily about
 upgrading the encryption, was not in response to cryptanalysis, and did
 not eliminate any cipher from the Internet.  We could, of course,
 imagine using TCP-ENO to select between the equivalent of SSH 1 and SSH
 2, with cipher negotiation handled at a different layer.  But if we want
 just a few good cipher suite options, then these should simply be tied
 to ENO suboptions, in which case the IETF cannot prioritize these.

 David



-- 
Man is born free, but everywhere he is in chains.
--Rousseau.

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[Watson Ladd]

On Mon, Aug 24, 2015 at 1:08 PM, Stephen Kent k...@bbn.com 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 has a compatible total order, and preferences are
expressed as total orders. Could you explain how your supposed insight
into the reality of comparing ciphersuites justifies exposing all
possible ciphersuites, and permitting specifying arbitrary preferences
among them?


 Steve



 ___
 Tcpinc mailing list
 Tcpinc@ietf.org
 https://www.ietf.org/mailman/listinfo/tcpinc



-- 
Man is born free, but everywhere he is in chains.
--Rousseau.

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[Watson Ladd]

On Sun, Aug 23, 2015 at 12:42 PM, David Mazieres
dm-list-tcpcr...@scs.stanford.edu wrote:
 Watson Ladd watsonbl...@gmail.com writes:

 Think of this fixed ordering as versioning, like HTTP/0.9, 1.0, 1.1,
 2.0, etc. The idea is that we'd only introduce new versions when we
 knew they were stronger than the old ones.

 Such a linear ordering would be very hard to achieve, given that
 different parts of the world trust/mistrust different crypto algorithms.
 Even among cipher suites discussed so far, how would we order
 P-256/AES-128 vs. Curve25519/Chacha/Poly1305.  The former set is better
 is the sense that it is more established.  The latter is better in the
 sense that it is newer, potentially more efficient, and (for the
 paranoid) less tainted by government involvement.  I think realistically
 the preference has to be left to the individual host configuration
 rather than the IETF.

Let's consider what this actually means. Hosts that implement 1 of two
options because they don't trust the other one to provide adequate
security will not talk to the ones that make the wrong choice. Hosts
that implement both would be fine picking just one, in fact prefer it
as it reduces the amount of work they have to do.

But by having ranking preferences, we're in fact saying you would be
fine with picking one for improved interop, but we're going to force
you to make a choice that complicates your implementation, because we
assume you are an expert in cryptanalysis research and we are not.
Picking one suite that's widely acceptable is far better than
providing a smorgasbord.


 David



-- 
Man is born free, but everywhere he is in chains.
--Rousseau.

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[Watson Ladd]

On Sun, Aug 23, 2015 at 7:28 PM, David Mazieres
dm-list-tcpcr...@scs.stanford.edu wrote:
 Watson Ladd watsonbl...@gmail.com writes:

 Suppose everyone behaves the way you suggest. How unhappy are they
 with using X or Y? Clearly not very much: they were willing to use it
 if the other side didn't want their preference.

 Actually, people have *very* strong opinions about crypto and are
 willing to lobby pretty hard for particular algorithms and protocols.
 We should ensure such lobbying is directed towards OS vendors *after*
 TCP-ENO is standardized, not towards the working group beforehand (where
 it will further slow us down undermine TCP-ENO's goal of breaking the
 working group deadlock).

Who are people? Certainly not the people willing to use the
alternative algorithm if they have to. The problem is with the
existence of sites where only one algorithm must be used, and the OS
is configured accordingly.

 The result of wanting to support every possible combination of
 preferences and admin interface is having dead options linger forever
 as the sysadmins keep copypasta in config files alive forever. I'd
 rather order my crypto from McSorley's.

 The fact that we have way too many encryption options floating around
 does not mean all ciphersuites can be strictly ordered by security, for
 the simple reason that nobody can predict the future.  Cryptanalysis may
 alter the relative security of different algorithms at any time.  Or
 some NIST scandal might erupt casting doubt on the design methodology of
 P-512 compared to the nominally weaker Curve25519.  At such points, OS
 vendors need the ability to re-prioritize cipher suites without breaking
 backwards compatibility.

Am I proposing a fixed, static ordering? No. I'm proposing that in
response to cryptanalysis we have a functional migration plan, and the
negotiation mechanism to support it. We start with version 1, when
that becomes untenable move to version 2. This has eliminated SSHv1
from the Internet. The alternative plan has never eliminated any
cipher completely.


 David



-- 
Man is born free, but everywhere he is in chains.
--Rousseau.

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] CORRECTION: Reminder: Ongoing Working Group Last Call about drafts to choose as WG item

[Watson Ladd]

On Aug 2, 2015 5:57 AM, Richard Barnes r...@ipv.sx 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 minimum set of changes needed.

It's true that OpenSSL has been executed more times then some other
implementations. Does this ensure its security?

Bind was more popular  then qmail. Which has a better security record?


 --Richard

 ___
 Tcpinc mailing list
 Tcpinc@ietf.org
 https://www.ietf.org/mailman/listinfo/tcpinc
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] CORRECTION: Reminder: Ongoing Working Group Last Call about drafts to choose as WG item

[Watson Ladd]

On Sun, Aug 2, 2015 at 2:25 PM, Christian Huitema huit...@microsoft.com wrote:
 On Sunday, August 2, 2015 1:37 PM, Watson Ladd wrote:

 On Sun, Aug 2, 2015 at 1:30 PM, Christian Huitema huit...@microsoft.com
 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 shim between application and TCP.
 If I implemented this in the Windows kernel, I would use the existing kernel
 API. But I can see many other ways.
 
  Your specific question on certificate is a matter of profiles. EKR proposed
 ECDH anon with P256 and Curve25519. This is anonymous Diffie-Helman
 with elliptic curves. It does not involve any certificate at all.

 Your email talked about authentication. Was that going to interact
 with the shim, or just signal to the app that it should do TLS? If the
 second, what is the gain from using TLS over TCP instead of opting out
 of tcpcrypt if the app will do TCP?

 There are four scenarios, shim to shim, full to shim, shim to full, and 
 full to full, where full is a complete implementation of TLS and shim is 
 the subset. Obviously, shim to shim works as long as the two ends have the 
 same shim, and full to full works as long as the two ends implement TLS.

You didn't answer the question, but half of it. Okay, I'll provide the
other half, where we use tcpcrypt instead. We'll use two bits: will
offer tls, will offer tcpcrypt, and fall back to tls otherwise.


 Full to shim sees one client implementing full TLS, and presumably using an 
 IOCTL to disable the shim implementation. If the TLS options proposed by the 
 client are a superset of the TLS options used by the shim, and if the ENO 
 option is used right, we end up with the same TLS over TCP variant as shim to 
 shim.

So in my above proposal we end up with tcpcrypt protecting the
channel, as what was the shim indicates it wants tcpcrypt, and the
negotiation works.


 Shim to full sees one server implementing full TLS, presumably using some 
 start TLS variant. The shim is systematically disabled on the server's 
 sockets. The ENO option advises the server to switch on TLS, rather than wait 
 for the Start TLS message. As long as the TLS options accepted by the 
 server include the options proposed by the shim, we end up with the same TLS 
 over TCP variant as shim to shim.

This is symmetric with above. Or am I missing something? So once again
both proposals do the same thing. Can someone beat the donkey until it
decides?


 The obvious issue is the potential for downgrade attacks and MITM insertion, 
 but that's something LS has to deal with anyhow.

 -- Christian Huitema






-- 
Man is born free, but everywhere he is in chains.
--Rousseau.

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] Developer opinions matter

[Watson Ladd]

On Jul 24, 2015 11:06 AM, Eric Rescorla e...@rtfm.com wrote:



 On Fri, Jul 24, 2015 at 7:59 PM, John-Mark Gurney j...@funkthat.com
wrote:

 Eric Rescorla wrote this message on Fri, Jul 24, 2015 at 10:22 +0200:
I've been working on project to accelerate TLS by doing the framing
and encryption work in the kernel, and not in userland.  We made
the
choice of not moving the handshake and certificate validation into
the kernel due to it's complexity and high risk for bugs.  Yes,
tcpcrypt will have slightly more code than just framing and
encryption,
but it's vastly more simple than doing anything wrt parsing and
validating X.509 certificates.
  
 
  There's not going to be any need to do either of these. I'm working on
  the profile, but expect it to be anonymous (EC)DHE, and so not
  require certificates.

 Well, require and support are two different things.  Under chapter 10,
 you say:
 If some sort of external authentication mechanism was provided or
certificates are used

 This implies that certificates may be used.  What is going to happen
 if one side decides to require a certificate and the otherside rejects
 any certificate use?  Then we end up again, back to an unencrypted
 session, or worse (better?), failure to establish the session.

 I do realize that ladder diagram does not even mention the Certificate
 side of things, so probably the clause, or certificates, should just
 be removed.

 It should be tightened up to explicitly disallow any use of
 certificates, or at a minimum, that the side that presents a
 certificate but does not receive a correct response, must continue as
 if the certificate was ignored.


 Thanks for your comments.

 My thinking here is that I would like this mechanism to serve two
purposes:

 1. To allow for encryption in TCP at the system/kernel level.
 2. To let applications discover when TLS is available and upgrade to it

What was wrong with the tcpcrypt approach of letting applications discover
when the connection was encrypted already, and using X509 authentication
over that?

Let me broaden this: what features is tcpcrypt as it stands now not going
to provide that we need?


 In the former case, certificates are not useful but in the latter they
are.

 Perhaps what's needed is an indication in the initial extension handshake
 of the expectation vis-a-vis authentication

 -Ekr



___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] four more months... then pixie dust?

[Watson Ladd]

On Fri, Jul 17, 2015 at 10:37 PM, Andrea Bittau bit...@cs.stanford.edu wrote:
 I think that we can make progress as long as the format of the meeting
 isn't:


 Here's TLS-option ; Here's tcpcrypt ; Which should we use?


 Even though it's been a long stalemate, tcpcrypt itself did benefit from the
 WG

 and some progress has been made.  For example, at IETF 91 we (the WG)
 decided

 not to MAC the header.  At IETF 92 we decided to use TLV.  Both resulted in
 new

 tcpcrypt drafts and code.  I hope that at this IETF we can continue this
 design

 effort, though in a more concentrated way.


 It's clear that by November the WG needs to produce a substantial result and
 not

 just keep debating.  I suggest that we use this meeting to define this
 result.

 Specifically, we should:


 1) Define what we want from TLS-option (e.g., a profile?, code?, etc.).


 2) Define what we want from tcpcrypt (e.g., some handshake feature?).


 3) Discuss a generic start encryption TCP option that can select any

tcpinc protocol.


 For both #1 and #2 we should spend time designing and discussing the

 protocol (as if it were the only contender) to see WG dynamics when
 asked to

 work on a specific protocol.


 The protocols can then be developed in the coming months and in November we
 can

 check to see if one result is superior.  If none is, the generic start

 encryption option might be the best way forward, leaving it to natural

 selection to decide which particular encryption option becomes most popular.

This option has serious costs: it forces operating systems to ship
both stacks for compatibility reasons, and delays widespread adoption
and use even further. I used to think Buridan's Ass was a fable. Now I
realize it was prophecy.



 On Fri, Jul 17, 2015 at 1:01 PM, Stephen Farrell stephen.farr...@cs.tcd.ie
 wrote:



 On 17/07/15 18:31, Joe Touch wrote:
 
  I see your point, but would include other context in comparing the two
  approaches - e.g., based on well-established mechanisms vs. not, not
  implemented but relatively clean interaction with TCP vs. not, which
  puts them on a much more equal footing (which is part of why the WG has
  not converged).

 Yep, that's fair, I wasn't trying to include all context and the above
 points are clearly why deciding has been hard. My point though against
 option 1 is that deciding won't get easier in 4 months.

 S.

 ___
 Tcpinc mailing list
 Tcpinc@ietf.org
 https://www.ietf.org/mailman/listinfo/tcpinc



 ___
 Tcpinc mailing list
 Tcpinc@ietf.org
 https://www.ietf.org/mailman/listinfo/tcpinc



-- 
Man is born free, but everywhere he is in chains.
--Rousseau.

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

[tcpinc] Implementations

[Watson Ladd]

Dear all,

One of the selling points of the TLS option was how easy it would be
to implement: after all, we've already got TLS implementations and a
few kernel-level changes to permit userspace to set the option is all
that is required for an implementation. Yet I don't see an
implementation, which would make Nico's and Joe's contentions about
how to implement much clearer, along with other things.

Without working implementations, ideally deployed across a wide number
of networks, we can't actually determine all the terrible things that
can go wrong, and what the impact is. So far only tcpcrypt has this
data. I don't know that much about networking, so I'm sure there are
disadvantages of tcpcrypt that I'm not spotting, but I'm virtually
certain that we're better off testing middleboxes for compatibility
then talking about what they will and won't do, and having that
information inform an eventual decision about what to deploy.

Sincerely,
Watson Ladd

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [tcpinc] TCP-TLS latency SYN floods: kernel vs user-space

[Watson Ladd]

On Nov 17, 2014 10:42 AM, Joe Touch to...@isi.edu wrote:



 On 11/17/2014 12:27 AM, Bob Briscoe wrote:
  Ekr,
 
  There needs to be more behind the text on Implementation Options
  
https://tools.ietf.org/html/draft-rescorla-tcpinc-tls-option-00#section-5
 ...
  This has implications both for vulnerability to SYN floods and for
latency.

 It's not clear whether SYN floods are in-scope for these solutions.

Well, if you expect kernels to implement and users to deploy these
solutions, they shouldn't make security worse. Increased DoS vulnerability
will go a long way to making sure these solutions never see the light of
day.

Sincerely,
Watson Ladd
___
 Tcpinc mailing list
 Tcpinc@ietf.org
 https://www.ietf.org/mailman/listinfo/tcpinc
___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

[tcpinc] My analysis of the slides

[Watson Ladd]

Dear all,

I've looked at draft-bittau-tcp-crypt, and I'm not sure I understand
some parts. There are several possible ways to encode P-256 public
keys in SEC1: it's not clear which have to be supported, and if we
decide to include any new curves, something extra may need to be said.
The key size for RSA is underspecified: the paper uses 2048 bytes, but
the draft doesn't mention it.

The citation for PRF based MACs doesn't work in the case of
Poly1305-AES-128 xored AES-128, as Poly1305 isn't a PRF. I'm sure the
necessary result is true enough, but I'd have to do some work to show
it.

The DTLS and TLS proposals look very similar: why is one better than
the other? There is no word on what features have to be supported, or
guidance on what the kernel vs. the underlying application will do.

The TCP-AO variant as it currently stands uses a 16 byte DH exchange.
That's going to be very weak, even with elliptic curves. 32 bytes
minimum works. SEC1 is not a network byte order encoding, it's a fixed
length with a prefix. There is a lot missing from the draft: cipher
choices, how negotiation works.

If I had to implement one of these in the kernel, it would be the
bittau draft. It's much simpler then alternatives, has running code,
and comes with measurements of deployment effects. It explains how
application layer can use the TCP connection for authentication and
encryption by checking socket options.

Sincerely,
Watson Ladd

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc