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

[Benjamin Kaduk <[e-mail]>]

Hi TLS WG,

I'm forwarding my ballot comments on the (now-deferred) EAP with TLS 1.3
draft here, since they relate to some rather core TLS protocol concepts,
and I'd like to get some broader feedback with the extra time given by
deferring the ballot.

Please ensure that comments reach the EMU WG list (cc'd).

Thanks,

Ben

On Wed, Dec 16, 2020 at 02:36:50PM -0800, Benjamin Kaduk via Datatracker wrote:
> 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.
> 
> 
>