Subject: Re: [Last-Call] Last Call: <draft-ietf-tls-exported-authenticator-13.txt> (Exported Authenticators in TLS) to Proposed Standard

From: Nick Sullivan <[email-masked]>
Date: Mon, 8 Mar 2021 11:48:55 -0500

Hi Keith,

Thanks for raising this and apologies for the delay.

On Fri, Oct 2, 2020 at 5:01 PM Keith Moore <[email-masked]>
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
> > [email-masked] mailing lists by 2020-10-16. Exceptionally, comments
> may
> > be sent to [email-masked] 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf-announce
>
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>