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

From: Keith Moore <[email-masked]>
Date: Fri, 2 Oct 2020 17:00:52 -0400

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.

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?

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