Subject: [Tcpcrypt] Initial questions

From: Sandy Harris <[email-masked]>
Date: Wed, 18 Jun 2014 17:15:06 -0400

This is basically a fine idea & I'm glad to see people working on it.

Some comments in the archive had me somewhat worried, and the current
draft charter has the following:

- When encryption is enabled, it must at least provide protection against
  passive eavesdropping by default,
...
When encryption is enabled, then the protocol:
- must always provide forward secrecy.
- must always provide integrity protection of the payload data ...
- must always provide payload encryption.

Why on Earth do these have "When encryption is enabled"? As others
have said quite eloquently in various posts, there is no reason at all
to even consider a null encryption mode; anyone who needs that can
just fall back to TCP.

I'd go further. At a bare minimum, reject the insecure things
FreeS/WAN refused to do 15 years ago even though they were in the
IPsec RFCs -- single DES, small DH groups and null encryption.
http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/compat.html#dropped

Probably today we should go much further. No MD5 or SHA1 since there
are known problems. No 3DES since newer ciphers are far faster. No
reliance on the whole X.509 cert infrastructure SLL/TLS uses; that
also has known problems. I'm not sure what else.

The draft charter also has:

- The protocol must provide cryptographic algorithm agility.

OK, but there is a balance to be struck. IPsec & TLS both have
problems from arguably excessive complexity and in general complexity
is the enemy of security. It makes all of design, implementation,
testing & auditing much harder. TCPcrypt has a rather narrow niche to
fill; that can be done with a fairly simple protocol. We really must
strive to keep it simple.

Here's a first cut at what we might support:

Block ciphers: MUST do AES. SHOULD do the other three AES finalists
with open licenses: Mars, Twofish & Serpent. MAY do compatible ciphers
which are national standards: Aria for Korea, Camellia for Japan,
maybe others. Nothing else.

Overhead for those is minimal since they all have same block size as
AES and same range of key sizes, so they are drop-in replacements.
Also, all the AES candidates and Aria have readily available open
source code; I have not checked for Camellia.

Key size? I'd mandate 128 bits everywhere to keep it simple.

Authentication: The draft has:

- must always provide integrity protection of the payload data (it is open for
  discussion for the WG if the TCP header should or not be protected)

AEAD (authenticated encryption with additional data) algorithms have
partly replaced the cipher+HMAC combination in both IPsec and TLS.
They are often faster, and the "additional data" feature would let us
protect the TCP header at negligible extra cost. I'd say they are
obviously what we should use.

I'd just take two with existing RFCs -- AES-GCM RFC 5288 and OCB RFC
7253 --  and make them both MUST. Leave HMAC out to keep it simple.

The draft also has:

- Must gracefully fall-back to TCP if the remote peer does not support the
  proposed extensions

Aren't there a set of policy questions there? Some users might prefer
to drop the connection rather than communicate insecurely. Perhaps
they need a mechansim to set policy, globally and/or on a
per-connection basis. FreeS/WAN had something like this for IPsec over
a decade ago:
http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/policygroups.html

At an absolute minimum, I think there must be a requirement that any
fallback action is logged.

Another question is whether we could achieve the goals of this group
with almost no work just by deploying existing stuff.

The now-closed BTNS working group did RFCs 5386 & 5387 on "Better than
nothing security", which they implemented as an unauthenticated mode
for IPsec. That sounds much like what we are aiming at. Can we just
work on getting BTNS deployed, thereby protecting both TCP and other
protocols?

The draft has:

- Must not require any authentication or configuration from
applications or users. However, hooks for external authentication must
be made available.

RFC 4322 describes an authentication mechansim for IPsec opportunistic
encryption using keys stored in DNS. Could we make that the external
hook and fall back to BTNS if the right record is not found?

Even if we choose to avoid the complexity of IPsec and design
something specifically for TCP instead of just using BTNS, the idea of
using DNS for keys may be useful. I do not know details, but it looks
as though the DANE working group is doing this sort of thing:
https://datatracker.ietf.org/wg/dane/

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 18 Jun 2014 14:20:16 -0700

On Wed, Jun 18, 2014 at 2:15 PM, Sandy Harris <[email-masked]>
wrote:

> Why on Earth do these have "When encryption is enabled"?

 "Every once in a while, someone not an NSA employee, but who had
  longstanding ties to NSA, would make a suggestion that reduced privacy
  or security, but which seemed to make sense when viewed by people who
  didn't know much about crypto. For example, using the same IV
  (initialization vector) throughout a session, rather than making a new
  one for each packet. Or, retaining a way to for this encryption
  protocol to specify that no encryption is to be applied."

    -- John Gilmore

-- 
Tony Arcieri

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jun 2014 14:26:35 -0700

> to even consider a null encryption mode; anyone who needs that can

That's what "when encryption is enabled" means - i.e., there are (at 
least) two valid modes:

	use TCPCRYPT

	do not use TCPCRYPT

Regardless of what this WG develops, the latter will always need to be 
an alternative. The charter is perhaps being overly pedantic in noting 
that the gains claimed occur only when the methods indicated are in use.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jun 2014 14:36:42 -0700

Comments on your other points:

As to the specific algorithms and how many, we probably all agree that a 
small number of required algorithms is preferable. I think 2 is a good 
upper bound on the MUST algorithms, though.

Algorithm agility just means that the protocol isn't inherently 
dependent on any one algorithm, so that it can be extended in the future 
to support other algorithms - that seems prudent.

...
>    discussion for the WG if the TCP header should or not be protected)

If you don't protect the header, IMO you're not doing TCP security, and 
might as well use TLS.

> Aren't there a set of policy questions there?

Gracefully != silently

Gracefully != without regard for policy

I think the intent of the requirement is that graceful fallback needs to 
be supported, but not that it is either silent or the default - 
especially for associations indicated as preferring/requiring TCPCRYPT.

> work on getting BTNS deployed, thereby protecting both TCP and other

That's certainly one possibility, but IPsec protection isn't quite the 
same as TCP-level. IPsec won't create new keying material for each TCP 
connection, whereas a TCP-level solution might. IPsec solutions also 
often required tunneling over UDP for NAT traversal, whereas a TCP 
solution might not (e.g., if the TCP header is protected but not encrypted).

> hook and fall back to BTNS if the right record is not found?

It's possible, but TCP currently doesn't consult the DNS directly; 
inserting this dependence in a TCP-layer protocol could introduce 
additional delays.

Joe

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 19 Jun 2014 07:43:34 +0200

Yes, exactly what Joe said.

This is the extract of one email that cuased this particular piece of 
text in the charter:

On Thu, Mar 13, 2014 at 10:21:55AM +0100, marcelo bagnulo braun wrote:

(the original charter text used to say)

> - the protocol must gracefully fall-back to TCP if the remote peer
> does not support the proposed extensions
> - the protocol must always provide forward secrecy.
> - the protocol must always provide integrity protection of the

(then someone commented)

Cool! How do you reconcile the first point with the last two? If it falls
back to normal TCP, it would also need SSL or similar to always provide
forward secrecy and integrity protection.  Or is this part of the TCPcrypt
API that the application must be careful to check?

So, we changed it to what is currently in the charter.
Hope this clarifies this particular point.
Regards, marcelo

El 18/06/14 23:26, Joe Touch escribió:
> _______________________________________________
> Tcpcrypt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpcrypt
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 19 Jun 2014 07:58:43 +0200

below...

> Why on Earth do these have "When encryption is enabled"?

I replied to this in a separated email

> As others
> to even consider a null encryption mode;

The requirement for disabling encryption was removed from the charter.
The text above refers to the case when a TCPINC host is talking to a 
legacy host.

> anyone who needs that can
> just fall back to TCP.
>

Right, this needs more discussion. The other side of the coin is that if 
you dotn provide agility and a vulnerability is found in an algorithm, 
then you are in bad shape. So, i agree, we need to find the way to 
provide agility with minimum complexity (not sure if we will be able to 
make it simpler than what is already out there though)

> obviously what we should use.

mmm, the problem with securing the header is not about the performance 
of signing the header but about the impact to other aspects.
In particular, how this interacts with middleboxes? Clearly you cant 
protect the IP address and the ports as it would break nat 
compatibility. what about the other fields? well, there are some other 
boxes out there that do funny things with seq numbers (boxes coalescing 
segments), do we want to be compatible with those or not?
The other aspect realted to this is where we carry the MAC for each 
segment, in the payload or in an option? Do we have room in options to 
carry this for every segment? wouldnt people rather have more sack 
blocks? If we go for carrying the MAC in the payload, then it is much 
harder to secure the header. Again, all these are discussions we need to 
have. I personally dont have a clear position, i just dont find it 
obvious (i know some of you do)

> to drop the connection rather than communicate insecurely.

The main issue addressed here is incremental deployment. In early phases 
of deployment, a host needs to be able to communicate with legacy hosts. 
When wider deployment is available it can have stringent policies, i guess.

Regards, marcelo

---

From: ianG <[email-masked]>
Date: Thu, 19 Jun 2014 11:09:43 +0100

On 18/06/2014 22:20 pm, Tony Arcieri wrote:
> On Wed, Jun 18, 2014 at 2:15 PM, Sandy Harris <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

The problem with this view is that we can also do the same things to
ourselves, without the need of hints from the NSA.  If you take a big
room of experts, they've all got their hobby horses, their pet wishes.
The sum total of those pet features would result in a non-working
protocol, and half of those pet features would result in a mess --
perhaps working, sometimes secure.

Having said that, in this fertile ground, it is certainly easy for
groups like the NSA to influence and tilt certain directions.  But we
shouldn't be so quick to blame them.  It is the job of spooks to
interfere, and it is we that are at fault first and foremost by
providing a target-rich environment.

iang

---

From: ianG <[email-masked]>
Date: Thu, 19 Jun 2014 11:30:15 +0100

> draft charter has the following:

my 2c below.

> to even consider a null encryption mode; anyone who needs that can

Perhaps we can change the text to say more about what is meant:

   When TCPCRYPT mode is enabled, the protocol will provide a good stab
at the following:

  - must PFS
  - must integrity
  - must encrypt payload, and must block passive eavesdropping

etc.

> also has known problems. I'm not sure what else.

I don't think we need to enumerate the current fads on algorithms.
Everyone knows what is old and tired.  Currently the fad is
ChaCha20/Poly1305.  But in 3 years the new fad will be a CAESAR winner.
 Leave the WG some room to move with the times.

> - The protocol must provide cryptographic algorithm agility.

As previously written (ranted?), I'm adamantly against any such thing.
IMHO the protocol should provide precisely one and only one whole cipher
suite;  the truth, the whole truth and nothing but the truth!

For any issues that might arise, change the protocol.  Entirely.  You
will anyway ... so we need a way to negotiate the protocol number, from
1 to 2 to 3, etc.

> strive to keep it simple.

Nothing gets simpler than the ONE!

> Key size? I'd mandate 128 bits everywhere to keep it simple.

Even if I agreed with the above, I'd say, this is the job of the WG, not
to be listed in the charter at all.  Too low level.

> 7253 --  and make them both MUST. Leave HMAC out to keep it simple.

This is all the job of the WG, to come up with a suite.  Keep that
competition out of the charter, let the WG also have their fun ;-)

> http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/policygroups.html

Well, we want this stuff to spread like the plague.  So, I'd keep policy
well away from users.  Any switch provided to users just has a habit of
branching decision trees, interfering with something else in their daily
lives, and potentially causing the whole shebang to be switched off
until it works.

E.g., if there is to be some policy discussion I would frame it in these
terms for the charter:

  - there is to be zero confuguration load for the sysadm/user

> fallback action is logged.

Oh, sure.  That's like remembering to put air in tires, no need to say
that in the charter.

> work on getting BTNS deployed, thereby protecting both TCP and other

If it fits the charter, then let it be proposed -- in the WG ring.
Let's have a nice clean fight, no hitting below the belt, ...

Especially, I'd like a fast knockout in round 1.  If we can slide in
BTNS for the TCPCRYPT v1, and then have a better, later-gen
bells&whistles proposal for v2, then we could win twice over.

> hook and fall back to BTNS if the right record is not found?

Any external hook, that included?  That is, it is beyond scope how that
is done.  The point is to allow a later TLS drop-in replacement to
bootstrap over TCPCRYPT and allow a fuller authentication to work.

> https://datatracker.ietf.org/wg/dane/

Yep, but out of scope to specify which.  Only need would be to keep an
eye on the ways and make sure there are no snafus.

iang

---

From: ianG <[email-masked]>
Date: Thu, 19 Jun 2014 11:46:01 +0100

> upper bound on the MUST algorithms, though.

Actually, no.  I for one disagree.  There should be one true cipher
suite [0].

> to support other algorithms - that seems prudent.

If an exploit is found, then it's time to role out version 2.  You'll
need a way to negotiate the version anyway, may as well use it.

(I know it is popular to approximate the whole 'all' thing in WG-speak
and I'm happy to go down in flames on the rough consensus.)

iang

[0] http://iang.org/ssl/h1_the_one_true_cipher_suite.html

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 Jun 2014 10:55:58 -0700

> Actually, no.  I for one disagree.  There should be one true cipher

If you have only one, then if (or when) you urgently decide it's 
vulnerable and want an alternate you need to wait for deployment of an 
update (e.g., as happened to TCP MD5). That will undermine the utility 
of a solution.

That's why TCP-AO included two 'must implement' algorithms from the 
start, and why it's important to do so here as well.

Joe

---

From: ianG <[email-masked]>
Date: Thu, 19 Jun 2014 19:23:38 +0100

On 19/06/2014 18:55 pm, Joe Touch wrote:
> update (e.g., as happened to TCP MD5

MD5 isn't a good example.  It has been effectively deprecated by SHA1
(and SHA0 ;) as of around 1996.  MD5 was collision-cracked around 2004,
as reported at Crypto 2004 in Santa Barbara.

When did TCP have this 'urgent decision' ?  If it happened several years
after 1996, then what you have is a forewarning that was ignored.  If it
was after 2004, well, no amount of warning will do, and algorithmic
agility is a crutch that should be stripped away in order to focus
attention.

> ). That will undermine the utility
> of a solution.
> 

I'd like to see some historical evidence of when this actually made a
difference?  Yes, we understand the idea.  But we now have 20 years of
experience in Internet protocols.  We have data.  What does the data say
about algorithmic agility, in the field?

The closest I've seen is the backoff in TLS back to RC4.  But even that
only gets halfmarks because RC4 itself should have been deprecated ages ago.

iang

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 Jun 2014 11:35:06 -0700

...
> agility is a crutch that should be stripped away in order to focus

2004 was the first practical attack on MD5; the first draft of TCP-AO 
was 2007. It took another three years for the IETF sausage mill to 
generate a final result.

Given that TCP-AO was used mostly for router security, and nobody had 
reported a successful MD5-based attack in the wild, that's not bad IMO.

The primary problem with TCP MD5 was that it wasn't algorithm-agile.

...
> about algorithmic agility, in the field?

You're arguing two points at the same time.

1) use one algorithm

	I've already pointed out how that's dangerous; it prevents
	pre-deploying a backup when a given algorithm is deprecated.

2) don't have algorithm agility

	This is counter to your earlier post. If you consider
	that any one algorithm won't last forever, then ultimately
	we'll want a solution that can support different algorithms.

I don't like either of the above, but they're separate points.

Joe

---

From: ianG <[email-masked]>
Date: Fri, 20 Jun 2014 07:13:54 +0100

> reported a successful MD5-based attack in the wild, that's not bad IMO.

Right.  So it worked.  The reason it worked fine -- no attacks reported
until 2008 [0] -- was likely due to the lack of collision vulnerability
in a protocol.  There was no urgent decision, just useful caution.

> The primary problem with TCP MD5 was that it wasn't algorithm-agile.

That's to repeat your conclusion.  I'm asserting a different conclusion:
 the problem with the MD5 upgrade was a management one, not a real one.
 The maintenance of the protocol should have started the replacement
sometime before 2004.

>     pre-deploying a backup when a given algorithm is deprecated.

You've pointed out it is dangerous.  Can you provide historical evidence
for this claim?  We've debunked MD5 in TCP-AO.

If it never happened, can it be still called dangerous?

If there is one thing that actually we are quite good at, it is
selecting a single strong suite.  How about we concentrate on what
actually does go wrong, demonstrably, in protocols?

Complexity leads to failure in takeup, anyone?

>     we'll want a solution that can support different algorithms.

OK, we're agreed that life moves on.  As do security products.  Versions
upgrade.  Let's look at say SSL.  It has run from v1 - v2 - v3 - TLS 1.0
- 1.1 - 1.2 - 1.4.

At each of those changes, there are incompatibilities within.  In each
case, the client/server conversation has to negotiate which version the
other side is capable of talking, and (generally) prefer the latest.

In each version, there is a chance to move forward.  This chance to move
forward may be taken for:  protocol weaknesses, advances in the science,
features, speed increases, ... *and the cipher suite*.

Now look at the history of important fixes to SSL.  SSL v3 patch,
TLS/SNI, renegotiation bug, heartbleed, gotofail, debian random, etc.

In practice, we're replacing the in-place version because of other bugs,
and improvements, over time, faster than we're seeing any problem with
any of the well chosen algorithms.

So we may as well just do that:  have TLS v+1 ready to go.

Also note that automated upgrade is the way that everyone does stuff
these days, and it can easily move faster than our ability to roll out a
config change.

Anyone got any numbers on how long it takes Apple to upgrade 80% of
clients?  Can they beat the OODA loop of 3.5 years for SSL [1]?

> I don't like either of the above, but they're separate points.

Here's another one:  why do you care?

This is opportunistic encryption, anyway.  We get what we can for free.
 Why bother about the freak occurrence of an algorithm break when it can
be hit by MITM anyway?  When we're losing most of the marketplace to
slowness in install?

How are you going to tell people to switch, given that our problem space
is automatic operation, without people knowing?

Is there anyone here who feels that (say) ChaCha20/Poly1305 is at risk
of a sudden break?  Who doesn't feel safe in an opportunistic protocol
against mass surveillance unless there is a backup inside it?

iang

[0] http://wiki.cacert.org/Risk/History#MD5-Root
[1] http://financialcryptography.com/mt/archives/001210.html

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Jun 2014 15:23:30 -0700

On 6/19/2014 11:13 PM, ianG wrote:
...
> be hit by MITM anyway?  When we're losing most of the marketplace to

Two algorithms, with one as the preferred default is prudent as a 
pre-deployed backup...

> is automatic operation, without people knowing?

and it also helps us validate that the system can support other 
algorithms without major revision (i.e., we need an answer to this 
question, and the best way to test it is with two algorithms).

That's my view, and you've already disagreed with it; let's see what 
others have to say.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 20 Jun 2014 19:33:17 -0700

On Thu, Jun 19, 2014 at 10:55 AM, Joe Touch <[email-masked]> wrote:

> update (e.g., as happened to TCP MD5). That will undermine the utility of a
> solution.
>

Hey Joe,

Perhaps you should pay attention to 2014, and not look at things through a
historical glass, darkly.

In case you haven't been paying attention, vulnerabilities have been
accelerating at something of an exponential rate, and pretty much
everything that hasn't happened in 2014 is practically irrelevant at this
point.

Cipher agility is clearly not the problem. Implementation vulnerabilities
are the problem. In fact, the rate at which cipher vulnerabilities have
been discovered is practically glacial at this point.

Things have gotten a lot more complicated since MD5 is even a hash function
anyone with a clue would use for any reason whatsoever. Perhaps you should
stop referencing anything that has anything to do with MD5, period. It's
not germane to the discussion of any modern protocol, except perhaps if you
want to discuss historical failures.

-- 
Tony Arcieri

---

From: Derek Fawcus <[email-masked]>
Date: Sun, 22 Jun 2014 06:06:57 -0700

> That's my view, and you've already disagreed with it; let's see what 

I like the idea of the initiator being able to specify the crypto
algorithm, say an 8 bit value,  we have 1 or 2 intially defined.
If the receiver doesn't support the selected algorithm,
the whole tcpcrypt option will fail and we fallback to unencrypted.

Thereafter the initiator (application or host stack - not sure which)
can decide to terminate the connection,  and maybe retry with a different
algorithm,  continue unencryted,  or whatever.  i.e. local policy.

The idea being that we deploy with one recommended algorithm which
everyone supports,  and if a sucessful attack is found on it,  we
can switch over to the next algorithm.

I don't think the endpoints should negotiate the algorithm,
if the initiators choice is not supported,  the session is unencryted.
i.e. avoid round trips to agree/negotiate an algorithm,
and don't supply a list of choices in the initiation.

I'm not sure of the effect with simultaneous open,  but probably OK
until the recommended version changes.

.pdf

---

From: Derek Fawcus <[email-masked]>
Date: Sun, 22 Jun 2014 06:10:05 -0700

> and don't supply a list of choices in the initiation.

Or could one argue that the above is not too dissimilar to simply
having a version field in the tcpcrypt protocol,  and we can
associate a version with any set of crypto algorithms?

.pdf

---

From: Joe Touch <[email-masked]>
Date: Sun, 22 Jun 2014 18:05:00 -0700

>> if the initiators choice is not supported,  the session is unencryted.

Even if that's true, there can still be merit to picking from among a set of required algorithms during negotiation.

>> i.e. avoid round trips to agree/negotiate an algorithm,

Whether negotiation takes additional exchanges depends on the mechanism.

> associate a version with any set of crypto algorithms?

Once it's negotiated, it serves no purpose to continue to indicate it in the header. If parameters need to be renegotiated, that happens during the renegotiation.

Joe

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Jun 2014 10:45:20 -0400

Sandy,

> also has known problems. I'm not sure what else.
To which X.509 cert infrastructure problems are you referring? Do you
mean the Web PKI or PKI in general? IPsec, for example, does not make
use of the Web PKI. Just curious.
> strive to keep it simple.
I'm not sure what your position is re alg agility, based on the 
paragraph above.
I can say that failure to accommodate alg agility will almost certainly 
cause
the IESG to reject this as a standard, based on precedents for some time.

> maybe others. Nothing else.
why would one make the other AES finalists SHOULD? They didn't make the cut.
> Key size? I'd mandate 128 bits everywhere to keep it simple.
recall that AES has 256-bit keys as an option as a counter to possible
quantum computing attacks. Why rule out that option?
> http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/policygroups.html
This is a different context. I believe the goal is to try to negotiate
use of encryption silently, and thus failing silently makes sense. There
was a session in the STRINT workshop that addressed a topic very close
to this. It's conclusion was to fail silently (and to use PFS, and ...)
> fallback action is logged.
And who will check the logs? A log on a user machine will likely go
unread in 99.99% of cases, unless there is a plan to submit the logs
to some central monitoring source. But that would raise a set of
privacy questions, so ...

> with almost no work just by deploying existing stuff.
Always a good question.
> work on getting BTNS deployed, thereby protecting both TCP and other
I think the folks who pursue BTNS are best-equipped to address that
question. Ask Sam Hartman, maybe Joe would like to comment as well.

Steve

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Jun 2014 11:22:27 -0700

...
> question. Ask Sam Hartman, maybe Joe would like to comment as well.

RFC5925 already describes the rationale for TCP authentication vs. 
IPsec. The same issues are relevant for TCP encryption.

The other aspect of BTNS - use of DH without authentication (which isn't 
TOFU; it's trust-on-any-use in a sense because IDs aren't retained) 
might be similar to various approaches offered here (e.g., it's the 
basis of draft-touch-tcp-ao-encrypt.

Joe

---

From: ianG <[email-masked]>
Date: Tue, 24 Jun 2014 20:19:03 +0100

...

...

> the IESG to reject this as a standard, based on precedents for some time.

Interesting point!  Probably worth reaching out to those folk and asking
whether they are serious about enforced alg agility.

And why they care so much in the context of TCPcrypt, which is
opportunistic anyway, and as such provides not much of a guarantee.

...
>> Key size? I'd mandate 128 bits everywhere to keep it simple.

(In the charter, we shouldn't mandate any size.  Just let the proponents
walk the gauntlet with their choices.)

> quantum computing attacks. Why rule out that option?

Because this is TCPcrypt.  The enemy is the unavailability of any
encryption at at all, not the QC bogeyman.

If we deploy TCPcrypt to 99% of all nodes, and they're all vulnerable to
QC, we still win.

(Because, to spell it out, we can always upgrade later on when the
bogeyman starts deploying QC in the mega-scale, and meanwhile we won
against everyone else.)

> use of encryption silently, and thus failing silently makes sense.

(concur.)

iang

---

From: Sandy Harris <[email-masked]>
Date: Tue, 24 Jun 2014 16:22:04 -0400

> use of the Web PKI. Just curious.

I said SSL/TLS, implying the web. I think there are more general problems
in PKI -- see some of Peter Gutmann's comments, for example -- but
those are not relevant here.

> I'm not sure what your position is re alg agility, based on the paragraph
> above.

I wrote "OK, but ..".

> cause the IESG to reject this as a standard, based on precedents
> for some time.

OK, we need some agility, both because it is a good safety measure
and because IESG will likely insist.

BUT the fewer choices there are, the simpler the protocol can be.
That has costs in "design, implementation, testing & auditing" &
extra options may mean a risk of downgrade attacks.

IPsec has a lot of arguably unnecessary complexity -- pre-shared
keys or public keys, main mode or aggressive mode, with or
without PFS, actual encryption or do the whole negotiation and
then use null encryption, ... Such things should be flatly rejected
here; just choose one secure option.

As for cipher suites, we need at least two to test the agility and
the negotiation part of the protocol. On the other hand, having
fewer makes it simpler. I conclude we should have exactly two
MUST implement algorithms per choice.

> why would one make the other AES finalists SHOULD? They didn't make the cut.

They are easy to add, patent-free and with open source software
readily available, and they have had lots of analysis. Maybe make
one a MUST (I'd pick Serpent) and the others MAY.

> quantum computing attacks. Why rule out that option?

The protocol can be simpler if it does not negotiate key size. Make it
256 everywhere, perhaps, but don't complicate the protocol.

If quantum attacks become feasible, my understanding is that
more-or-less everything we are likely to use would become
vulnerable: DH, RSA, ... We'd need a new version no matter
what symmetric ciphers were in play.

Anyway, this is an opportunistic encryption protocol which blocks
easy wholesale monitoring. Its essential goals do not include
resistance to more sophisticated attacks, whether MITM or
quantum.

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Jun 2014 13:31:11 -0700

On 6/24/2014 1:22 PM, Sandy Harris wrote:
...
> easy wholesale monitoring.

Of content. Nothing in the charter ensures protection of the meta 
information (endpoints addrs or ports), nor is traffic confidentiality 
required.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Jun 2014 01:17:53 +0100

Hiya,

> and because IESG will likely insist.

Planning for what to do on the basis of what the IESG might
conclude at this level of detail is not a great plan. For
example, by the time the spec reaches the IESG the relevant
folks may have changed (I'm one of 'em for now btw) and/or
opinions as to the desirable mechanisms for algorithm
agility could have changed somewhat.

> extra options may mean a risk of downgrade attacks.

There is a separate (sporadic) discussion on the saag list about
this. [1] Russ has written a draft trying to capture algorithm
agility in the form of a BCP. iang isn't keen but may so far be
in the rough. OTOH, we do have issues - its just dumb that there
are 300+ TLS ciphersuites, even with the combinatoric explosion,
and then there's vanity/national crypto as well that might also
be thought of differently here, or not, we'll see.

So basically, I'd say leave this one until the WG which I hope
will be formed very shortly gets to discussing its protocol
details. And at that point I hope we see an argument about what's
the right thing to do.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Jun 2014 12:04:35 +0100

Sorry, I omitted the link to the saag discussion about
algorithm agility (thanks Marcelo for spotting that).

The initial thread starts at [1], and iang's disagreement
at [2].

S.

[1] https://www.ietf.org/mail-archive/web/saag/current/msg04844.html
[2] https://www.ietf.org/mail-archive/web/saag/current/msg04960.html

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 27 Jun 2014 15:37:33 +0300

ianG writes:
> > I can say that failure to accommodate alg agility will almost
> > certainly cause the IESG to reject this as a standard, based on
> > precedents for some time.
> 

I at least think that we do need algorithm agility. We do not need to
deploy multiple algorithms, but we need option to be able to implement
multiple algorithms and select common one between peers. 

> opportunistic anyway, and as such provides not much of a guarantee.

To provide upgrade path. 

> bogeyman starts deploying QC in the mega-scale, and meanwhile we won

So you seem to prefer algorithm agility yourself, by saying "we can
always upgrade later". To be able to upgrade later do require
algorithm agility.

When we need to do upgrade that will take YEARS, or DECADES, as we
need to update every single implementation in the world. This means
that upgrade is never done completely, there will most likely always
be old devices which have not been updated, thus future devices need
to be able to talk to old and new devices both, thus requiring
algorithm agility.

IKEv1 was obsoleted 2005 and replaced with IKEv2. Still lots of
implementations only support IKEv1, even when it is quite broken (and
I know Dan will disagree with me about this, but in my personal
opinion IKEv1 is quite broken, there is no point of arguing it here,
IKEv2 is much better protocol), and even those which support IKEv1 and
IKEv2 still use IKEv1 as default because the IKEv1 didn't have good
enough algorithm agility, i.e. there was lots of implementations who
just drop all packets whose version number is not 1.0 causing timeout
if you start out with IKEv2. Also lots of people when they comment
about IKE list the problems in the IKEv1 which were already fixed in
IKEv2.

Another example is that SSL 3.0 is still used in some implementations
even when newer versions of TLS have been out for some time. If you
now go and only allow connections using TLS 1.2 there will lots of
clients who cannot connect to you anymore, and TLS 1.2 came out 2008.

With these examples about IKEv2 and TLS 1.2, I am trying to tell you
that upgrading protocols takes lots of time, especially if there is
new protocol version involved. Its much easier to implement new
ciphers etc with old protocol than to deploy completely new protocol.
Thus algorithm agility is important feature, and it needs to be there
from the beginning, otherwise we are stuck with the first version for
long time.
-- 
[email-masked]