Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

From: "Kaduk, Ben" <[email-masked]>
Date: Sun, 13 Nov 2016 23:54:21 +0000

I have reviewed this document and have a few minor comments.  I also have many editorial notes that can be addressed out of band.

In the abstract and introduction, we have text about the properties that TLS is expected to provide, like confidentiality, authentication, etc.  Do we want to say anything about avoiding side channels that might leak information about the data being exchanged?  I know that we are not 100% confident at what exactly we currently achieve in this area, but since we have mechanisms that attempt to achieve it, maybe it is worth mentioning.  (In a similar vein, as davidben reminded me recently, an attacker “who has complete control of the network”, as is our stated adversary, can do things like trickle packets in one by one and try to see, e.g., where the end of early data is and query handshake state.  So some things may not be avoidable.)

In section 4.2.5.1 we talk about how for FFDH peers SHOULD validate each other’s public key Y by ensuring that 1 < Y < p-1, which is supposed to ensure that the peer is well-behaved and isn’t forcing the local system into a small subgroup.  Somehow I thought that additional checks were needed to avoid being forced into a small subgroup, but I guess that depends on what group it’s in, and I didn’t pull up the RFC 7919 reference when I was reading this document.

In section 4.2.7, we note that the server MUST NOT send the “psk_key_exchange_modes” extension, with the implication that the client must observer the types of handshake messages that are subsequently received in order to determine what the server selected.  I think that we had talked about this already some time ago, but just wanted to confirm that we are okay with increasing the size of the client state machine in this manner.

In section 4.5.1 we note that when client auth is not used, servers MAY compute the remainder of the client-sent messages for the transcript so as to issue a NewSessionTicket immediately after the server Finished.  Do we want to say anything about why a server might wish to do so?

The coverage of record payload protection (around section 5.2) seems to not always make careful distinction between TLSPlaintext, TLSCiphertext, TLSInnerPlaintext, and the fields therein.  In some sense this is editorial, but there were a lot of places that I flagged, so I wanted to call it out to the broader audience and get more eyes on it.  I also didn’t find a description of where the length of the AEAD authentication tag gets included into a length field for the ciphertext.

At the end of section 6.1 we have this little note that “it is assumed that closing a connection reliably delivers pending data before destroying the transport”, which, if I remember correctly previous discussion on this list, is not actually true for linux.  It is perhaps problematic to have an assumption that we know is not going to be held for a large proportion of implementations.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Nov 2016 10:44:41 +0900

On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben <[email-masked]> wrote:

> I have reviewed this document and have a few minor comments.  I also have
> many editorial notes that can be addressed out of band.
>
> In the abstract and introduction, we have text about the properties that
> TLS is expected to provide, like confidentiality, authentication, etc.  Do
> we want to say anything about avoiding side channels that might leak
> information about the data being exchanged?  I know that we are not 100%
> confident at what exactly we currently achieve in this area, but since we
> have mechanisms that attempt to achieve it, maybe it is worth mentioning.
> (In a similar vein, as davidben reminded me recently, an attacker “who has
> complete control of the network”, as is our stated adversary, can do things
> like trickle packets in one by one and try to see, e.g., where the end of
> early data is and query handshake state.  So some things may not be
> avoidable.)
>

I'd be interested in seeing a PR in this area.

In section 4.2.5.1 we talk about how for FFDH peers SHOULD validate each
> other’s public key Y by ensuring that 1 < Y < p-1, which is supposed to
> ensure that the peer is well-behaved and isn’t forcing the local system
> into a small subgroup.  Somehow I thought that additional checks were
> needed to avoid being forced into a small subgroup, but I guess that
> depends on what group it’s in, and I didn’t pull up the RFC 7919 reference
> when I was reading this document.
>

These are the recommendations in 7919, I believe

> In section 4.2.7, we note that the server MUST NOT send the
> “psk_key_exchange_modes” extension, with the implication that the client
> must observer the types of handshake messages that are subsequently
> received in order to determine what the server selected.  I think that we
> had talked about this already some time ago, but just wanted to confirm
> that we are okay with increasing the size of the client state machine in
> this manner.
>

It's not subsequent messages. You determine it from the PreSharedKey and
KeyShare extensions.

> In section 4.5.1 we note that when client auth is not used, servers MAY
> compute the remainder of the client-sent messages for the transcript so as
> to issue a NewSessionTicket immediately after the server Finished.  Do we
> want to say anything about why a server might wish to do so?
>

I think I would rather not.

The coverage of record payload protection (around section 5.2) seems to not
> always make careful distinction between TLSPlaintext, TLSCiphertext,
> TLSInnerPlaintext, and the fields therein.  In some sense this is
> editorial, but there were a lot of places that I flagged, so I wanted to
> call it out to the broader audience and get more eyes on it.  I also didn’t
> find a description of where the length of the AEAD authentication tag gets
> included into a length field for the ciphertext.
>

I'm not following this point. The way to think about this is that the
ciphertext is a specific size. That may be encryption + auth tag or not
(it's possible to design an AEAD algorithm that doesn't have a separate
auth tag).

-Ekr

At the end of section 6.1 we have this little note that “it is assumed that
> closing a connection reliably delivers pending data before destroying the
> transport”, which, if I remember correctly previous discussion on this
> list, is not actually true for linux.  It is perhaps problematic to have an
> assumption that we know is not going to be held for a large proportion of
> implementations.
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Kaduk, Ben" <[email-masked]>
Date: Mon, 14 Nov 2016 12:22:13 +0000

Unfortunately, Outlook seems to be incapable of properly quoting a message for inline replies, so I will have to top-post with the relevant bits.

I’ll try to put together some text on side-channel resistance along with my pull request for editorial changes.

With respect to psk_key_exchange_modes, PreSharedKey and KeyShare are enough for the existing modes, but my understanding was that the plan with splitting the modes out this way was to allow adding new modes in later documents, including PSK for server authentication.  Can we guarantee that for all future modes we might add, there will be some other extension that indicates what was picked?  (I guess we can probably arrange for that to happen with how we specify the new modes, so it’s not actually a big deal, but might or might not make things more awkward in the future.)

The problematic text about ciphertext length/expansion for tag and other things was in the description of the TLSCiphertext ‘length’ field, which says:

   length  The length (in bytes) of the following
      TLSCiphertext.fragment, which is the sum of the lengths of the
      content and the padding, plus one for the inner content type.  The
      length MUST NOT exceed 2^14 + 256.  An endpoint that receives a
      record that exceeds this length MUST terminate the connection with
      a "record_overflow" alert.

(There is no TLSCiphertext.fragment field.)  Assuming it’s talking about the length of the “opaque encrypted_record[length]” member (which seems obvious), I do not see how the length is the sum of the length of the (plaintext) content and padding and content-type octet, since the AEAD-encryption is supposed to add some amount of expansion.  Probably the answer is to just remove any discussion about what the length represents, since it is not really helping anything; the specification for the AEAD in use will specify the ciphertext length.

On 11/14/16, 10:44, "Eric Rescorla" <[email-masked]> wrote:

    On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben 
    <[email-masked]> wrote:

    In the abstract and introduction, we have text about the properties that TLS is expected to provide, like confidentiality, authentication, etc.  Do we want to say anything about avoiding side channels that might leak information about the data being exchanged? 
     I know that we are not 100% confident at what exactly we currently achieve in this area, but since we have mechanisms that attempt to achieve it, maybe it is worth mentioning.  (In a similar vein, as davidben reminded me recently, an attacker “who has complete
     control of the network”, as is our stated adversary, can do things like trickle packets in one by one and try to see, e.g., where the end of early data is and query handshake state.  So some things may not be avoidable.)

    

    In section 4.2.5.1 we talk about how for FFDH peers SHOULD validate each other’s public key Y by ensuring that 1 < Y < p-1, which is supposed to ensure that the peer is well-behaved and isn’t forcing the local system into a small subgroup.  Somehow I thought
     that additional checks were needed to avoid being forced into a small subgroup, but I guess that depends on what group it’s in, and I didn’t pull up the RFC 7919 reference when I was reading this document.

    

    
    In section 4.2.7, we note that the server MUST NOT send the “psk_key_exchange_modes” extension, with the implication that the client must observer the types of handshake messages that are subsequently received in order to determine what the server selected. 
     I think that we had talked about this already some time ago, but just wanted to confirm that we are okay with increasing the size of the client state machine in this manner.

    
    It's not subsequent messages. You determine it from the PreSharedKey and KeyShare extensions.

    
    In section 4.5.1 we note that when client auth is not used, servers MAY compute the remainder of the client-sent messages for the transcript so as to issue a NewSessionTicket immediately after the server Finished.  Do we want to say anything about why a server
     might wish to do so?

    

    The coverage of record payload protection (around section 5.2) seems to not always make careful distinction between TLSPlaintext, TLSCiphertext, TLSInnerPlaintext, and the fields therein.  In some sense this is editorial, but there were a lot of places that
     I flagged, so I wanted to call it out to the broader audience and get more eyes on it.  I also didn’t find a description of where the length of the AEAD authentication tag gets included into a length field for the ciphertext.

    
    I'm not following this point. The way to think about this is that the ciphertext is a specific size. That may be encryption + auth tag or not (it's possible to design an AEAD algorithm that doesn't have a separate auth tag).

    -Ekr

    At the end of section 6.1 we have this little note that “it is assumed that closing a connection reliably delivers pending data before destroying the transport”, which, if I remember correctly previous discussion on this list, is not actually true for linux. 
     It is perhaps problematic to have an assumption that we know is not going to be held for a large proportion of implementations.
    
    -Ben
    
    _______________________________________________
    TLS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tls <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=4W-krMGHeyoUsqPM6uRCNxkjaJzO9tQcda4N2STFkzg&s=pxgTG28tIN2VVwYGzXG5fI2_1SiJEWfPkCBK7RpVmoM&e=>

---

From: John Mattsson <[email-masked]>
Date: Sat, 19 Nov 2016 19:40:05 +0000

WGLC comments on draft-ietf-tls-tls13-18

Hi,

Very well written draft and an excellent protocol. The things I have found
is mostly
editorial. I think it’s ready. I will try to make sure that 3GPP already
next year
mandates support of both TLS 1.3 and DTLS 1.3 in all the places they use
(D)TLS.

Cheers,
John

- I cannot find any text describing the requirements TLS 1.3 put on the
lower layers. In
  fact the only text I can find is "which might be hidden by TCP". I don't
  know if the draft should mandate TCP or not, but otherwise it should be
stated that
  reliable, in-order transport is required, and that the lower layers must
allow
  identification TLS messages in the same session (e.g. the 5-tuple when
TCP is used).

- I cannot find any text describing that TLS 1.3 outputs a stream
identical to the input
  stream. The current text only states that the input on the sender side
is application
  messages. Should state that the TLS is reliable and in-order.

- The are no requirements on the TLS API. I think the following should be
added:
  - SHALL support an exporter API
  - SHALL support an API allowing an application to get information
regarding the negotiated
    connection.
  - SHOULD support an API allowing an application to influence the
connection to be
    negotiated.

- TLS 1.3 also updates RFC5246, but I don't know if you can both update
and obsolete.
  If you have to choose, obsolete is better.

- Section 1: This is the only place channel is used in the meaning
connection. I suggest
  "channel" -> "connection"
  as connection is used in the rest of the document.

- Section 1: "The TLS standard, however, does not specify ... how to
interpret the
  authentication certificates"

  I don't this is really true any more, the draft has significant text on
certificates.
  I suggest removing "how to interpret the authentication certificates
exchanged"

- Figure 1, 4: "pre_shared_key_modes" -> "psk_key_exchange_modes"

- Figure 1. "Server Params" not horizontally aligned with "Key Exch" and
"Auth"
  (not sure if this is a feature or a bug).

- Section 2: 
- "CertificateVerify:  a signature over the entire handshake "
  "Finished :  a MAC over the entire handshake "

  Not really true. Maybe add something like "to this point"

- Section 2: The text below Figure 1 should mention
psk_key_exchange_modes. It talks
  about all other messages and extensions.

- Section 2.2: OLD "PSKs can be used with (EC)DHE exchange"
               NEW "PSKs SHOULD be used with (EC)DHE exchange"

- Section 2.3: 
  "When PSKs are provisioned out of band, the PSK identity and the KDF to
be used with
   the PSK MUST also be provisioned."
   
   OLD "and the KDF to be used"
   NEW "and the Hash algorithm to be used"
   
   I think this is a little problematic as current PSK provisioning
mechanisms do
   not provision a hash algorithm. This means that they need to be updated
before
   TLS 1.3 can be used. Otherwise the risk is that one endpoint uses
SHA-256 and
   the other SHA-384. To enable PSK systems to directly and easily upgrade
to
   TLS 1.3 I suggest the following
   
   OLD
   "When PSKs are provisioned out of band, the PSK identity and the KDF to
be used with
   the PSK MUST also be provisioned."

   NEW
   "When PSKs are provisioned out of band, the PSK identity MUST also be
provisioned and
   the Hash algorithm to be used SHOULD be provisioned. If no hash
algorithm has been
   provisioned, then SHA-256 SHALL be used."
   
   This would also affect 4.2.6.

- Section 2.3: "the following additional information MUST be provisioned
to both parties:

   -  The Application-Layer Protocol Negotiation (ALPN) protocol, if any
      is to be used

   -  The Server Name Indication (SNI), if any is to be used"

  I think these two bullets apply to ALL uses of TLS. Or? I suggest moving
to a general
  section.

- Section 2.3: "1.  This data is not forward secret, as it is encrypted
solely under keys
  derived using the offered PSK."

  This is true for all uses of PSK without (EC)DHE and not only Zero-RTT.
I suggest
  moving this text to another more general section. Maybe in Section 2
when the three
  basic key exchange modes are discussed.

- Section 2.3: Zero-RTT with PSK obtained out-of-band is a special case of
  Zero-RTT, with its own requirements and warnings. I think it should be
moved to its
  own subsubsection (2.3.1).

- Section 3.5: "enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;"
  The variable 'n' is used for two different purposes. Use n, m or
something.

- Section 3.8: Same thing here. The variable 'n' is used for two different
purposes.

- Section 4.0 The cases in Handshake definition in some random order.
Should keep the same
  order as the HandshakeType definition.

- Section 4.1.2 "Including a "cookie" extension if one was provided in the
  HelloRetryRequest."
  Could state that this is the HelloRetryRequest cookie echoed back.
  
- Section 4.1.3 I don't think ServerHello.extensions can be 0 length, but
maybe there is
  no well defined minimum length...

- Section 4.1.3
  Should state that Server.random shall be (psuedo-)random, I don't think
this is stated
  (except that the name kind of indicates it)
  
  OLD: "random  This structure is generated by the server and MUST be
        generated independently of the ClientHello.random.
  NEW: "random  32 bytes generated by the server. The first 24 bytes are
generated by a
       secure random number and MUST be generated independently of the
ClientHello.random.

- Section 4.1.3
  OLD "as long as ephemeral ciphers are used"
  NEW "as long as ephemeral key exchange are used"

  As the ephemeral part is not part of the cipher suites anymore.

- Section 4.1.3 "It does not provide downgrade protection when static RSA
is used."
  I don't know the details of ServerKeyExchange, but it this not true for
non-DHE PSK
  as well?

- Section 4.2.4
  I do not really understand why the private_use divided and resticted?
  I.e. ffdhe_private_use and ecdhe_private_use. I think it would be
preferable to just
  have "private_use" without specifying the exact use. Where do I e.g. put
my private use
  SIDH, and Lattice-based key exchange information. Feels like this is the
natural place,
  or is the intention that a new extension is required for PQC?

- Section 4.2.8
  OLD "the server MUST have accepted a PSK cipher suite"
  OLD "the server MUST have accepted a PSK key exchange mode"

- Section 5.5 "up to 2^24.5 full-size records"

  It is not well-defined on how to do with non-full-size records. I suggest
  
  OLD "up to 2^24.5 full-size records"
  NEW “up to 2^24.5 records"

- Section 5.5
  Limits are needed also for AES-CCM. It should also be stated that new
specifications
  defining new TLS ciphers SHALL provide lmits on the number of records
that can be
  protected with a given key.
  
  As far as I understand the confidentiality limits for AES-CCM (and CRT
and CBC) would
  be the same as for AES-GCM. I suggest
  
  OLD "For AES-GCM, up to 2^24.5 full-size records"
  NEW "For AES-GCM and AES-CCM, up to 2^24.5 records"
 
  These limits are quite hard, but I think that is fine as it should not
be a problem
  to rekey frequantly.
 
- Section 5.5 "for Authenticated Encryption (AE) security."
  I think it is better to state that this is confidentiality (in constrast
to integrity
  or key recovery). Suggestion
  
  OLD "for Authenticated Encryption (AE) security."
  NEW "for an confidentiality attack"

- Section 8
  The sentences "In the absence of an application profile standard
specifying otherwise"
  only apply to some parts of Section 8. E.g. it applies to cipher suites
but not to the
  diffie-hellman groups. Feels like this should apply to the whole
section. I suggest
  removing the current occurences of ""In the absence of an application
profile standard
  specifying otherwise" and add (at the start of Section 8.)

  "In the absence of an application profile standard specifying otherwise,
the following
  requirements apply".

- Section 8.1 and 8.2
  The heading says "MTI" but the text also contains non-mandatory things
(SHOULD)

  I suggest changing "MTI" to "Requirements"

- Section 8.1
  The title is "cipher suites", but the scope is broader (signatures and
key
  exchange). I sugegst changing the heading to
  
  "Requirements for cipher suites, signatures, and groups"

- Section 8.2 This section seems to forget psk_key_exchange_modes. If
pre_shared_key is
  mandatory then psk_key_exchange_modes should be to.

- Section 9: Should mention that an attacker at any point can terminate
the session by
  sending a single malformed packet. This termination feature is both
positive and
  negative.

- Section 11.2: [RFC4279] is an informative reference but never referred
to.

- Section A.4 "TLS 1.2 and lower cipher suites cannot be used with TLS
1.3."
  I cannot find any text in the draft statinn that you can negotiate TLS
1.2 ciphersuites
  in TLS 1.3, I think this should be stated.
  
  OLD: "TLS 1.2 and lower cipher suites cannot be used with TLS 1.3."
  NEW: "TLS 1.2 and lower cipher suites cannot be used with TLS 1.3, but
can be
        negotiated in a TLS 1.3 Client Hello."

- Section D.2
  OLD "weaker than 2048-bit RSA or 224-bit ECDSA are not appropriate"
  OLD "weaker than 2048-bit RSA, 224-bit ECDSA, or 128-bit PSK are not
appropriate"

- Section D.2 "The reader should refer to the following references for
analysis of
  the TLS record layer."
   
  No references given.

------------------------------------------------------------------
JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security

---

From: John Mattsson <[email-masked]>
Date: Sun, 20 Nov 2016 13:10:48 +0000

(This is the same comments as yesterday, just resending them as my mail
client turned my text into an unreadable mess, hopefully this is better).

Hi,

Very well written draft and an excellent protocol. The things I have found
is mostly editorial. I think it’s ready. I will try to make sure that 3GPP
already next year mandates support of both TLS 1.3 and DTLS 1.3 in all the
places they use (D)TLS.

Cheers,
John

- I cannot find any text describing the requirements TLS 1.3 put on the
  lower layers. In fact the only text I can find is "which might be hidden
  by TCP". I don't know if the draft should mandate TCP or not, but
  otherwise it should be stated that reliable, in-order transport is
  required, and that the lower layers must allow identification TLS
  messages in the same session (e.g. the 5-tuple when TCP is used).

- I cannot find any text describing that TLS 1.3 outputs a stream identical
  to the inputstream. The current text only states that the input on the
  sender side is application messages. Should state that the TLS is
  reliable and in-order.

- The are no requirements on the TLS API. I think the following should be
  added:
  - SHALL support an exporter API
  - SHALL support an API allowing application to get information regarding
    the negotiated connection.
  - SHOULD support an API allowing application to influence the connection
    to be negotiated.

- TLS 1.3 also updates RFC5246, but I don't know if you can both update and
  obsolete. If you have to choose, obsolete is better.

- Section 1: This is the only place channel is used in the meaning
  connection. I suggest "channel" -> "connection" as connection is used in
  the rest of the document.

- Section 1: "The TLS standard, however, does not specify ... how to
  interpret the authentication certificates"

  I don't this is really true any more, the draft has significant text on
  certificates. I suggest removing "how to interpret the authentication
  certificates exchanged"

- Figure 1. "Server Params" not horizontally aligned with "Key Exch" and
  "Auth" (not sure if this is a feature or a bug).

- Section 2: 
  "CertificateVerify:  a signature over the entire handshake "
  "Finished :  a MAC over the entire handshake "

- Section 2: The text below Figure 1 should mention psk_key_exchange_modes.
  It talks about all other messages and extensions.

- Section 2.3: 
  "When PSKs are provisioned out of band, the PSK identity and the KDF to
  be used with the PSK MUST also be provisioned."

  I think this is a little problematic as current PSK provisioning
  mechanisms do not provision a hash algorithm. This means that they need
  to be updated before TLS 1.3 can be used. Otherwise the risk is that one
  endpoint uses SHA-256 and the other SHA-384. To enable PSK systems to
  directly and easily upgrade to TLS 1.3 I suggest the following

  OLD
  "When PSKs are provisioned out of band, the PSK identity and the KDF to
  be used with the PSK MUST also be provisioned."

  NEW
  "When PSKs are provisioned out of band, the PSK identity MUST also be
  provisioned and the Hash algorithm to be used SHOULD be provisioned. If
  no hash algorithm has been provisioned, then SHA-256 SHALL be used."

- Section 2.3: "the following additional information MUST be provisioned to
  both parties:

  to a general section.

- Section 2.3: "1.  This data is not forward secret, as it is encrypted
  solely under keys derived using the offered PSK."

  This is true for all uses of PSK without (EC)DHE and not only Zero-RTT. I
  suggest moving this text to another more general section. Maybe in
  Section 2 when the three basic key exchange modes are discussed.

- Section 2.3: Zero-RTT with PSK obtained out-of-band is a special case of
  Zero-RTT, with its own requirements and warnings. I think it should be
  moved to its own subsubsection (2.3.1).

- Section 4.0 The cases in Handshake definition in some random order.
  Should keep the same order as the HandshakeType definition.

- Section 4.1.3 I don't think ServerHello.extensions can be 0 length, but
  maybe there is no well defined minimum length...

- Section 4.1.3
  Should state that Server.random shall be (psuedo-)random, I don't think
  this is stated (except that the name kind of indicates it)
  
  OLD: "random  This structure is generated by the server and MUST be
        generated independently of the ClientHello.random.
  NEW: "random  32 bytes generated by the server. The first 24 bytes are
       generated by a secure random number and MUST be generated
       independently of the ClientHello.random.

- Section 4.1.3

  non-DHE PSK as well?

- Section 4.2.4
  I do not really understand why the private_use divided and resticted?
  I.e. ffdhe_private_use and ecdhe_private_use. I think it would be
  preferable to just have "private_use" without specifying the exact use.
  Where do I e.g. put my private usE SIDH, and Lattice-based key exchange
  information. Feels like this is the natural place, or is the intention
  that a new extension is required for PQC?

- Section 4.2.8
  OLD "the server MUST have accepted a PSK cipher suite"
  NEW "the server MUST have accepted a PSK key exchange mode"

- Section 5.5
  Limits are needed also for AES-CCM. It should also be stated that new
  specifications defining new TLS ciphers SHALL provide lmits on the number
  of records that can be protected with a given key.

  As far as I understand the confidentiality limits for AES-CCM (and CTR
  and CBC) would be the same as for AES-GCM. I suggest

  These limits are quite hard, but I think that is fine as it should not be
  a problem to rekey frequently.
 
- Section 5.5 "for Authenticated Encryption (AE) security."
  I think it is better to state that this is confidentiality (in constrast
  to integrity or key recovery). Suggestion

- Section 8
  The sentences "In the absence of an application profile standard
  specifying otherwise" only apply to some parts of Section 8. E.g. it
  applies to cipher suites but not to the Diffie-Hellman groups. Feels like
  this should apply to the whole section. I suggest removing the current
  occurrences of ""In the absence of an application profile standard
  specifying otherwise" and add (at the start of Section 8.)

  "In the absence of an application profile standard specifying otherwise,
  the following requirements apply".

- Section 8.1 and 8.2

- Section 8.1
  The title is "cipher suites", but the scope is broader (signatures and
  key exchange). I suggest changing the heading to

- Section 8.2 This section seems to forget psk_key_exchange_modes. If
  pre_shared_key is mandatory then psk_key_exchange_modes should be to.

- Section 9: Should mention that an attacker at any point can terminate the
  session by sending a single malformed packet. This termination feature is
  both positive and negative.

- Section A.4 "TLS 1.2 and lower cipher suites cannot be used with
  TLS 1.3." I cannot find any text in the draft statinn that you can
  negotiate TLS 1.2 cipher suites in TLS 1.3, I think this should be
  stated.
  
  OLD: "TLS 1.2 and lower cipher suites cannot be used with TLS 1.3."
  NEW: "TLS 1.2 and lower cipher suites cannot be used with TLS 1.3, but
       can be negotiated in a TLS 1.3 Client Hello."

- Section D.2
  OLD "weaker than 2048-bit RSA or 224-bit ECDSA are not appropriate"
  NEW "weaker than 2048-bit RSA, 224-bit ECDSA, or 128-bit PSK are not
      appropriate"

- Section D.2 "The reader should refer to the following references for
  analysis of the TLS record layer."
   
  No references given.

---

From: Yuhong Bao <[email-masked]>
Date: Mon, 21 Nov 2016 01:42:37 +0000

I can't help but notice the text:
"Versions of TLS before 1.3 supported compression with the list of supported compression methods being sent in this field. For every TLS 1.3 ClientHello,  this vector MUST contain exactly one byte set to zero, which corresponds to the “null” compression method in prior versions of TLS. If a TLS 1.3 ClientHello is received with any other value in this field, the server MUST abort the handshake with an “illegal_parameter”  alert. Note that TLS 1.3 servers might receive TLS 1.2 or prior ClientHellos which contain other compression methods and MUST follow the procedures for the appropriate prior version of TLS."
IMO, the compression methods section of ClientHello should be ignored as mentioned by Martin Rex.

It may be too late for that, but RC4 IMO should be a SHOULD NOT not a MUST NOT.
One reason for that is that it is not broken the way that say 56-bit encryption is.

From: TLS <[email-masked]> on behalf of Joseph Salowey <[email-masked]>
Sent: Wednesday, October 26, 2016 7:56 PM
To: [email-masked]
Subject: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

This is a working group last call announcement for draft-ietf-tls-tls13-18, to run through November  20. If possible, we would like to receive comments on the list by November 13 so  they can be discussed at the meeting in Seoul. We hope to address any substantive issues raised during that process shortly thereafter.

In order to allow for cryptographic review, we will delay submission of the draft to the IESG until the end of January 2017; there will be an opportunity to address  any issues discovered by the cryptographic community prior to submission to the IESG.

Cheers,

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Nov 2016 19:13:38 -0800

On Sun, Nov 20, 2016 at 5:42 PM, Yuhong Bao <[email-masked]>
wrote:

> "Versions of TLS before 1.3 supported compression with the list of
> supported compression methods being sent in this field. For every TLS 1.3
> ClientHello,  this vector MUST contain exactly one byte set to zero, which
> corresponds to the “null” compression method in prior versions of TLS. If a
> TLS 1.3 ClientHello is received with any other value in this field, the
> server MUST abort the handshake with an “illegal_parameter”  alert. Note
> that TLS 1.3 servers might receive TLS 1.2 or prior ClientHellos which
> contain other compression methods and MUST follow the procedures for the
> appropriate prior version of TLS."

I'm not seeing any good reason for this. We don't want anyone to offer
compression and it's not
like it's difficult for 1.3 implementations to not offer it.

It may be too late for that, but RC4 IMO should be a SHOULD NOT not a MUST
> NOT.

The IETF has already decided this issue:
https://tools.ietf.org/rfcmarkup?doc=7465

-Ekr

> This is a working group last call announcement
> for draft-ietf-tls-tls13-18, to run through November  20. If possible,
> we would like to receive comments on the list by November 13 so  they
> can be discussed at the meeting in Seoul. We hope to address
> any substantive issues raised during that process shortly thereafter.
>
>
> In order to allow for cryptographic review, we will delay submission of
> the draft to the IESG until the end of January 2017; there will be an
> opportunity to address  any issues discovered by the cryptographic
> community prior to submission to the IESG.
>
>
> Cheers,
>
>
> Joe
>
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Nov 2016 14:27:37 +1100

> like it's difficult for 1.3 implementations to not offer it.

I understand Martin Rex's rationale: we are effectively mandating a
requirement on implementations of other versions of the protocol.
However, I agree with ekr.  We have - I think - consensus to forbid
compression more broadly than just in TLS 1.3.  It's a foot gun.

And I don't believe that the foot gun is unique to the web case.  For
example, if you don't believe that mail could contain
attacker-controlled data and secrets, then you haven't thought hard
enough about all the ways mail can be used.  Similarly, insert
protocol of choice.  Of course it's definitely true that someone
loaded and cocked the footgun for the web.