Hi Keith,
Thanks for raising this and apologies for the delay.
On Fri, Oct 2, 2020 at 5:01 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
This seems like a useful facility for applications, and I know something
I'd like to use it for.
Something that is not immediately clear to me, is whether a middlebox
could insert or remove an Authenticator Request or an Authenticator,
without authorization of the peer(s) that the middlebox is
impersonating. I could see how a middlebox that did this could be
useful. I can also see how the possibility for such a middlebox would
mislead the other peer and make this facility less valuable than it
would otherwise be, if any on-path middlebox could insert or delete
these protocol elements. I would like to see this question addressed
in the Security Considerations section.
Can I safely assume that you are referring to middleboxes with TLS interception? Specifically, ones that act as MITM, splitting the communication between client and server into two connections (client<->mb, mb<->server)? If so, I think putting in text to reason about this scenario is out of scope. This document is focused on connections where the client and server are peers in a shared TLS connection. It's not even possible for this type of middlebox to forward an Authenticator because Authenticators are bound to the channel (due to the signature over the exported by a private key not known to the middlebox).
It concerns me that there's no explicit state change inside TLS when an
authenticator is transmitted, but it might be that I misunderstand that
statement. If either the request or authenticator were protected by
session authentication, to me that sounds like a state change within the
implementation, but not a change to the TLS state machine. Should this
be clarified?
Producing or consuming an EA doesn't change the state of a TLS connection or its security properties. This is because exported authenticators are intended to provide TLS-strength authentication facilities to higher-layer protocols. It's the higher-layer protocol that manages the EA-related state.
Nick
Keith Moore
On 10/2/20 12:59 PM, The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG (tls) to
> consider the following document: - 'Exported Authenticators in TLS'
> <draft-ietf-tls-exported-authenticator-13.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-call@xxxxxxxx mailing lists by 2020-10-16. Exceptionally, comments may
> be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document describes a mechanism in Transport Layer Security (TLS)
> for peers to provide a proof of ownership of an identity, such as an
> X.509 certificate. This proof can be exported by one peer,
> transmitted out-of-band to the other peer, and verified by the
> receiving peer.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf-announce
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
