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
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
