Subject: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Nov 2017 18:03:32 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-tcpinc-tcpeno-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

   o  TEPs MUST NOT permit the negotiation of any encryption algorithms
      with significantly less than 128-bit security.
IMPORTANT: I don't know what "significantly means". I wouldn't be
making a point of this, but it's phrased as a normative requirement,
so I don't know what conformance means.

IMPORTANT: This actually seems to be a bit confusing about how to
handle URG. Consider TCP-use-TLS, you would just process URG in the
normal way and then generate errors if URG causes reordering at the
TLS layer. This seems like a reasonable procedure but is at least
arguably prohibited by this text.

   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

IMPORTANT: this also does not seem to be unambiguous.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

   4.  Provide a standard negotiation transcript through which TEPs can
       defend against tampering with TCP-ENO.

This was unclear to me when I first read this. Maybe
"Export a standard negotiation transcript to TEPs which they can use to defend
against"

   opportunistically.  It uses a new TCP option kind to negotiate one
   among multiple possible TCP encryption protocols or TEPs.  The
   negotiation involves hosts exchanging sets of supported TEPs, where
Nit: I would say "one TEP out of multiple"

Also, "TCP encryption protocols or TEPs." is confusing. If you feel the need to
redefine, do "TCP encryption protocols (TEPs)"

   variable-length data.  When "v = 0", the byte itself constitutes the
   entirety of the suboption.  The 7-bit value "glt" expresses one of:
I would say "the remaining 7-bit value, called "glt", may take on various
meanings, as defined below"

   "b = 0" plays the "A" role.  The host that sent "b = 1" plays the "B"
   role.
This would be clearer if it (a) explained the reasoning and (b) appeared before
the packet formats. Perhaps something like

"Because the passive opener MUST set b=1 and the active opener by default sets
b=0, the normal cases is that the active opener is A and the passive opener is
B. Applications which depend on simultaneous open and have some other way of
breaking the tie can set one side to b=1 (even though it is the active opener)
and thus arrange for correct role assignment. Otherwise, simultaneous opens
will fail"

   If both sides of a connection set "b = 1" (which can happen if the
   active opener misconfigures "b" before calling "connect"), or both
   sides set "b = 0" (which can happen with simultaneous open), then
Why is this "misconfigures"? You allow them to do so.

   initial suboption byte (see Figure 4).  By default, suboption data
   extends to the end of the TCP option.  Hence, if only one suboption
   requires data, the most compact way to encode it is to place it last
Why is this "by default"? It just seems like another setting of glt.

   connection or when there is any ambiguity over the meaning of the SYN
   data.  This requirement applies to hosts that implement ENO even when
   ENO has been disabled by configuration.  However, note that
I think you may mean to say "when the last SYN TEP is not eventually negotiated"

   o  TEPs MUST NOT depend on long-lived secrets for data
      confidentiality, as implementations SHOULD provide forward secrecy
      some bounded, short time after the close of a TCP connection.
Maybe "depend solely" because one might want to use a DH mode where a static DH
key is mixed in with an ephemeral.

      probability detect a FIN flag that was set or cleared in transit
      and does not match the sender's intent.  A TEP MAY discard a
      segment with such a corrupted FIN bit, or may abort the connection
What is "high probability"

      that disable urgent data by default.  The exception is when
      applications and protocols are known never to send urgent data.

             (4) B -> A:  SYN-ACK  ENO<b=1,X,Y,Z>
             [rest of connection encrypted according to TEP Y]
Can you show a=0 in line 1?

---

From: "Black, David" <[email-masked]>
Date: Sun, 12 Nov 2017 05:08:23 +0000

Hi Ekr,
[writing as draft shepherd]

Let's see if the two of us can find some time in Singapore to talk about the two crypto algorithm Discuss points (encryption and secure hash), as (IMHO) the authors' intentions are good:

- Encryption: The intent is - don't use anything weaker than AES-128, e.g., don't even think about using 3DES.  The concern is how to write that requirement in a way that would survive hypothetical discovery of a catastrophic cryptanalytic attack on AES-128.

- Secure Hash: The intent is - don't use vanity crypto.  Does the Security Area have some text that could just be copied to say that?

> arguably prohibited by this text.

I'm confused, as the only "MUST" requirement on URG handling is:

   o  TEPs MUST prevent corrupted packets from causing urgent data to be
      delivered when none has been sent.

Surely TCP-use-TLS meets that requirement ;-).   Beyond that, the list of implementation techniques that follows uses "MAY" twice, and is not intended to be comprehensive.  Would stating that the list of implementation techniques is not comprehensive suffice, or is something else causing heartburn here?

Thanks, --David

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Friday, November 10, 2017 9:04 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Black, David <[email-masked]>;
> [email-masked]; Black, David <[email-masked]>; [email-masked]
> Subject: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS
> and COMMENT)
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 12 Nov 2017 05:13:50 +0000

On Sun, Nov 12, 2017 at 5:08 AM, Black, David <[email-masked]> wrote:

> Let's see if the two of us can find some time in Singapore to talk about
> the two crypto algorithm Discuss points (encryption and secure hash), as
> (IMHO) the authors' intentions are good:
>

Yep.

- Encryption: The intent is - don't use anything weaker than AES-128, e.g.,
> don't even think about using 3DES.  The concern is how to write that
> requirement in a way that would survive hypothetical discovery of a
> catastrophic cryptanalytic attack on AES-128.
>

Or even a small one. I mean, what does this say about Curve25519 or 4Q.

- Secure Hash: The intent is - don't use vanity crypto.  Does the Security
> Area have some text that could just be copied to say that?
>

Not to my knowledge. I'm not sure this is really useful to say.

> Surely TCP-use-TLS meets that requirement ;-).   Beyond that, the list of
> implementation techniques that follows uses "MAY" twice, and is not
> intended to be comprehensive.  Would stating that the list of
> implementation techniques is not comprehensive suffice, or is something
> else causing heartburn here?
>

Yep, that would be fine. I read those MAYs as exhaustive.

-Ekr

> > Cc: [email-masked]; Black, David <[email-masked]
> >;

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sun, 12 Nov 2017 13:17:20 +0800

Hi David, hi Ekr,

just quickly on the discuss points: I’m actually wondering if we can just remove the normative language here because it might be hard to give less ambiguous guidance and if there is a new TEP it anyway will go through the IETF process and we should/will not publish anything that is not considered secure to current standards.

Mirja

> Am 12.11.2017 um 13:13 schrieb Eric Rescorla <[email-masked]>:
> 
> 
> 
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Kyle Rose <[email-masked]>
Date: Sun, 12 Nov 2017 15:19:23 +0800

On Sun, Nov 12, 2017 at 1:13 PM, Eric Rescorla <[email-masked]> wrote:
>> - Encryption: The intent is - don't use anything weaker than AES-128,
>> e.g., don't even think about using 3DES.  The concern is how to write that

I think this is actually the issue driving the vagueness of the
requirement: e.g., if some hypothetical attack against AES-128 reduced
security by a few bits. The intent, as David suggests, is to prohibit
the use of something like DES, not to prohibit a 128-bit cipher with
only (say) 125 bits of security.

Kyle

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 12 Nov 2017 07:21:42 +0000

> only (say) 125 bits of security.

That's not a reasonable desire, but this is an RFC 2119 requirement, so it
really does need to be unambiguous.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 12 Nov 2017 07:39:13 +0000

Sorry, "not an unreasonable desire"

---

From: "Black, David" <[email-masked]>
Date: Mon, 13 Nov 2017 01:53:23 +0000

Keeping this all on one thread, I think the situation on the three Discus points is:

1) Encryption: Ekr and I need to talk about how to express “no weaker than current strength of AES-128 (i.e., based on attacks known in 2017)”

2) The resolution for URG processing is clear – state that the list of two techniques is not exhaustive, although the text would be improved by describing the two techniques as examples of what could be done and not using the “MAY” keyword.

3) On further reading, it looks like the one-way hash function concern is caused by a little bit of weak text in the Security Considerations section, as the body of the draft gets this topic right in Section 6:

   o  The session ID MUST depend in a collision-resistant way on all of
      the following (meaning it is computationally infeasible to produce
      collisions of the session ID derivation function unless all of the
      following quantities are identical):

      *  Fresh data contributed by both sides of the connection,

      *  Any public keys, public Diffie-Hellman parameters, or other
         public asymmetric cryptographic parameters that are employed by
         the TEP and have corresponding private data that is known by
         only one side of the connection, and

      *  The negotiation transcript specified in Section 4.8<https://tools.ietf.org/html/draft-ietf-tcpinc-tcpeno-13#section-4.8>.

The complete Security Considerations paragraph that is the focus of this Discuss point is:

   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

   identical session IDs at both ends after tampering with ENO contents

   in SYN segments.

That paragraph looks like a reasonable description of the security risk and countermeasure, except for the one sentence that Ekr pointed out.   Here’s a suggested fix:

OLD

   To avoid such

   problems, TEPs MUST compute session IDs using only well-studied and
   conservative hash functions.

NEW

   To avoid such problems, TEPs are required to compute session IDs in a

   collision-resistant way based on the TCP-ENO transcript and other

   parameters, as specified in Section 6.

This also reflects Mirja’s observation that IETF & IESG review will be the means of ensuring that this happens, so a “MUST” is not needed here beyond the “MUST” in Section 6.  In support of that observation, please be sure to make Barry Leiba’s suggested IANA registry policy changes from RFC Required to IETF Review.

Thanks, --David

From: Eric Rescorla [mailto:[email-masked]]
Sent: Sunday, November 12, 2017 2:39 AM
To: Kyle Rose <[email-masked]>
Cc: Black, David <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)

On Sun, Nov 12, 2017 at 7:21 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Nov 12, 2017 at 7:19 AM, Kyle Rose <[email-masked]<mailto:[email-masked]>> wrote:
On Sun, Nov 12, 2017 at 1:13 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
> On Sun, Nov 12, 2017 at 5:08 AM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Nov 2017 09:59:06 +0800

On Mon, Nov 13, 2017 at 9:53 AM, Black, David <[email-masked]> wrote:

> 1) Encryption: Ekr and I need to talk about how to express “no weaker than
> current strength of AES-128 (i.e., based on attacks known in 2017)”
>
>
Yep. Happy to do this at a mutually convenient time.

> 2) The resolution for URG processing is clear – state that the list of two
> techniques is not exhaustive, although the text would be improved by
> describing the two techniques as examples of what could be done and not
> using the “MAY” keyword.
>

LGTM.

>
> 3) On further reading, it looks like the one-way hash function concern is
> caused by a little bit of weak text in the Security Considerations section,
> as the body of the draft gets this topic right in Section 6:
>
>
>
>       *  The negotiation transcript specified in Section 4.8
> <https://tools.ietf.org/html/draft-ietf-tcpinc-tcpeno-13#section-4.8>.
>
>
>
> That paragraph looks like a reasonable description of the security risk
> and countermeasure, except for the one sentence that Ekr pointed out.
> Here’s a suggested fix:
>
>
>
> OLD
>
>    To avoid such
>
> This also reflects Mirja’s observation that IETF & IESG review will be the
> means of ensuring that this happens, so a “MUST” is not needed here beyond
> the “MUST” in Section 6.  In support of that observation, please be sure to
> make Barry Leiba’s suggested IANA registry policy changes from RFC Required
> to IETF Review.
>

LGTM.

-Ekr

>
>
> Thanks, --David
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* Sunday, November 12, 2017 2:39 AM
> *To:* Kyle Rose <[email-masked]>
> *Cc:* Black, David <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13:
> (with DISCUSS and COMMENT)
>
>
>

---

From: David Mazieres <[email-masked]>
Date: Sun, 12 Nov 2017 18:37:45 -0800

Hi, Eric.  Thanks for your review.  Let me go through the discuss
points, but then below I have just a couple of questions about your
feedback.  Most of your points I was able to address straight-forwardly.

So to be clear, the goal here is to make a normative requirement that
prohibits something like DES or 40-bit RC4 like in the bad old days.
However, we also don't want to rule out something like AES-128 just
because some highly theoretical biclique attack shaves two bits off the
security for an attacker who happens to have 2^{80} storage (or whatever
the state of the art in AES attacks is).

The other problem is that "n-bit" security is kind of inherently
ambiguous anyway, because with circuit complexity you'd probably have a
fairly high constant factor multiple of your key space in gate count,
while with time you can just design an instruction set that does two
things at once hence shaves a factor of two off your runtime.

My hope was that this kind of phrasing would basically allow anyone to
object if a weak cipher like DES is being considered, while permitting
things like AES-128 to go through unimpeded by unanimous consent.  The
MUST is effort to hand as powerful a weapon as possible to anyone
legitimately arguing against the selection of a bad cipher.

That said, if it's simpler we could just pick some number like 112-bit
security or something.  We've discussed this point before and I think
ended up returning to the slightly informal wording being best, but
happy to entertain other suggestions.

> IMPORTANT: this also does not seem to be unambiguous.

The current phrasing is an attempt to walk a fine line between the
adamant demands of some working group members that TEPs fully support
urgent data and the desire to support TCP-use-TLS.  Basically the SHOULD
is intended to leave you enough leeway to argue that most applications
are known not to use urgent data so TCP-use-TLS can be on by default.
I've added a sentence to the experiments section to say one of the
things we might learn is whether we can relax the urgent data
requirements further.

I tweaked the phrasing to make it clear there may be other approaches
besides the to MAYs, so the current phrasing is:

      * TEPs MUST prevent corrupted packets from causing urgent data
        to be delivered when none has been sent.  There are several
        ways to do so.  A TEP MAY cryptographically protect the URG
        flag and urgent pointer alongside ordinary payload data.
        Alternatively, a TEP MAY disable urgent data functionality by
        clearing the URG flag on all received segments and returning
        errors in response to sender-side urgent-data API calls.
        Implementations SHOULD avoid negotiating TEPs that disable
        urgent data by default.  The exception is when applications
        and protocols are known never to send urgent data.

Does that work for you?

> I think you may mean to say "when the last SYN TEP is not eventually negotiated"

No, we definitely mean *any* ambiguity, including other unrelated RFCs.
Like if the segment contains a non-empty TFO option, for example.  This
is clarified again below, with:

* The SYN segment contains a non-empty TFO option or any other TCP
  option implying a conflicting definition of SYN data.

So does this need a clarification, or is the existing wording okay?

> key is mixed in with an ephemeral.

I'm confused by this comment.  Either you depend on a long-lived secret
for data confidentiality or you don't.  In your example, would
compromising the long-lived DH key also break past connections?  If so,
then you have a bad TEP.  If not, then you don't depend on a long-lived
secret for confidentiality, so your TEP is permissible.

Adding the word "solely" actually makes it more confusing to me.
Knowing my confusion, is there some other wording you would suggest?  Or
maybe leave as-is?

> Can you show a=0 in line 1?

Do you want me to put a=0 in ever single SYN packet?  Since none of the
examples use the application aware bit, putting it in some segments but
not others might be confusing.  Can you say more specifically what the
possible confusion is?  Maybe one sentence saying a=0 in all examples
would help?

Thanks,
David

---

From: "Black, David" <[email-masked]>
Date: Mon, 13 Nov 2017 02:41:10 +0000

> Yep. Happy to do this at a mutually convenient time.

I found something useful, as it turns out that I’ve seen this before in dealing w/another draft …
   o  TEPs MUST NOT permit the negotiation of any encryption algorithms
      with significantly less than 128-bit security.
To begin with, “permit the negotiation” is somewhat off, as this is a design-time requirement for TEP security strength.  Fortunately, NIST SP 800-57 part 1 covers the notion of “security strength” in significant detail, so citing that should provide clarity on that concept.  That leaves the concern about how not to lose AES-128 if an attack is discovered that knocks a few bits off of its security strength.  Here’s a suggestion with the full rationale:
o  TEP encryption SHOULD have a security strength [SP800-57part1] of at least 128 bits and MUST have a
   security strength of at least 120 bits.  The intent of this requirement is to allow use of encryption
   algorithms designed for 128 bit security strength if attacks should be discovered that weaken their
   security strength by a few bits.
I suggested 120 bits here as being halfway between 128 bits (clearly acceptable) and 112 bits (clearly unacceptable) – that could be some other number of bits, e.g., 124 bits.

Thanks, --David

From: Eric Rescorla [mailto:[email-masked]]
Sent: Sunday, November 12, 2017 8:59 PM
To: Black, David <[email-masked]>
Cc: Kyle Rose <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)

On Mon, Nov 13, 2017 at 9:53 AM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:
Keeping this all on one thread, I think the situation on the three Discus points is:

LGTM.

   in SYN segments.

OLD

   To avoid such

NEW

LGTM.

-Ekr

Thanks, --David

From: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, November 12, 2017 2:39 AM
To: Kyle Rose <[email-masked]<mailto:[email-masked]>>
Cc: Black, David <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Nov 2017 10:42:32 +0800

This seems fine to me. 124, 120, whatever it takes.

-Ekr

On Mon, Nov 13, 2017 at 10:41 AM, Black, David <[email-masked]> wrote:

> > > 1) Encryption: Ekr and I need to talk about how to express “no weaker
> than current strength of AES-128 (i.e., based on attacks known in 2017)”
> >>
>
> To begin with, “permit the negotiation” is somewhat off, as this is a
> design-time requirement for TEP security strength.  Fortunately, NIST SP
> 800-57 part 1 covers the notion of “security strength” in significant
> detail, so citing that should provide clarity on that concept.  That leaves
> the concern about how not to lose AES-128 if an attack is discovered that
> knocks a few bits off of its security strength.  Here’s a suggestion with
> the full rationale:
>
> I suggested 120 bits here as being halfway between 128 bits (clearly
> acceptable) and 112 bits (clearly unacceptable) – that could be some other
> number of bits, e.g., 124 bits.
>
>
>
> Thanks, --David
>
>
>
> *Sent:* Sunday, November 12, 2017 8:59 PM
> *To:* Black, David <[email-masked]>
> *Cc:* Kyle Rose <[email-masked]>; The IESG <[email-masked]>;

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Nov 2017 10:49:55 +0800

On Mon, Nov 13, 2017 at 10:37 AM, David Mazieres <dm-list-tcpcrypt@scs.

> happy to entertain other suggestions.

See David Black's email.

>         and protocols are known never to send urgent data.

This still seems to suggest that these are exclusive. Perhaps a
"For instance" before "A TEP MAY"

> So does this need a clarification, or is the existing wording okay?

Sorry, I meant to replace "When the SYN TEP does not govern the
connection", not the point about ambiguity,.

> secret for confidentiality, so your TEP is permissible.

Well, as Cas Cremers keeps pointing out, if you also had a weak PRNG,
then you would in fact be depending on the static DH key. I think my problem
is the word "depend" which seems imprecise.

It' s clumsy but perhaps
"TEPs MUST NOT be designed so that compromise of a long-lived secret
compromises confidentiality"

> possible confusion is?

Why am I supposed to infer that it is 0 here when the other is 1.

  Maybe one sentence saying a=0 in all examples
> would help?

I would deal with this by a note here saying that you explicitly show a=0
here for clarify, but I could live with you having the sentence you suggest
both in the first example and then a reminder here.

-Ekr

---

From: David Mazieres <[email-masked]>
Date: Sun, 12 Nov 2017 21:15:45 -0800

> connection", not the point about ambiguity,.

So in the first paragraph of the section, we define SYN TEP as follows:

        The meaning of data in a SYN segment with an ENO option (a
        SYN+ENO segment) is determined by the last TEP identifier in the
        ENO option, which we term the segment's _SYN TEP_.

So I think the problem here may be that the term SYN TEP is confusing,
or that the definition does not stand out enough.  Am I correct that you
may just not have picked up the definition in the first paragraph and
that given the definition the rest of the section makes sense?

If that's the case, then rather than fix the sentence you highlighted, I
think we need a better term/and or better definition.  What about
"SYN-data TEP", since it's the TEP governing data in the SYN segment?

> compromises confidentiality"

The security considerations section already makes having an adequate
source of randomness a MUST, so indeed we categorically want to rule out
a weak PRNG in the normative language!

Remember, the "MUST" in question is a requirements for TEPs, not for TEP
implementations.  We deliberately made forward secrecy of the
implementation only a SHOULD.  However, the TEP itself MUST be designed
to avoid dependence on long-lived secrets for data confidentiality.  I
believe the existing language correctly prohibits TEPs from requiring
long-lived static DH keys, even if certain *implementations* wind up
keeping keys around longer than indicated by the TEP specification.

If you still think there's a problem with the current language, can you
supply a more concrete example?  It sounds like you have a specific kind
of protocol in mind that you think should be legal but isn't under the
current draft.  However, I can't figure out what that is because I don't
see how to make long-lived static DH parameters useful in a TEP.
Long-lived static DH parameters seem more useful for some kind of
higher-layer application protocol that authenticates session IDs...

Thanks,
David

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Nov 2017 05:29:12 +0000

On Mon, Nov 13, 2017 at 5:15 AM, David Mazieres <
[email-masked]> wrote:

> or that the definition does not stand out enough.

The problem is that "govern" is not very clear. It's clearer to link the
requirement
here to the specific feature of the packet.

> "SYN-data TEP", since it's the TEP governing data in the SYN segment?

i don't really understand what you are proposing here.

> a weak PRNG in the normative language!

I don't disagree with that. But implementations have defects sometimes and
also
see my point about pinning below

> current draft.

Sure. OPTLS for example. This has PFS but also is robust against compromise
of the ephemeral key.

> However, I can't figure out what that is because I don't
> higher-layer application protocol that authenticates session IDs...

They are useful in two ways:

1. If you wanted to do TOFU on the remote key.
2. If you were concerned about the ephemeral PRNG (even if you intended
it to be strong) but you believed your initial PRNG to be strong.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Nov 2017 06:16:43 +0000

On Mon, Nov 13, 2017 at 6:12 AM, David Mazieres expires 2018-02-10 PST <
[email-masked]>
wrote:

> Okay, let me futz with the language a bit and try to get rid of or
> clearly define the term govern.
>

Thanks

> Got it, thanks.  How about the following?
>
>         TEPs MUST guarantee the confidentiality of TCP streams without
>         assuming the security of any long-lived secrets.
>

SGTM.

Thanks
-Ekr

---

From: David Mazieres <[email-masked]>
Date: Sun, 12 Nov 2017 22:35:32 -0800

> clearly define the term govern.

Okay, how about the following?

Thanks,
David

4.7.  Data in SYN Segments

   TEPs MAY specify the use of data in SYN segments so as to reduce the
   number of round trips required for connection setup.  The meaning of
   data in a SYN segment with an ENO option (a SYN+ENO segment) is
   determined by the last TEP identifier in the ENO option, which we
   term the segment's _SYN TEP_.  A SYN+ENO segment may of course
   include multiple TEP suboptionss, but only the SYN TEP (i.e., the
   last one) specifies how to interpret the SYN segment's data payload.

   A host sending a SYN+ENO segment MUST NOT include data in the segment
   unless the SYN TEP's specification defines the use of such data.
   Furthermore, to avoid conflicting interpretations of SYN data, a
   SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO)
   option [RFC7413].

   Because a host can send SYN data before knowing which if any TEP the
   connection will negotiate, hosts implementing ENO are REQUIRED to
   discard data from SYN+ENO segments when the SYN TEP does not become
   the negotiated TEP.  Hosts are furthermore REQUIRED to discard SYN
   data in cases where another Internet standard specifies a conflicting
   interpretation of SYN data (as would occur when receiving a non-empty
   TFO option).  This requirement applies to hosts that implement ENO
   even when ENO has been disabled by configuration.  However, note that
   discarding SYN data is already common practice [RFC4987] and the new
   requirement applies only to segments containing ENO options.

   More specifically, a host that implements ENO MUST discard the data
   in a received SYN+ENO segment if any of the following applies:

   o  ENO fails and TEP-indicated encryption is disabled for the
      connection,

   o  The received segment's SYN TEP is not the negotiated TEP,

   o  The negotiated TEP does not define the use of SYN data, or

   o  The SYN segment contains a non-empty TFO option or any other TCP
      option implying a conflicting definition of SYN data.

   A host discarding SYN data in compliance with the above requirement
   MUST NOT acknowledge the sequence number of the discarded data, but
   rather MUST acknowledge the other host's initial sequence number as
   if the received SYN segment contained no data.  Furthermore, after
   discarding SYN data, such a host MUST NOT assume the SYN data will be
   identically retransmitted, and MUST process data only from non-SYN
   segments.

   If a host sends a SYN+ENO segment with data and receives
   acknowledgment for the data, but the SYN TEP in its transmitted SYN
   segment is not the negotiated TEP (either because a different TEP was
   negotiated or because ENO failed to negotiate encryption), then the
   host MUST abort the TCP connection.  Proceeding in any other fashion
   risks misinterpreted SYN data.

   If a host sends a SYN-only SYN+ENO segment bearing data and
   subsequently receives a SYN-ACK segment without an ENO option, that
   host MUST abort the connection even if the SYN-ACK segment does not
   acknowledge the SYN data.  The issue is that unacknowledged data may
   nonetheless have been cached by the receiver; later retransmissions
   intended to supersede this unacknowledged data could fail to do so if
   the receiver gives precedence to the cached original data.
   Implementations MAY provide an API call for a non-default mode in
   which unacknowledged SYN data does not cause a connection abort, but
   applications MUST use this mode only when a higher-layer integrity
   check would anyway terminate a garbled connection.

   To avoid unexpected connection aborts, ENO implementations MUST
   disable the use of data in SYN-only segments by default.  Such data
   MAY be enabled by an API command.  In particular, implementations MAY
   provide a per-connection mandatory encryption mode that automatically
   aborts a connection if ENO fails, and MAY enable SYN data in this
   mode.

   To satisfy the requirement of the previous paragraph, all TEPs SHOULD
   support a normal mode of operation that avoids data in SYN-only
   segments.  An exception is TEPs intended to be disabled by default.

---

From: David Mazieres <[email-masked]>
Date: Sun, 12 Nov 2017 23:31:51 -0800

> I suggested 120 bits here as being halfway between 128 bits (clearly acceptable) and 112 bits (clearly unacceptable) – that could be some other number of bits, e.g., 124 bits.

Hi, David.  Thanks for this general approach.  However, I have a couple
of points.  First, I'm not sure I understand your criticism about permit
the negotiation, as we would expect most TEPs to engage in some sort of
cipher suite negotiation.  Second, why make this more complicated with
the SHOULD 128?  Can we just have a 120-bit requirement?  What about
the following?

   o  TEPs MUST NOT permit the use of encryption algorithms with a
      security strength [SP800-57part1] of less than 120 bits.  The
      intent of this requirement is to allow the use of algorithms such
      as AES-128 [AES] that are designed for 128-bit security and still
      widely considered secure even after losing a few bits of security
      to highly theoretical attacks.

If you accept that, then I think the only remaining issues are this from
your other email:

> That paragraph looks like a reasonable description of the security risk and
> countermeasure, except for the one sentence that Ekr pointed out.   Here’s a
> suggested fix:
>
> OLD
>
>    To avoid such
>
> means of ensuring that this happens, so a “MUST” is not needed here beyond the
> “MUST” in Section 6.  In support of that observation, please be sure to make
> Barry Leiba’s suggested IANA registry policy changes from RFC Required to IETF
> Review.

The security considerations paragraph is trying to make a different
point from the one in section 5.1.  Section 5.1 says you MUST provide
all this stuff as an input to your hash function.  Section 10 says that
hash function MUST not be weird "vanity crypto."  In other words, it may
be reasonable to use vanity crypto for key negotiation or session data
encryption, because that only affects the security of one TEP.  However,
the session ID hash function potentially affects *all* TEPs because if
it's broken, it will permit negotiation rollback attacks to deprecated
TEPs--even when both sides prefer a more secure TEP.

I want to make clear clear that the session ID hash function choice
needs extra scrutiny to prevent this point from being lost on future
generations of IETF & IESG reviewers.  I don't have to make it a MUST if
that seems really problematic.  But I also don't just want to reiterate
the same point as section 5.1, which is I think what your proposed
language does.

Final point:  I only have a tcpcrypt review from Barry Leiba.  Should I
apply his suggestion of "IETF review" instead of "RFC Required"?  I
originally wanted "Specification Required" because I thought the
designated expert review it implied would be sufficient.  Mirja talked
me up to "RFC Required," which I thought was more strict.  However, does
the RFC Required not in fact demand any kind of expert review?  (Looking
at RFC8126, it doesn't seem to.)  I would be perfectly happy with an
IRTF or Independent Submission stream RFC so long as a designated expert
agrees the document is not a waste of a code point.

Thanks,
David

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Nov 2017 08:28:07 +0000

This seems fine to me.

---

From: "Black, David" <[email-masked]>
Date: Mon, 13 Nov 2017 09:20:34 +0000

Hi David,

Separating and labelling topics ...

--[1]-- TEP encryption security strength

> First, I'm not sure I understand your criticism about permit
> cipher suite negotiation.  

This is entirely editorial about word choice - "permit the negotiation" sounds like a runtime requirement to me, whereas this section is entirely design requirements.  Using "support" instead of "permit the negotiation of" is among the ways to make this clearer, IMHO.

> Second, why make this more complicated with the SHOULD 128?  Can we just have a 120-bit requirement?

I think this is a "show your work" situation.  I'd expect a 120-bit requirement by itself to induce a fair amount of "where did that number of bits come from?" head scratching, starting from the inability to find a 120 bit security strength in SP 800-57.  Independent of wording and keyword choices, there appear to be two things going on:
	a) We want TEPs designed to at least 128 bits of strength.
	b) We're willing to accept a few bits less if necessary, but not many bits less.
I think both need to be stated for clarity, although I'm not attached to the precise words used, e.g., lower case "should" instead of "SHOULD" seems reasonable for the 128 bit design requirement.  One advantage of using a "SHOULD" for the 128 bits of strength is that it invokes RFC 2119's requirement that "the full implications must be understood and carefully weighed before choosing a different course."

--[2]-- Cross-TEP security considerations for "vanity crypto"

> TEPs--even when both sides prefer a more secure TEP.

I would write what is meant/wanted here as opposed to assuming that the rationale behind the MUST will be clear to all future reviewers.

> I want to make clear that the session ID hash function choice

Text along those lines would be clearer, including stating that reviewers are an intended target audience.   Writing that text would be better than discussing the text that I wrote.  Guidance to security reviewers is a fine thing to put in Security Considerations.

--[3]-- IANA registry policy for TEP registry

> agrees the document is not a waste of a code point.

This is somewhat in tension with the previous topic - how much review is sufficient to ensure that a weak TEP doesn't impact the security of all others?  The degree of review increases from Specification Required to RFC Required to IETF Review - if the need to ban potentially flawed vanity crypto hashes in TEPs is serious, then IETF Review seems justified, even though it imposes process costs on getting new TEPs approved.  In all cases, IANA will have a designated expert to advise on the registration, "RFC Required" adds the IESG taking a look, and IETF Review adds a lot more attention from the IETF security community.   More eyes tend to find more things ...

Thanks, --David

> From: Tcpinc [mailto:[email-masked]] On Behalf Of David Mazieres
> Sent: Monday, November 13, 2017 2:32 AM
> To: Black, David <[email-masked]>; Eric Rescorla <[email-masked]>
> Cc: [email-masked]; Kyle Rose <[email-masked]>; [email-masked];
> Black, David <[email-masked]>; Mirja Kuehlewind (IETF)
> <[email-masked]>; The IESG <[email-masked]>; draft-ietf-tcpinc-
> [email-masked]
> Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13:
> > To begin with, “permit the negotiation” is somewhat off, as this is a design-
> time requirement for TEP security strength.  Fortunately, NIST SP 800-57 part
> 1 covers the notion of “security strength” in significant detail, so citing that
> should provide clarity on that concept.  That leaves the concern about how
> not to lose AES-128 if an attack is discovered that knocks a few bits off of its
> security strength.  Here’s a suggestion with the full rationale:

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 13 Nov 2017 13:47:46 +0200

>       to highly theoretical attacks.

Just side comment about all this MUST / MUST NOT discussion. Remember
that there is going to be customer coming to you at one point and
asking you to show the line numbers which implements each MUST and
MUST NOT in the code, as their auditor required that information
before they allow product to be certified. Then you will curse all
those people who wrote the document and added all kind of MUSTs and
MUST NOTs to which cannot be verified.

I think both cases here are something that only limit the future IESG
or TEPs, and does not really need upper case MUST, and also mostly are
not even implementation or protocol issues but policy issues. And I
myself would recommend writing them in non-conformant manner just to
make implementors life easier.

And yes, I did get request from support asking me to provide line
numbers which implement the RFC7296 text saying "field X MUST NOT be
zero", so they can pass them to customers who is going to pass it to
audit lab... My original answer was "all of the lines", but I think
support converted it to more suitable answer.
-- 
[email-masked]

---

From: David Mazieres <[email-masked]>
Date: Mon, 13 Nov 2017 10:42:47 -0800

"Black, David" <[email-masked]> writes:

> This is entirely editorial about word choice - "permit the
> negotiation" sounds like a runtime requirement to me, whereas this
> section is entirely design requirements.  Using "support" instead of
> "permit the negotiation of" is among the ways to make this clearer,
> IMHO.

But what about my proposed wording, which says "permit the use of"
instead of "permit the negotiation of"?

* TEPs MUST NOT permit the use of encryption algorithms with a
  security strength [@!SP800-57part1] of less than 120 bits.  The
  intent of this requirement is to allow the use of algorithms such as
  AES-128 [@?AES] that are designed for 128-bit security and still
  widely considered secure even after losing a few bits of security to
  highly theoretical attacks.

> I think both need to be stated for clarity, although I'm not attached to the precise words used, e.g., lower case "should" instead of "SHOULD" seems reasonable for the 128 bit design requirement.…

The proposed language explains the rationale.

Also, I'm not sure I agree that 128 bits are better than slightly fewer.
For example, tcpcrypt's MTI DH curve is curve25519.  If memory serves,
aren't the private keys for that something like 123 bits, because you
are supposed to fix the top bits as 01 and bottom as 000 or something?
It still seems like a perfectly fine choice of algorithm.  All else
equal, given implementation considerations, I think we might be more
likely to see mainstream 127-bit keys than 129-bit keys, and I'd rather
people choose algorithms with more scrutiny.  When you are dealing with
such small bit length differences, the constant factors and amount of
human scrutiny against a big break are more important.

> I would write what is meant/wanted here as opposed to assuming that
> the rationale behind the MUST will be clear to all future reviewers.

Obviously that is not coming through to readers, but that was the intent
of the language.  E.g.:

        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.

What about:

Because TCP-ENO enables multiple different TEPs to coexist, security
could potentially be only as strong as the weakest available TEP.  In
particular, if TEPs use a weak hash function to incorporate the TCP-ENO
transcript into session IDs, then an attacker can undetectably tamper
with ENO options to force negotiation of a deprecated and vulnerable
TEP.  To avoid such problems, session IDs SHOULD be computed using
mainstream, well-studied, conservative hash functions.  That way, even
if other parts of a TEP rely on more esoteric cryptography that turns
out to be vulnerable, it is still intractable for an attacker to induce
identical session IDs at both ends after tampering with ENO contents in
SYN segments.

> This is somewhat in tension with the previous topic - how much review is sufficient to ensure that a weak TEP doesn't impact the security of all others?  The degree of review increases from Specifi…

As long as "RFC required" involves a designated expert, that would be my
preference.  It's also what I think we arrived at after a bunch of
discussion with Mirja.  I don't think the choice of conservative hash
function requires more than a designated expert review, because it's not
controversial or hard to check.  So is the status quo okay on this
point?

David

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Nov 2017 20:40:25 +0000

On Mon, Nov 13, 2017 at 6:42 PM, David Mazieres <
[email-masked]> wrote:

> > I think this is a "show your work" situation.  I'd expect a 120-bit
> requirement by itself to induce a fair amount of "where did that number of
> bits come from?" head scratching, starting from the inability to find a 120
> bit security strength in SP 800-57.  Independent of wording and keyword
> choices, there appear to be two things going on:
> > I think both need to be stated for clarity, although I'm not attached to
> the precise words used, e.g., lower case "should" instead of "SHOULD" seems
> reasonable for the 128 bit design requirement.  One advantage of using a
> "SHOULD" for the 128 bits of strength is that it invokes RFC 2119's
> requirement that "the full implications must be understood and carefully
> weighed before choosing a different course."
>

To be honest, I think this document is working too hard in both cases to
try to legislate that people don't do things that we think are bad. The
bottom
line is that in both cases the boundaries around what we think is OK and
what we think is not are kind of fuzzy (as you illustrate above with
Curve25519). Rather than try to write RFC 2919 language about this,
it would be better to simply describe the consequences of bad choices,
and say that the function must be collision resistant, and stop.

-Ekr

> > This is somewhat in tension with the previous topic - how much review is
> sufficient to ensure that a weak TEP doesn't impact the security of all
> others?  The degree of review increases from Specification Required to RFC
> Required to IETF Review - if the need to ban potentially flawed vanity
> crypto hashes in TEPs is serious, then IETF Review seems justified, even
> though it imposes process costs on getting new TEPs approved.  In all
> cases, IANA will have a designated expert to advise on the registration,
> "RFC Required" adds the IESG taking a look, and IETF Review adds a lot more
> attention from the IETF security community.   More eyes tend to find more
> things ...
>

---

From: Amanda Baber <[email-masked]>
Date: Mon, 13 Nov 2017 21:21:49 +0000

Hi David,

See [AB] below for a note about registration procedures.  

Thanks,
Amanda

[AB] To include a designated expert requirement here, you would need to combine registration procedures. “Expert Review with RFC Required” would work.

David

---

From: David Mazieres <[email-masked]>
Date: Mon, 13 Nov 2017 13:24:00 -0800

> and say that the function must be collision resistant, and stop.

I don't understand the RFC2919 reference.  Did you mean a different RFC,
or is there some IETF lore about this being an overly-specified RFC?

The thing is, there is definitely historical precedent for intentionally
choosing weak crypto algorithms.  And while I hope the truly bad old
days are behind us, I still think it's important that we abstract some
base level of security out of TCP-ENO so that most applications don't
need to whitelist TEP identifiers.

David

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Nov 2017 21:31:21 +0000

> or is there some IETF lore about this being an overly-specified RFC?

Sorry RFC 2119.

> choosing weak crypto algorithms.

Yes, I really am aware of this.

  And while I hope the truly bad old
> need to whitelist TEP identifiers.

I think you're really overestimating the amount of influence IETF has here.
What we can do is stop IANA from registering code points, but nothing stops
people from just grabbing one for a noncompliant TEP. I'm fine with having
text in the RFC that says "this needs to be a strong function and that's
why",
but it's not like we can take people to court to make them stop doing that,
so having extremely precise and strong language here doesn't actually
help that much.

-Ekr

---

From: "Black, David" <[email-masked]>
Date: Tue, 14 Nov 2017 03:02:20 +0000

Trying to summarize …

> instead of "permit the negotiation of"?

Ok, but “permit the ... of” is not needed – “TEPs MUST NOT use” is both direct and sufficient.

[…  snip …]

Beyond that, I concur with this point:

> When you are dealing with

However, I still think that it’s a good idea to note that 128 bits is the preferred lower bound design target for security strength, although that can be done without a “SHOULD” keyword– e.g.:

TEPs MUST NOT use encryption algorithms with a security strength [@!SP800-57part1] of less than 120 bits.
TEP designs are encouraged to target a security strength of at least 128 bits to provide some headroom
above the 120 bit requirement to accommodate possible future attacks that remove a few  bits of security
strength without compromising the fundamental security of the encryption algorithm.

> identical session IDs at both ends after tampering with ENO contents in

Ekr, Tero and I all appear to think that an RFC 2119 keyword is not appropriate here.  Try:

OLD
To avoid such problems, session IDs SHOULD be computed using
mainstream, well-studied, conservative hash functions.
NEW
Towards avoiding such problems, security reviewers of new TEPs
are expected to pay particular attention to the security strength and
state of cryptanalysis (including research into possible attacks) of the
session ID hash function, above and beyond checking that the hash
function meets the requirements stated in Section 6.

This proposed text also makes it clear that the concern here is in addition to the Section 6 requirements on the hash function.

At least my suggestion of IETF Review was in part to see whether more strict review would be appropriate – that appears not to be the case, so …

I like Amanda’s suggestion of: “Expert Review with RFC Required”   That should result in two security reviews of a new TEP, both of which could halt a weak one.  Looking at the Independent Submission track as the “path of least resistance” that would be the IETF Security Area (ADs and Directorate) as part of RFC publication plus an IANA expert review as part of codepoint assignment.  Thank you, Amanda.

I have to admit that Ekr is right that anyone can do arbitrarily stupid things on their own – what we can stop is misuse of IETF’s good name and IANA registration in support of that sort of stupidity.

Thanks, --David

From: Eric Rescorla [mailto:[email-masked]]
Sent: Monday, November 13, 2017 3:40 PM
To: David Mazieres <[email-masked]>
Cc: Black, David <[email-masked]>; [email-masked]; Kyle Rose <[email-masked]>; [email-masked]; Mirja Kuehlewind (IETF) <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)

On Mon, Nov 13, 2017 at 6:42 PM, David Mazieres <[email-masked]<mailto:[email-masked]>> wrote:

What about:

try to legislate that people don't do things that we think are bad. The bottom

-Ekr

David

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Nov 2017 11:07:33 +0800

On Tue, Nov 14, 2017 at 11:02 AM, Black, David <[email-masked]> wrote:

> However, I still think that it’s a good idea to note that 128 bits is the
> preferred lower bound design target for security strength, although that
> can be done without a “SHOULD” keyword– e.g.:
>
>
>

This is fine.

> function meets the requirements stated in Section 6.

This is fine, though I think "SHOULD" could replace "are expected to"

>
> This proposed text also makes it clear that the concern here is in
> addition to the Section 6 requirements on the hash function.
>
>
>
> At least my suggestion of IETF Review was in part to see whether more
> strict review would be appropriate – that appears not to be the case, so …
>
>
>
> I like Amanda’s suggestion of: “Expert Review with RFC Required”   That
> should result in two security reviews of a new TEP, both of which could
> halt a weak one.  Looking at the Independent Submission track as the “path
> of least resistance” that would be the IETF Security Area (ADs and
> Directorate) as part of RFC publication plus an IANA expert review as part
> of codepoint assignment.  Thank you, Amanda.
>
>
>
> I have to admit that Ekr is right that anyone can do arbitrarily stupid
> things on their own – what we can stop is misuse of IETF’s good name and
> IANA registration in support of that sort of stupidity.
>

Well, ultimately this is a WG decision, but we actually have tried this
approach in TLS and other WGs and it doesn't work well. People grab code
points and we have to deal with that, and we also have to spend a lot of WG
time doing useless vetting when people just want a code point.

-Ekr

> *Sent:* Monday, November 13, 2017 3:40 PM
> *To:* David Mazieres <[email-masked]>
> *Cc:* Black, David <[email-masked]>; [email-masked]; Kyle Rose <
> [email-masked]>; [email-masked]; Mirja Kuehlewind (IETF) <
> [email-masked]>; The IESG <[email-masked]>;
> [email-masked]
> *Subject:* Re: [tcpinc] Eric Rescorla's Discuss on
> draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)
>
>
>
>
>
>
>
> On Mon, Nov 13, 2017 at 6:42 PM, David Mazieres <dm-list-tcpcrypt@scs.
> stanford.edu> wrote:
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 14 Nov 2017 11:18:11 +0800

Only on this point:

> Am 14.11.2017 um 11:07 schrieb Eric Rescorla <[email-masked]>:
> 
> Well, ultimately this is a WG decision, but we actually have tried this approach in TLS and other WGs and it doesn't work well. People grab code points and we have to deal with that, and we also have to spend a lot of WG time doing useless vetting when people just want a code point.
> 
Ekr, not sure what your recommendation is but the previous discussion was that it is encouraged to ask for early allocation in the (RFC) process, however, we would like to finally end up with a spec in an RFC for all TEPs.

I guess if we want expert review for non-IETF stream docs it actually would be „IETF Review or RFC Required with Expert Review“… Amanda, does that still makes sense to you?

Mirja

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Nov 2017 11:29:30 +0800

On Tue, Nov 14, 2017 at 11:18 AM, Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> Ekr, not sure what your recommendation is but the previous discussion was
> that it is encouraged to ask for early allocation in the (RFC) process,
> however, we would like to finally end up with a spec in an RFC for all TEPs.
>

My recommendation is not to use the IANA registry to gatekeep on what
people deploy and instead do what TLS has moved towards, namely making the
bar for registering a code point low but that have the bar to a
*recommended* code point be a standards track RFC.

As I said, it's a WG decision to decide what to do.

-Ekr

I guess if we want expert review for non-IETF stream docs it actually would
> be „IETF Review or RFC Required with Expert Review“… Amanda, does that
> still makes sense to you?
>
> Mirja
>
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Nov 2017 05:42:36 +0200

Black, David writes:
> I like Amanda’s suggestion of: “Expert Review with RFC Required”
> That should result in two security reviews of a new TEP, both of
> which could halt a weak one. Looking at the Independent Submission
> track as the “path of least resistance” that would be the IETF
> Security Area (ADs and Directorate) as part of RFC publication plus
> an IANA expert review as part of codepoint assignment. Thank you,
> Amanda.

We (talking as secdir secretary) do not do security reviews on the
independent submission documents. Area review teams only review IETF
stream documents and ignore other streams (Independent, IAB, IRTF
etc). 

Expert can of course do whatever checks he wants, and the IANA section
can set some instructions for expert, for example ask him to verify in
the specific mailing list before doing assignments etc.

I as an IANA expert for the IKEv2 related registries (it is just
expert review, no specification or RFC required) usually do require
stable reference before I say assignment is ok. I also quite often
send email to the [email-masked] list before doing assignments, if I
think there is something that might be important to people there.

Anyways everything this boils down getting expert for the IANA
registry that we (as an IETF) can trust do good job of blocking bad
ideas... 
-- 
[email-masked]

---

From: "Black, David" <[email-masked]>
Date: Tue, 14 Nov 2017 03:48:02 +0000

> stream documents and ignore other streams (Independent, IAB, IRTF

Hmm - the process that I'd expect is that a SEC AD notices something odd, suspicious or peculiar in an independent submission TEP spec during conflict review and asks an expert on the secdir to take a closer look.   Given the threat of a weak TEP hash to all other TEPs, I would think/hope that independent submission publication of a TEP with a weak hash could be blocked then and there.

Thanks, --David

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Monday, November 13, 2017 10:43 PM
> Cc: Eric Rescorla <[email-masked]>; David Mazieres <dm-list-
> [email-masked]>; [email-masked]; Kyle Rose <[email-masked]>;
> [email-masked]; Mirja Kuehlewind (IETF) <[email-masked]>; The
> IESG <[email-masked]>; [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Nov 2017 06:03:32 +0200

Black, David writes:
> Hmm - the process that I'd expect is that a SEC AD notices something
> odd, suspicious or peculiar in an independent submission TEP spec
> during conflict review and asks an expert on the secdir to take a
> closer look.   Given the threat of a weak TEP hash to all other
> TEPs, I would think/hope that independent submission publication of
> a TEP with a weak hash could be blocked then and there. 

Sec AD will most likely post to the saag list [1] and ask if there is
reason to block some specific ISE document. This does not mean there
is security review done on that document.

[1] https://mailarchive.ietf.org/arch/msg/saag/E8icM-Ak-wJnnqtG4t6I8bujxiI
-- 
[email-masked]

---

From: David Mazieres <[email-masked]>
Date: Mon, 13 Nov 2017 21:15:04 -0800

> See [AB] below for a note about registration procedures.  

Okay, thanks.  Here is my new proposed language for the end of IANA
considerations.  This also reflects a change to address Benoit Claise's
concern that 95 TEP identifiers could prove too few.

   This document defines a 7-bit "glt" field in the range of 0x20-0x7f,
   for which IANA is to create and maintain a new registry entitled "TCP
   encryption protocol identifiers" under the "Transmission Control
   Protocol (TCP) Parameters" registry.  The initial contents of the TCP
   encryption protocol identifier registry is shown in Table 2.  This
   document allocates one TEP identifier (0x20) for experimental use.
   In case the TEP identifier space proves too small, identifiers in the
   range 0x70-0x7f are reserved to enable a future update to this
   document to define extended identifier values.  Assignments are to be
   made under the combined policy "Expert Review with RFC Required" as
   these terms are defined in [RFC8126].  Early allocation [RFC7120]
   should be used to facilitate testing before RFCs are finalized.

         +-----------+------------------------------+-----------+
         | Value     | Meaning                      | Reference |
         +-----------+------------------------------+-----------+
         | 0x20      | Experimental Use             | [RFC-TBD] |
         | 0x70-0x7f | Reserved for extended values | [RFC-TBD] |
         +-----------+------------------------------+-----------+

               Table 2: TCP encryption protocol identifiers

David

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 14 Nov 2017 13:55:02 +0800

We should rather put experts in place and not trying to push the responsibility on the Sec AD. The conflict review is only to check if there are conflicts with any IETF work and not to check if the work described is technically mature.

Mirja

> Am 14.11.2017 um 12:03 schrieb Tero Kivinen <[email-masked]>:
> 
> Black, David writes:

---

From: Amanda Baber <[email-masked]>
Date: Tue, 14 Nov 2017 19:38:57 +0000

Hi David,

See [AB] below.

Thanks,
Amanda

On 11/13/17, 9:15 PM, "David Mazieres" <[email-masked]> wrote:

[AB] Yes, this makes sense. I should note that because Expert Review has been added, we would ask the expert(s) to confirm that any Early Allocation request is OK. 

David

---

From: Amanda Baber <[email-masked]>
Date: Tue, 14 Nov 2017 19:44:16 +0000

Hi,

See [AB] below.

On 11/13/17, 7:18 PM, "Mirja Kuehlewind (IETF)" <[email-masked]> wrote:

[AB] That works for us too. I think that in that case we would call it “IETF Review or Expert Review with RFC Required,” to make it clear that Expert Review is only modifying one of the procedures.  

Mirja

---

From: David Mazieres <[email-masked]>
Date: Wed, 15 Nov 2017 17:46:07 -0800

Amanda Baber <[email-masked]> writes:

> I guess if we want expert review for non-IETF stream docs it actually
> would be „IETF Review or RFC Required with Expert Review“… Amanda,
> does that still makes sense to you?
>
> [AB] That works for us too. I think that in that case we would call it
> “IETF Review or Expert Review with RFC Required,” to make it clear
> that Expert Review is only modifying one of the procedures.

Thanks for the continued feedback.  Here is the current wording.  Please
let us know it that seems good:

   This document defines a 7-bit "glt" field in the range of 0x20-0x7f,
   for which IANA is to create and maintain a new registry entitled "TCP
   encryption protocol identifiers" under the "Transmission Control
   Protocol (TCP) Parameters" registry.  The initial contents of the TCP
   encryption protocol identifier registry is shown in Table 2.  This
   document allocates one TEP identifier (0x20) for experimental use.
   In case the TEP identifier space proves too small, identifiers in the
   range 0x70-0x7f are reserved to enable a future update to this
   document to define extended identifier values.  Assignments are to be
   made upon satisfying either of two policies defined in [RFC8126]:
   "IETF Review" or (for non-IETF stream specifications) "Expert Review
   with RFC Required."  IANA will furthermore provide early allocation
   [RFC7120] to facilitate testing before RFCs are finalized.

Thanks,
David

---

From: Amanda Baber <[email-masked]>
Date: Thu, 16 Nov 2017 08:18:06 +0000

Hi David,

This works for us. Thanks!

Amanda

On 11/15/17, 5:46 PM, "David Mazieres" <[email-masked]> wrote:

Thanks,
David