Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

From: "Holland, Jake" <[email-masked]>
Date: Thu, 2 Feb 2017 22:16:23 +0000

Hello tcpinc members,

I’m new to the group, and joined at Kyle and David’s invitation to give a review of this draft before the WGLC expires:
"TCP-ENO: Encryption Negotiation Option"
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/

The doc mostly looks pretty good to me. I couldn’t find anything that would make it impossible to transport data and opportunistically encrypt it with ENO where available, nor anything inherently dangerous for an app that doesn’t use any ENO-specific API extensions, but which is running on a network stack that silently turns on ENO underneath.

A few suggestions that I think might improve the doc:

1. There should be a MUST for an API that an application can use to discover whether a connection ended up encrypted, unless it’s there and I missed it. I couldn’t find one in the doc, but it seems a likely vital point for anything that satisfies the application-aware definition.

2. I’d like to see a section that lists a use case or 2 that can be solved by knowing the remote host’s a-bit (or with the mandatory application-aware mode), and how the a-bit solves them. I assume I’m missing something obvious, but I haven’t been able to come up with a use case that does anything useful with the remote a-bit.
(An example guess: is the whole point so that you can avoid sending sensitive data if the remote app itself hasn’t done anything to become secure? And if so, is there some reason the application-layer protocol shouldn’t be in charge of determining that?)

3. All 3 instances of “manual(ly)” in the doc seem better if changed to “explicit(ly)” (sections 4.2 and 7.4)

4. In section 7.1, the hopes of increasing TCP’s SYN option space seem exaggerated. EDO does not apply to SYN, and of the other 2 cited drafts, one is expired over a year ago and the other looks, I guess I’d call it "tricky", in addition to being experimental. It might be better to remove the second and third paragraphs of section 7.1, or at least reduce to just the one example of a live and applicable draft (and maybe noting that it’s experimental).

I hope that helps.

- Jake

---

From: David Mazieres <[email-masked]>
Date: Thu, 02 Feb 2017 21:14:01 -0800

> A few suggestions that I think might improve the doc:

Thanks for going through the document.

> 1. There should be a MUST for an API that an application can use to
> discover whether a connection ended up encrypted, unless it’s there
> and I missed it. I couldn’t find one in the doc, but it seems a likely
> vital point for anything that satisfies the application-aware
> definition.

This is a good catch.  There used to be a requirement that
implementations MUST provide an API for getting the session ID that MUST
give an error if the connection is not TEP-encrypted, but I think this
got moved into the informational API draft.  The natural place to
mention this would be section 9 (security considerations).

> 2. I’d like to see a section that lists a use case or 2 that can be
> solved by knowing the remote host’s a-bit (or with the mandatory
> application-aware mode), and how the a-bit solves them. I assume I’m
> missing something obvious, but I haven’t been able to come up with a
> use case that does anything useful with the remote a-bit.

This is mentioned in the second paragraph of section 9 ("applications
MAY use the application-aware bit to negotiate the inclusion of session
IDs in authentication.")  However, if you think the point is worth
making more explicitly, maybe a place to do this would be in a new
subsection of 7 (design rationale).

> (An example guess: is the whole point so that you can avoid sending
> sensitive data if the remote app itself hasn’t done anything to become
> secure? And if so, is there some reason the application-layer protocol
> shouldn’t be in charge of determining that?)

Actually the point is to enable incremental steps towards security
legacy protocols.  Let's say that today some protocol X sends plaintext
authentication cookie.  With TCP-ENO, at least the cookie isn't
available to a passive eavesdropper, but it's still not very secure.  So
you use the application-aware bit to signal that instead of a cookie,
you will send a MAC of the session ID under the cookie, thereby keeping
the cookie secret.  Then in a few years, once everyone is always setting
the application-aware bit, you disable the old authentication behavior
or issue some warning, or provide some sort of application-aware pinning
mechanism to prevent rollback attacks.

The application-aware bit is what allows this incremental improvement in
security to happen without a flag day, because having a flag day would
be a show stopper for a lot of legacy protocols.

Does that make sense?  And does it merit its own section 7.6 or
something?

> to “explicit(ly)” (sections 4.2 and 7.4)

That's an easy change.

> 4. In section 7.1, the hopes of increasing TCP’s SYN option space seem
> exaggerated. EDO does not apply to SYN, and of the other 2 cited
> drafts, one is expired over a year ago and the other looks, I guess
> I’d call it "tricky", in addition to being experimental. It might be
> better to remove the second and third paragraphs of section 7.1, or at
> least reduce to just the one example of a live and applicable draft
> (and maybe noting that it’s experimental).

I agree that large SYN options seem like kind of a long shot, but if
they ever happen, ENO stands to benefit.  So part of the point here is
to make it unambiguous that ENO would benefit from large SYN options and
is ready to take advantage of them, because A) it's true, and B) it
could potentially strengthen the case for current or future large option
designs.

Is there harm in doing this?  E.g., is it bad practice to cite internet
drafts (non-normatively, of course) in an RFC?

David

---

From: "Holland, Jake" <[email-masked]>
Date: Sat, 4 Feb 2017 00:13:08 +0000

Hi David,

Thanks for the response.

I’ll try to give a deeper explanation on what I’m thinking on points #2 and #4 (“a-bit” and the draft-citing), and see if it leads to any further clarity or easier consensus.

Sorry for the length, and please don’t feel a need to respond to each individual part of this message. This is meant to give a coherent picture of the thinking and assumptions behind my objections, in hopes that you can more easily narrow in on examples that will best help to clear up any mismatches.

2. a-bit use cases/flag day avoidance:

I’m struggling to think of an example protocol that would need the a-bit to implement this kind of incremental increase in security.

The examples I’ve considered that run over TCP all do a feature (or version) negotiation in a handshake of some sort, then settle on a set of options that both sides understand, specifically so they can avoid flag days when making future upgrades.

In protocols that follow that practice, I’d expect that if they upgraded to add functionality for using the ENO session ID during authentication, the new protocol extension would add a new field type with a very specific meaning, probably with more than 1 bit of information (including for example which specific hash to use).

I’m also trying to think about the consequences if the protocol X in your example made such an extension by relying on the a-bit, and I keep running into reasons for concern.

2.a. A scenario for illustration:

For instance, maybe next year somebody reads about ENO and decides to upgrade protocol X, their proprietary gaming application protocol, so that Xv2 will be identical except that the passphrase will now be HMAC-MD5 of passphrase+sessionID if and only if the remote connection sets the a-bit, instead of just the cleartext passphrase. Your example exactly, I think.

They roll out the upgrade and tell their boss that even though many kinds of upgrades are impossible for them without a flag day, this one is safe and will secure their communications, so now they can finally transmit credit card info to their servers from clients that are running on an encryption-capable network stack. They run it that way for a few months, then a new attack on MD5 is discovered, and they realize it really should have been SHA-256 these days. Under the same logic that argues protocol X needs the a-bit, would the z1 bit in ENO be assigned for a second level of backward compatibility so that protocol Xv3 can distinguish between the SHA-256 and the MD5 hashes? I assume not, but this is part of why I’m struggling.

This example didn’t seem very compelling to me, so I was hoping that access to a real life example that needs the a-bit for this kind of backward compatibility would make it easier for me to follow the intended usage.

2.b. Another different example with a different problem:

Suppose I write an app that talks to servers I don’t own, and my OS has the recommended API feature from 4.7 (“implementations MAY provide a per-connection mandatory encryption mode that automatically resets a connection if ENO fails”), so my app tries one connection with mandatory encryption, then on failure with the right error code, I retry without encryption and with a reduced feature set of things I’m willing to send to the server. However, I don’t have time to implement session ID authentication, and the server wouldn’t accept it anyway.

Should my app set the a-bit? I think this version of the ENO draft says yes, because I have altered my behavior in the presence of encrypted TCP (and it wasn’t practical for me to authenticate, so I qualify as an exception for the first SHOULD from 5.1). I publish my app this way, and it’s downloaded by a few hundred folks with accolades about my security-consciousness.

However, a few years later the owners of the server side read section 9’s “applications MAY use the application-aware bit to negotiate the inclusion of session IDs in authentication”, and they roll out a new version that uses this by folding in new semantics for the authentication field, plus a blog post about the new meaning of application-awareness and how to upgrade to a new version of someone else’s more-popular app that incorporates these authentication semantics, and explains what the authentication using session IDs now look like.

Now my app’s authentication has a different meaning from the server’s and I start getting rejected on authentication until I can roll out an emergency upgrade, because I’m setting the a-bit but I wasn’t coordinated with the server’s upgrade.

In this scenario, I think the a-bit hasn’t avoided the flag day, and the reason is because of semantic confusion over the proper use of the a-bit, but everybody followed the rules as laid out in this draft.

Therefore, there must be some problem either with my understanding of what’s allowed or with the rules in the draft.

2.c. a-bit summary

I think it’s likely I’m missing something, and I’m hoping that a real life example and a use case walk-through of a scenario where it’s expected to help (and maybe also an explanation of how the scenarios like the above 2 are avoided under a correct reading of the draft) will help clear things up.

But if it turns out this is a real issue, I think this problem goes away without having to change any implementations if you cut out section 9’s “To preserve backwards compatibility, applications MAY use the application-aware bit to negotiate the inclusion of session IDs in authentication.”. 

Instead, by leaving the authentication negotiation to the higher level protocol, where they’ll most likely want to do it anyway, the responsibility for negotiating it backwards-compatibly falls entirely to the higher level (even though the SHOULD from 5.1 remains in place and recommends that the session ID be used as part of the authentication where practical).

If you think it’s important to state that the a-bit might be involved in the decision, another alternative is perhaps to change to a negative requirement, with something like: “applications SHOULD NOT try to use the session ID in the authentication unless the remote host sets the a-bit” instead of the backwards compatibility sentence from section 9.

The negative formulation to me does not imply that it’s safe to assume that the a-bit can serve as the sole form of negotiation about the authentication format at the higher level. However, I’m not sure how useful it is, since presumably a non-aware application won’t accept a session-ID-based authentication anyway, unless it’s because they just never changed their code to set the a-bit. (In which case if the higher level negotiates a session-ID-based authentication method and both sides agree, they could use it regardless of whether the a-bit is set, and it would be pointless to prevent them from doing so by adding this negative clause. What am I missing here?)

I don’t see a way the a-bit is harmful in itself, but I haven’t yet understood a case where it can safely be used for the backward-compatibility purpose highlighted in section 9 of the current ENO draft.

So can you please point me to a real-life example protocol that needs the a-bit for backward compatibility? Thanks.

4. citing drafts in support of future large SYN options:
“Is there harm in doing this?  E.g., is it bad practice to cite internet drafts (non-normatively, of course) in an RFC?”

4.a. Citing drafts does go against the current BCP, as I understand it.

From https://tools.ietf.org/html/rfc2026#section-2.2, in a big star-box:
“Under no circumstances should an Internet-Draft be referenced by any paper, report, or Request-for-Proposal, nor should a vendor claim compliance with an Internet-Draft.”

There’s a partial exception right afterward, which I’m not sure how well it applies in this case:
“
   Note: It is acceptable to reference a standards-track specification
   that may reasonably be expected to be published as an RFC using the
   phrase "Work in Progress" without referencing an Internet-Draft.
   This may also be done in a standards track document itself as long
   as the specification in which the reference is made would stand as a
   complete and understandable document with or without the reference to
   the "Work in Progress".
“

4.b. the moral case for truth in advertising:

That said, I do think it’s reasonable to make the point that extending SYN option space would benefit ENO, and to point to evidence of ongoing work in that direction, even if it’s a long shot.

I also agree that one of the cited drafts is legitimately attempting something that would help ENO in this way if it continues to move forward (https://tools.ietf.org/html/draft-touch-tcpm-tcp-syn-ext-opt-06). In my original comment, one of the 2 alternatives I suggested as an edit was to continue to cite that draft, but to point out that it’s experimental.

However, I think 2 of the citations currently used as evidence are misleading, one of them because it shows no signs of moving forward toward any form of adoption (https://tools.ietf.org/html/draft-briscoe-tcpm-inspace-mode-tcpbis-00), and the other because it does not apply to SYN or SYN-ACK (https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-07), and therefore wouldn’t help ENO’s use case. That is why I suggested cutting them out. (Or alternatively, if this weakens the point by so much it’s not worth making, to cut out the paragraphs that rely on it.)

My underlying concern here is that someone might take hope from this section and try to push their luck by putting keys into the SYN option with a length near the lower edge of what’s OK for security, in hopes that by the time it’s a real problem they’ll get an extension on the option space, rather than wrestling with the likely-harder problem of sending the keys in the payload.

But in practice, the option space in SYN is likely to be even less than what’s pointed out in this draft, because if you leave window-scale, timestamps, and sack-permitted out of your SYN, you’re likely to lose more on performance than any gains you might have made by getting a key into the SYN.

In my experience, this is exactly the kind of subtle early misunderstanding that can lead a team to spend 6+ months developing something, then abort the project once they discover it cannot be made both performant enough and secure enough under the constraints of an early design decision.

Therefore, I would prefer this doc not to present a rosier-than-reality picture of the likelihood that a future development will make large SYN options available.

To take that a little further, I’d almost rather see an explicit warning that provides clear support for a claim like “You cannot fit a cryptographically secure key into the SYN option unless and until further standards work makes it possible to have more space there. Don’t try, you’ll regret it.”

It’s kind of a minor point to get this much discussion, but that’s a more complete explanation of my objection.

I hope that helps.

-Jake

On 2/2/17, 9:14 PM, "David Mazieres" <[email-masked]> wrote:

That's an easy change.

David

---

From: David Mazieres <[email-masked]>
Date: Fri, 03 Feb 2017 18:27:04 -0800

"Holland, Jake" <[email-masked]> writes:

> For instance, maybe next year somebody reads about ENO and decides to
> upgrade protocol X, their proprietary gaming application protocol, so
> that Xv2 will be identical except that the passphrase will now be
> HMAC-MD5 of passphrase+sessionID if and only if the remote connection
> sets the a-bit, instead of just the cleartext passphrase. Your example
> exactly, I think.

I guess the problem here is that protocol X might not have a way to
negotiate some new authentication mechanism, so you need some kind of
flag to do this.  The "a" bit solves that problem.  However, as you
point out, the "a" bit is a one-shot mechanism, so whatever behavior
change it triggers should have some crypto agility/negotiation facility.
In the case that you are replacing passwords, I think that's okay,
because an MD5 hash will be 32 hex digits while a SHA-256 one will be
64.  But it would be better to say "md5:XXX" or something for even more
future flexibility.

Would it address your concern if we say that when use of the "a" bit is
required to slot in a new authentication mechanism, the new mechanism
should allow some crypto agility or negotiation mechanism for future
compatibility?

> Suppose I write an app that talks to servers I don’t own, and my OS
> has the recommended API feature from 4.7 (“implementations MAY provide
> a per-connection mandatory encryption mode that automatically resets a
> connection if ENO fails”), so my app tries one connection with
> mandatory encryption, then on failure with the right error code, I
> retry without encryption and with a reduced feature set of things I’m
> willing to send to the server. However, I don’t have time to implement
> session ID authentication, and the server wouldn’t accept it anyway.

The mandatory encryption mode is not intended to serve a security
function, but rather to enable TEPs to optimize connection setup using
SYN data.  An example use case would be that you are connecting to an
NFS server that you know supports TCP-ENO, so you might as well do the
key agreement right in the SYN exchange if some future TEP supports it.
(We can't allow such an optimization by default because it reduces
backwards compatibility with TCP.)

> Should my app set the a-bit? I think this version of the ENO draft
> says yes, because I have altered my behavior in the presence of
> encrypted TCP (and it wasn’t practical for me to authenticate, so I
> qualify as an exception for the first SHOULD from 5.1). I publish my
> app this way, and it’s downloaded by a few hundred folks with
> accolades about my security-consciousness.

You definitely should not set the "a" bit.  The "a" bit is there if you
need it, but there is (or should be) no implication that you "SHOULD"
set it in cases where it is not required.  Header bits are a precious
resource, so if anything applications SHOULD NOT use the "a" bit if they
do not need to.

So perhaps the clarification is that you SHOULD avoid using the "a" bit
unless you absolutely need to, and when you do use it, since there's
only one "a" bit, you SHOULD slot in a mechanism that has hooks for
future compatibility.

> 2.c. a-bit summary
>
> I think it’s likely I’m missing something, and I’m hoping that a real
> life example and a use case walk-through of a scenario where it’s
> expected to help (and maybe also an explanation of how the scenarios
> like the above 2 are avoided under a correct reading of the draft)
> will help clear things up.

I guess a real-life example might be a kerberos protocol that protects
data with DES encryption and a weak MAC.  You could specify that, when
both sides set the "a" bit, two things happen:

        1) the endpoints omit the DES encryption and weak MAC (which are
           superseded by TEP encryption), and

        2) the authenticator format is altered to replace the subkey
           field (that, in the absence of TCP-ENO, specifies a key with
           which to encrypt session data) with the TCP-ENO session ID to
           prevent man-in-the-middle attacks.

Obviously this is just an example, and the decision on the exact
interpretation would fall to whoever on the kerberos team is extending
the kerberos protocol.  I'm sure it would involve lots of trade-offs I'm
not thinking of.  But the point is that this is the kind of thing people
might want to do, and they need an extra bit in order to do it.

I don't want to put such a concrete example in the ENO RFC, because we
would be stepping on the toes of the RFC4120 authors.  The point of the
"a" bit is to give people options.  There are scenarios where the "a"
bit can be put to good use.  There are scenarios where the "a" bit is
not needed.  And there are scenarios in which the "a" bit can
effectively be wasted on some trivial feature, leaving people later to
regret that they can't use it for something more important.  But one bit
is still better than zero bits, and if paired with some other
negotiation mechanism, a single bit is sufficient to provide future
adaptability.

Does that help?

> “Is there harm in doing this?  E.g., is it bad practice to cite internet drafts (non-normatively, of course) in an RFC?”

Okay, I think you've convinced me to go with standard practice and avoid
citing internet drafts.

David

---

From: "Holland, Jake" <[email-masked]>
Date: Sat, 4 Feb 2017 07:19:54 +0000

>resource, so if anything applications SHOULD NOT use the "a" bit if they

This answer has a big part of the insight I needed, thanks.

>only one "a" bit, you SHOULD slot in a mechanism that has hooks for

(UIC = Updated-insight Comment)

UIC #1: Yes, something that conveys the above message effectively would be a key edit, I think.

UIC #2: On a related note, I will point to the initial definition for the a-bit in section 4.2:
      The application-aware bit "a" is an out-of-band signal indicating
      that the application on the sending host is aware of TCP-ENO and
      has been extended to alter its behavior in the presence of 
      encrypted TCP.  

I think this initial definition doesn’t convey the right semantics for the backward-compatibility that you’ve outlined as the primary purpose for this bit, and it probably needs to do so. This is the main reason I thought the draft said my example app should set the a-bit.

If the a-bit is intended to be used as a mechanism for backward compatibility for legacy protocols that didn’t have one built in previously, in order to avoid misunderstandings I think you’ll need to make that point in a more specific and deliberate explanation of that purpose. Ideally, somewhere there will also be good recommendations on how to achieve a smooth transition, and probably an applicability paragraph or sub-section that outlines the key characteristics of protocols that can derive a benefit.

UIC #3: On another related note, I will also add that I think “application aware” is a misnomer for these semantics.

When a higher-level protocol is extended in a way that makes use of this feature, the updated protocol specification should define how updated apps must behave in order to comply with the updated protocol, and should do so with a definition that permits interoperability with the prior version of the protocol.

This is not about any choices an application makes or any awareness that an application has, except in the sense that the application risks incompatibility if it sets the bit without reference to an updated version of the protocol specification that defines semantics for how each side should handle a matched a-bit.

So this is perhaps something like a “Legacy protocol upgraded” bit, which should be set only when a higher level protocol has been updated by a new specification that defines the semantics for how to interpret the bit within the new version of that protocol.

I know that’s a lot of wide-ranging edits to propose, and I’m sorry about that. But I do think that making this point a lot more clear in the document would make a big difference in avoiding confusion.

Thanks for taking the time to understand my objections fully and explain the misunderstandings patiently. I think this is a very good doc, and I hope this discussion has been helpful in improving it a little further.

- Jake

---

From: David Mazieres <[email-masked]>
Date: Sat, 04 Feb 2017 11:40:45 -0800

Okay, here is some proposed language.  For the definition of the "a"
bit:

   a
      Legacy applications can benefit from updating their behavior to
      take advantage of TCP-level encryption, for instance by improving
      endpoint authentication or avoiding double encryption.  The
      application-aware bit "a" is an out-of-band signal that such
      applications can use to indicate support for ENO-specific updates
      when high-layer protocols lack a backwards-compatible means of
      doing so.  Implementations MUST set this bit to 0 by default, and
      SHOULD provide an API through which applications can change the
      value of the bit as well as examine the value of the bit sent by
      the remote host.  Implementations SHOULD furthermore support a
      _mandatory_ application-aware mode in which TCP-ENO is
      automatically disabled if the remote host does not set "a = 1".

For security considerations:

   Achieving stronger security with TCP-ENO requires verifying session
   IDs.  Any application relying on ENO for communications security MUST
   incorporate session IDs into its endpoint authentication.  By way of
   example, an authentication mechanism based on keyed digests (such
   Digest Access Authentication [RFC7616]) can be extended to include
   the role and session ID in the input of the keyed digest.
   Applications MAY use the application-aware "a" bit to negotiate the
   inclusion of session IDs in authentication even when there is no in-
   band way to carry out such a negotiation.  Because there is only one
   "a" bit, however, a protocol extension that specifies use of the "a"
   bit will likely require a built-in versioning or negotiation
   mechanism to accommodate crypto agility and future updates.

Added the third sentence to the first paragraph of 5.1 (Session IDs):

   Each TEP MUST define a session ID that is computable by both
   endpoints and uniquely identifies each encrypted TCP connection.
   Implementations MUST expose the session ID to applications via an API
   extension.  The API extension MUST return an error when no session ID
   is available because ENO has failed to negotiate encryption or
   because no connection is yet established.  Applications that are
   aware of TCP-ENO SHOULD, when practical, authenticate the TCP
   endpoints by incorporating the values of the session ID and TCP-ENO
   role (A or B) into higher-layer authentication mechanisms.

So now it is clear that you can check for an error on the call to
retrieve the session ID (meaning TCP-ENO succeeded if and only if you
get a session ID).

I also got rid of the citations to internet drafts.  Now 7.1 (future
developments) reads:

   Various proposals exist to increase the maximum space for options in
   the TCP header.  Though these proposals are highly experimental--
   particularly those that apply to SYN segments--TCP-layer encryption
   could significantly benefit from the availability of increased SYN
   option space.  In particular, if future TEPs can perform key
   agreement by embedding public keys or Diffie-Hellman parameters
   within suboption data, it will simplify protocols and reduce the
   number of round trips required for connection setup.  With large
   options, the 32-byte limit on length bytes could prove insufficient.
   This draft intentionally aborts TCP-ENO if a length byte is followed
   by an octet in the range 0x00-0x9f.  Any document updating TCP's
   option size limit can also define the format of larger suboptions by
   updating this draft to assign meaning to such currently undefined
   byte sequences.

I also changed manual to explicit, as you suggested.

Thanks,
David

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sun, 5 Feb 2017 06:57:09 +0000

[CCing TCPM for the part that matters to TCPM]

> “Is there harm in doing this?  E.g., is it bad practice to cite internet
> drafts (non-normatively, of course) in an RFC?”
> 
> “Under no circumstances should an Internet-Draft be referenced by any paper,
> report, or Request-for-Proposal, nor should a vendor claim compliance with an
> Internet-Draft.”
> 
> That said, I do think it’s reasonable to make the point that extending SYN
> option space would benefit ENO, and to point to evidence of ongoing work in
> that direction, even if it’s a long shot.
> 
> I also agree that one of the cited drafts is legitimately attempting something
> that would help ENO in this way if it continues to move forward
> (https://tools.ietf.org/html/draft-touch-tcpm-tcp-syn-ext-opt-06). In my
> original comment, one of the 2 alternatives I suggested as an edit was to
> continue to cite that draft, but to point out that it’s experimental.
> 
> However, I think 2 of the citations currently used as evidence are misleading,
> one of them because it shows no signs of moving forward toward any form of
> adoption (https://tools.ietf.org/html/draft-briscoe-tcpm-inspace-mode-tcpbis-
> 00), and the other because it does not apply to SYN or SYN-ACK
> (https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-07), and therefore
> wouldn’t help ENO’s use case. That is why I suggested cutting them out. (Or
> alternatively, if this weakens the point by so much it’s not worth making, to
> cut out the paragraphs that rely on it.)
> 
> My underlying concern here is that someone might take hope from this section
> and try to push their luck by putting keys into the SYN option with a length
> near the lower edge of what’s OK for security, in hopes that by the time it’s
> a real problem they’ll get an extension on the option space, rather than
> wrestling with the likely-harder problem of sending the keys in the payload.
> 
> But in practice, the option space in SYN is likely to be even less than what’s
> pointed out in this draft, because if you leave window-scale, timestamps, and
> sack-permitted out of your SYN, you’re likely to lose more on performance than
> any gains you might have made by getting a key into the SYN.
>
> In my experience, this is exactly the kind of subtle early misunderstanding
> that can lead a team to spend 6+ months developing something, then abort the
> project once they discover it cannot be made both performant enough and secure
> enough under the constraints of an early design decision.
> 
> Therefore, I would prefer this doc not to present a rosier-than-reality
> picture of the likelihood that a future development will make large SYN
> options available.

While TCPM discusses large SYN options (for a long time already), all known solutions have downsides. I do not believe that a non-TCPM document should speculate on the feasibility solutions.

Michael
 
> To take that a little further, I’d almost rather see an explicit warning that
> provides clear support for a claim like “You cannot fit a cryptographically
> secure key into the SYN option unless and until further standards work makes
> it possible to have more space there. Don’t try, you’ll regret it.”
>

---

From: David Mazieres <[email-masked]>
Date: Sun, 05 Feb 2017 05:26:42 -0800

"Scharf, Michael (Nokia - DE)" <[email-masked]> writes:

> While TCPM discusses large SYN options (for a long time already), all
> known solutions have downsides. I do not believe that a non-TCPM
> document should speculate on the feasibility solutions.

Michael, what do you think of the new proposed wording?

Our goal is not to second-guess TCPM, but rather to provide TCPM with a
data point that they have a "customer" for large SYN options in the
unlikely event that some proposal is ever deemed realistic.  I could
make the wording even stronger, as in:

   These proposals are highly experimental--with those that apply to SYN
   segments particularly unlikely to be adopted any time soon--but
   TCP-layer encryption could significantly benefit from the
   availability of increased SYN option space.

But that could be seen as second-guessing TCPM in the other
direction--telling TCPM we *don't* expect them to standardize large SYN
options anytime soon.  (Of course, it's true that I don't expect them to
do that, but it might not be my place to say so in an RFC unless you
sign off on the language...)

As always, concrete suggestions on wording are appreciated.

Thanks,
David

---

From: Joe Touch <[email-masked]>
Date: Mon, 6 Feb 2017 08:24:51 -0800

>> report, or Request-for-Proposal, nor should a vendor claim compliance with an

FWIW, Internet Drafts are cited when it is appropriate to refer
non-normatively to a concept.

Additionally, RFC20236 was published when Internet Drafts actually
expired; that's a fantasy these days, as they are archived by the ISOC.

>>    complete and understandable document with or without the reference to
That would be exactly the exception that does apply here.  If you want
to talk about using extended option space, then it's better to cite a
known discussion thereof and provide a summary than to speculate about
it or give the impression that it is not an investigated topic.
...
> While TCPM discusses large SYN options (for a long time already), all known solutions have downsides. I do not believe that a non-TCPM document should speculate on the feasibility solutions.

Agreed, but the point is that this doc probably SHOULD state that all
known solutions have deployment difficulties. An option (such as this)
that has SYN space limitations and does not address this issue is (IMO)
giving a misleading impression about its own limitations.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 6 Feb 2017 08:34:33 -0800

FWIW:

>    the TCP header.  Though these proposals are highly experimental--
The non-SYN extension is currently a WG document and intended for
standards-track.
>    particularly those that apply to SYN segments
The SYN extension proposals all have significant known issues and are
both highly experimental and difficult to deploy.

> --TCP-layer encryption
>    option space.
It might be useful to differentiate between the potential use of non-SYN
vs. SYN space.

You should be more explicit that "Although this protocol could benefit
from extended SYN space, e.g., to support in-band key coordination,
future TEPs should expect to use only the currently available space."

IMO, the following is speculative and not useful:

>   In particular, if future TEPs can perform key
>    by an octet in the range 0x00-0x9f.
The following appears to direct TCPM docs to update this doc, which is
not appropriate. If there is a SYN extension, it is much more likely to
be a stand-alone doc to update RFC793 and other docs would individually
update protocols that might benefit from that space.

>   Any document updating TCP's

...
>    availability of increased SYN option space.
Actually, the above is much more useful (IMO), but most of the rest of
the paragraph can be omitted.

Joe

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 6 Feb 2017 21:04:31 +0000

>   example, an authentication mechanism based on keyed digests (such

nit: I think you want an “as” here

>   band way to carry out such a negotiation

In this particular sentence (“Applications MAY use the ...”) I would prefer to see something like “Higher-layer protocols”, or “Higher-layer authentication mechanisms” instead of “Applications”, as the thing which MAY use the ...

The reason is because this negotiation is something that every application which connects to the same service has to do in a coherent manner. In other words, this is inherently NOT a negotiation that an individual application could perform in a different way from another different application that uses the same higher layer protocol for communication. Using “Applications” in that sentence seems to imply that it’s an application-level negotiation, when in fact it’s a higher-layer-protocol negotiation. Using “Applications” might still have left some confusion about this point for me on my first reading.

(Also, I still think you’d be better served by changing the name of the a-bit from “application-aware” to something like “Legacy protocol updated” or “Higher-layer negotiation”, or another phrase that more narrowly describes the usage of the a-bit. But outside from this one final mention I won’t quibble with your decision.)

Otherwise I’m satisfied with your proposed changes, and thanks again.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 7 Feb 2017 06:53:35 +0000

I'd agree to Joe's proposal "Although this protocol could benefit from extended SYN space, e.g., to support in-band key coordination, future TEPs should expect to use only the currently available space."

Michael (chair hat off)

________________________________________
From: Joe Touch <[email-masked]>
Sent: Monday, February 6, 2017 17:34
To: David Mazieres expires 2017-05-06 PDT; Scharf, Michael (Nokia - DE); Holland, Jake; [email-masked]
Cc: [email-masked]
Subject: Re: [tcpm] [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

FWIW:

...

Joe

---

From: "Black, David" <[email-masked]>
Date: Tue, 14 Feb 2017 23:06:25 +0000

+1 with WG chair hat on - I think Joe's text sets the right expectation.

Thanks, --David

> -----Original Message-----
> From: Tcpinc [mailto:[email-masked]] On Behalf Of Scharf, Michael
> (Nokia - DE)
> Sent: Tuesday, February 07, 2017 1:54 AM
> To: Joe Touch; David Mazieres expires 2017-05-06 PDT; Holland, Jake;
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tcpeno
> 
> I'd agree to Joe's proposal "Although this protocol could benefit from extended
> SYN space, e.g., to support in-band key coordination, future TEPs should expect
> to use only the currently available space."
> 
> Michael (chair hat off)
> 
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc