[Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eap-tls13-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-emu-eap-tls13/



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

I'm going to defer this document's evaluation because I think there are
several interrelated subtle issues that merit closer consideration than
has been given so far.  I will also invite the TLS WG to provide input
on these issues, since they relate to rather fundamental issues of the
operation of the TLS sub-protocols.

Most of them concern the Commitment Message, in terms of what goals it
aims to achieve, how it is specified, and what mechanism is used to
effectuate it.

To start with the easy one: currently the way in which the structure of
the Commitment Message is described makes reference to many fields of
TLS Record Layer structures in order to specify what is fundamentally a
message on the TLS Application Data stream.  This is a layering
violation; I don't see any reason to say more than what was suggested in
https://mailarchive.ietf.org/arch/msg/emu/ECgvnq-C_VVXT5bpvOowte8LBjw/ :
"the commit[ment] message is a single byte of [value] 0 in the application data
stream".  All the bits about cryptographic protection and expansion of the
plaintext in prepararation for record protection are just adding noise,
and the interface between the TLS stack and the application is supposed
to be a data-stream abstraction, not a record abstraction.

Next, the whole reason for the existence of a Commitment Message seems
under-justified -- the only mention I could find in the document is that
it serves "to decrease the uncertainty for the EAP-TLS peer".  What harm
would be caused by a lack of certainty in this area?  Why does waiting
for an EAP-Success or EAP-Failure not provide a similar level of
certainty?

The document also suggests in several places that the Commitment Message
can or should be sent at 0.5-RTT data in the same flight as the server
Finished.  The intent, as determined from the mailing list archive,
seems to be to save a round-trip compared to a typical full message flow
where the server does not send application data until after the client's
Finished (and any application data alongside it) is received.  In
particular, this came out during discussion of how a TLS "close_notify"
alert would be unsuitable for the role of the Commitment Message, since
sending the "close_notify" in 0.5-RTT would prevent sending an alert if
the client authentication failed, and the diagnostic value of such
alerts is significant.  This is where the issues start to become
interrelated -- the Commitment Message as a new application-data
construct is for the objective of reducing the number of round trips.
However, TLS session resumption is also designed to reduce the number of
round-trips (including by no longer needing to send potentially large
TLS Certificate messages that get fragmented at the EAP layer, with the
cost of a round trip per fragment), and there is a nasty interaction
between the two mechanisms.  Specifically, TLS 1.3 session resumption
requires the use of a NewSessionTicket message, which is associated with
a resumption secret; the resumption secret, in turn, is not available in
the key schedule until the client Finished (and client authentication
messages, if any) is available.  While it is possible in many Web
scenarios for NewSessionTicket to be issued in the 0.5-RTT flight, this
is because the server can precompute what the valid client Finished
would be and use that in the key schedule to precompute the resumption
secret.  If the client is to be authenticated, as is the case for the
vast majority of EAP exchanges, then such precomputation is impossible,
and the session ticket cannot be issued until the extra round trip is
completed.  The document contains no discussion of the inherent tradeoff
between sending the commitment message in 0.5-RTT and using resumption,
and this tradeoff seems to call into question the merits of choosing
this mechanism to implement the commitment message, since...

The commitment message as specified seems to itself be a layering
violation.  The TLS protocol itself consists of a few sub-protocols,
e.g., the handshake protocol, record protocol, and alert protocol.  The
operation of the handshake protocol is supposed to be completely
independent of the application-data record protocol (except to the
extent that the handshake protocol supplies the keys used for
cryptographic protection of application data records).  In particular,
there should not be any interaction between the handshake state machine
and the application data.  If there is to be a commitment made about the
operation of the TLS handshake protocol, that more properly belongs in
the handshake layer itself, or perhaps the alert layer if it relates to
the overall operation of the TLS connection.  It seems inappropriate and
unsustainable to expect that an application-data message would affect
the operation of the handshake layer.

The use of application data for the commitment message also may have
unfortunate interactions with other TLS-using EAP methods, which is very
briefly mentioned as a possibility but not explored at all:

   While EAP-TLS does not protect any application data except for the
   Commitment Message, the negotiated cipher suites and algorithms MAY
   be used to secure data as done in other TLS-based EAP methods.

If we are to expect this construction of commitment message to become
the de facto standard for using TLS 1.3 with EAP, I think we need to
consider whether other EAP methods that do need to actually protect
application data with the TLS connection will be affected by this
proposal to insert the EAP commitment message into the application data
stream.  This is worth particular consideration given that we require
that "EAP-TLS peer implementations MUST accept any application data as a
Commitment Message from the EAP-TLS server to not send any more
handshake messages" -- these seem like new semantics that might be quite
unexpected if applied to other EAP methods.

There's also a few internal inconsistencies that raise to a
discuss-level and will need to be resolved before publication:

The body text around Figure 3 indicates that mutual authentication
should be depicted, but the figure shows only normal server-only
authentication.

The example in Figure 8 needs a TLS CertificateRequest in there in order
for the rest of the flow to make sense.

Section 2.1.4 says that "TLS warning alerts generally mean that the
connection can continue normally and does not change the message flow."
but this is no longer true with TLS 1.3 -- the only alerts sent at
warning level are "close_notify" and "user_cancelled", both of which
indicate that the connection is not going to continue normally.

Section 2.1.9 claims that the largest size of a TLS record is 16387
octets, but by my count a TLSCiphertext can get up to 16643, since the
length field "MUST NOT exceed 2^14 + 256 bytes" (and there's the other 3
bytes of header).

Please also check the statements made about RFC 8446 that I note in my
comments on Section 5.1.


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

Some of these comments are a bit rough, as I did not do my full editing pass
since I plan to defer the ballot.  I'm including them anyway as they still
seem likely to be useful even in this form.

I strongly suggest that the option for the server to send an alert
instead of HelloRetryRequest in the case of missing "key_share" be
removed; see my comments on Section 2.1.3.  As far as I can tell this
option is flat-out bad practice and should not be allowed.

I also strongly suggest that the WG make the simple modification to the
key schedule that I suggest in my comments on Sections 2.3 and 5.5, that
would have the effect of achieving the property anticipated by Section
5.5 of RFC 5216, whereby incorporating the EAP-TLS Type information into
the key derivation formula prevents a type of packet modification
attack.

Abstract

   reduced latency when compared to earlier versions of TLS.  EAP-TLS
   with TLS 1.3 further improves security and privacy by mandating use
   of privacy and revocation checking.  This document also provides

I agree with the secdir reviewer that some indication of what is meant
by (EAP) "privacy" here is likely in order.

Section 1

   In addition to the improved security and privacy offered by TLS 1.3,
   there are other significant benefits of using EAP-TLS with TLS 1.3.
   Privacy is mandatory and achieved without any additional round-trips,

(ditto)

Section 2.1.1

   for resumption.  SessionID is deprecated in TLS 1.3 and the EAP-TLS
   server SHALL ignore the legacy_session_id field if TLS 1.3 is
   negotiated.  TLS 1.3 introduced early application data which is not

(nit) we could perhaps quibble about whether "SHALL ignore" is
consistent with the RFC 8446 requirement to echo the legacy_session_id
value from the ClientHello in the ServerHello, though I'm not going to
make a big deal about it.

   used in EAP-TLS.  A EAP-TLS server which receives an "early_data"
   extension MUST ignore the extension or respond with a
   HelloRetryRequest as described in Section 4.2.10 of [RFC8446].

It's probably better to place restrictions on the indication that early
data might be possible, than to (just) place restrictions on accepting
it.  That is, if the server is forbidden from generating a
NewSessionTicket message that includes the "early_data" extension, then
the client is also forbidden from sending "early_data" in a ClientHello.
[ed. we do do this in §2.1.2]

Section 2.1.3

   full handshake.  It is left up to the EAP-TLS peer whether to use
   resumption, but it is RECOMMENDED that the EAP-TLS server accept
   resumption as long as the ticket is valid.  However, the EAP-TLS

But the EAP-TLS server sets how long the ticket is valid :)
Should we give some guidance on how long that should be (noting that it
must say within the RFC 8446-mandated 7 day maximum).

   was used in the original full authentication.  E.g. the NAI @realm
   can safely be reused, while the NAI ZmxleG8=@realm cannot.  The TLS

(Does base64("flexo") have enough randomness to be reflective of a good
privacy NAI?)

   A subsequent authentication using resumption, where both sides
   authenticate successfully (without the issuance of more resumption
   tickets) is shown in Figure 3.

(It's slightly surprising to show an example of resumption without
issuing additional resumption tickets, since such issuance is basically
necessary in order to comply with the recommendation from earlier in the
section to follow the client tracking prevention mechanisms in Appendix
C.4 of RFC 8446.  Though I guess draft-ietf-tls-ticketrequests is
potentially relevant for just how necessary it is going to be in
practice.)

   back to a full handshake.  If the EAP-TLS peer did not supply a
   "key_share" extension when attempting resumption, the EAP-TLS server
   needs to reject the ClientHello and the EAP-TLS peer needs to restart
   a full handshake.  The message flow in this case is given by Figure 4
   followed by Figure 1.

   Also during resumption, the EAP-TLS server can respond with a Hello
   Retry Request (see Section 2.1.6) or issue a new ticket (see
   Section 2.1.2)

I don't understand why the "alert plus fresh handshake" flow is even
listed as an option -- AFAICT the HelloRetryRequest (note: no spaces)
flow is uniformly superior.  There is no benefit in round-trip count to
starting a fresh handshake, and HelloRetryRequest allows the initial
interaction to be authenticated by the continued handshake transcript.
Aborting and starting over is analogous to the dreaded "downgrade dance"
that has periodically plagued the TLS ecosystem, and I'm confused that
we would consider encouraging it to return.  I would instead say that
the server "needs to send HelloRetryRequest to signal that additional
information is needed to complete the handshake, and the EAP-TLS peer
needs to send a second ClientHello containing that information" (or
similar), and drop the "Figure 4 followed by Figure 1" sentence.  (The
final paragraph would then become a bit redundant, but perhaps there is
still some information that should be persisted.)

Section 2.1.4

   The two paragraphs below replaces the corresponding paragraphs in
   Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or
   higher.  The other paragraphs in Section 2.1.3 of [RFC5216] still
   apply with the exception that SessionID is deprecated.

      If the EAP-TLS peer authenticates successfully, the EAP-TLS server
      MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing
      TLS records conforming to the version of TLS used.  The message
      flow ends with the EAP-TLS server sending an EAP-Success message.

      If the EAP-TLS server authenticates successfully, the EAP-TLS peer
      MUST send an EAP-Response message with EAP-Type=EAP-TLS containing
      TLS records conforming to the version of TLS used.

Just to walk through the various scenarios here; if the last message of
the TLS handshake for a given TLS version is sent by the TLS client, that
will go in an EAP-Response, so the server is then able to send
EAP-Success directly.  On the other hand, if the last TLS handshake
message is sent by the server, that will have to go in an EAP-TLS
EAP-Request, and so the peer will have to send an empty EAP-TLS response
in order for the server to be able to wend EAP-Success?  Do we need to
have any text here to handle that empty EAP-TLS Eap-Request case?

   In the case where the EAP-TLS server rejects the ClientHello with a
   fatal error, the conversation will appear as shown in Figure 4.  The

Should we perhaps say that these examples are with TLS 1.3, even if the
actual normative protocol is no longer tied to a specific TLS version?

Section 2.1.5

In some sense, this figure depicting the no-peer-authentication case is
just an example specific to TLS 1.3 and is not necessarily
representative of the generic EAP-TLS case for potential future versions
of TLS.  Should we make that more clear from the prose?

Section 2.1.6

   the handshake.  One use case is if the EAP-TLS server does not
   support the groups in the "key_share" extension, but supports one of

I'd consider adding a parenthetical "(or there is no "key_share"
extension)".

Section 2.1.8

   username in cleartext in the Identity Response.  Following [RFC7542],
   it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but
   other constructions such as a fixed username (e.g. anonymous@realm)
   or an encrypted username (e.g.  YmVuZGVy@realm) are allowed.  Note

(I note that YmVuZGVy is just base64("bender"); does that really count
as "encrypted"?)

Section 2.3

The use of a constant 0x0D (the "Type-Code") as the TLS-Exporter context
is rather unusual; per RFC 8446 this value is intended to be a
"per-association context value provided by the application using the
exporter" per RFC 5705 -- this value is not a per-association value but
rather a global one.

Section 2.4

   While EAP-TLS does not protect any application data except for the
   Commitment Message, the negotiated cipher suites and algorithms MAY
   be used to secure data as done in other TLS-based EAP methods.

This makes me uncomfortable -- is this other data being secured going to
live in the same "namespace" as the Commitment Message?

Section 2.5

   and TLSPlaintext.fragment = 0x00).  Note that the length of the
   plaintext is greater than the corresponding TLSPlaintext.length due

(This sentence reads oddly; perhaps "length of the TLSInnerPlaintext" is
more clear?  But we shouldn't be saying this at all, per the Discuss.)

Section 5.1

   [2] Confidentiality: The TLS 1.3 handshake offers much better
   confidentiality than earlier versions of TLS by mandating cipher
   suites with confidentiality and encrypting certificates and some of
   the extensions, see [RFC8446].  When using EAP-TLS with TLS 1.3, the

I note that there exist codepoints for TLS 1.3 ciphersuites that do not
provide confidentiality protection.  Please point to the part of RFC
8446 that mandates this behavior.

   [3] Key strength: TLS 1.3 forbids all algorithms with known
   weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5.  TLS 1.3

Where does RFC 8446 forbid 3DES?  CBC is forbidden by the requirement to
be AEAD, and RC4 and MD5 are explicitly forbidden, but the situation for
SHA-1 is more subtle.  Please reword this sentence to be accurate.

Section 5.4

   When EAP-TLS is used with TLS 1.3, the revocation status of all the
   certificates in the certificate chains MUST be checked.

What does this mandatory checking entail when a certificate contains
neither a CRL Distribution Point nor an OCSP responder URL?  (See also
the recent thread on the LAMPS WG list with Subject: "The
id-ce-noRevAvail extension".)

   TLS, see Section 4.4.2.1 of [RFC8446].  In TLS 1.3 the OCSP
   information is carried in the CertificateEntry containing the
   associated certificate instead of a separate CertificateStatus
   message as in [RFC4366].  This enables sending OCSP information for

RFC 4366 seems like a stale (obsolete) reference, and RFC 6066 should be
preferred.  (RFC 4366 would then become an unused reference, I believe.)

   To enable revocation checking in situations where EAP-TLS peers do
   not implement or use OCSP stapling, and where network connectivity is
   not available prior to authentication completion, EAP--TLS peer
   implementations MUST also support checking for certificate revocation
   after authentication completes and network connectivity is available,
   and they SHOULD utilize this capability by default.

If it's RECOMMENDED to use OCSP stapling, what does it mean that they
"SHOULD utilize this capability by default" (as well)?

(Also, nit: only one '-' in EAP-TLS.)

Section 5.5

It seems like there may be some scope for improvements on the RFC 5216
behavior here.  For example, what if we used the EAP Type field as the
TLS Exporter 'context' argument, instead of the literal 0x0D?  That
seems like it would prevent the modification from successfully causing a
different TLS-based EAP method to be used, by using a different
key-derivation formula, exactly as postulated by RFC 5126.

Section 5.7

   and the authorizations of the other party may have been reduced.  If
   the cached revocation is not sufficiently current, the EAP-TLS peer
   or EAP-TLS server MAY force a full TLS handshake.

nit: s/cached revocation/cached revocation data/

   in the certificate chain has been revoked or has expired.  In all
   such cases, resumption results in a full TLS handshake instead.

nit: s/resumption results/an attempt at resumption results/ (or similar)

   If any authorization, accounting, or policy decisions were made with
   information that have changed between the initial full handshake and
   resumption, and if change may lead to a different decision, such
   decisions MUST be reevaluated.  It is RECOMMENDED that authorization,
   accounting, and policy decisions are reevaluated based on the
   information given in the resumption.  [...]

I'm not sure I understand how these two sentences fit together.  Is it
trying to say that "if there could be a different decision, you
definitly have to re-check, and we recommend just always re-checking
since that's timpler"?

   Where a good decision is unclear, EAP-TLS servers SHOULD reject the
   resumption.

I suggest "reject the assumption and continue with a full handshake".

   Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security
   considerations for resumption.

I'm curious why specifically § 8.1 and 8.2 were selected, given that §8
as a whole is about "0-RTT and Anti-Replay", which is a more specific
topic than just resumption.

Section 5.8

   Tracking of users by eavesdropping on identity responses or
   certificates is a well-known problem in many EAP methods.  When EAP-
   TLS is used with TLS 1.3, all certificates are encrypted, and the
   username part of the identity response is always confidentiality
   protected (e.g. using anonymous NAIs).  [...]

As written this applies to server certificates as well as TLS client
certificates.  For which the statement is technically true, but with the
caveat that it is typically easy to persuade the server to (re-)send
those same certificates encrypted to a key known to the attacker, so the
protection provided by the encryption is limited.  (The server has been
fairly strongly authenticated by the time the EAP peer makes the
decision to send its certificate, so there the reverse situation is
different.)

   and only using the pseudo-random usernames a single time.  Note that
   the privacy-friendly usernames also MUST NOT include substrings that
   can be used to relate the identity to a specific user.  Similarly,
   privacy-friendly username SHOULD NOT be formed by a fixed mapping
   that stays the same across multiple different authentications.

I think that violating the SHOULD NOT would intrinsically violate the
preceding MUST NOT ... so should they both be MUST NOTs?

   static RSA based cipher suites without privacy.  This implies that an
   EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS
   server responds to an empty certificate message with a TLS alert
   message.

Just to check my understanding, this "response" would be an EAP-TLS
response containing a new ClientHello (that would proceed to do a
handshake including the client certificate in the unprotected initial
handshake)?  That is, it would be a response at the EAP layer but not at
the TLS layer.

Section 5.9

   Pervasive monitoring refers to widespread surveillance of users.  In
   the context EAP-TLS, pervasive monitoring attacks can target EAP-TLS

nit: "context of"

Section 5.10

   summarizes the attacks that were known at the time of publishing and
   [RFC7525] provides recommendations for improving the security of
   deployed services that use TLS.  However, many of the attacks are

Using BCP195 as the slug is probably preferred, since any RFCs
associated with the BCP are going to be relevant and topical.