Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator

Thanks for the review. I'm open to adding text indicating that the exported
authenticator SHOULD be sent using an application protected by the TLS
stream in question, but I don't want to remove the possibility of sending
the data over a secure secondary channel, depending on the application.

Nick

On Tue, Apr 18, 2017 at 8:29 AM Victor Vasiliev <vasilvv@google.com> wrote:

> I've read the draft, and I support its adoption.  I believe that the
> mechanism
> is sound for its stated use.
>
> I have some minor concerns about the wording in the draft, though.  First,
> the
> draft describes the authenticators as sent "out-of-band", while my
> understanding is that they are always intended to be sent in-band as
> application data.  If they were truly sent out-of-band, there would be some
> questions about the security analysis, because that would imply those
> could be
> sent unprotected.  Hence, I suggest the draft to adapt the premise that
> exported authenticators MUST be sent as application data within the same
> connection.  This might simplify your security proofs too.
>
> The second issue I have is with the question of when does authentication
> succeed.  In TLS, by the time any party can send application data, normally
> (with exception of server-to-client data in client auth case) both parties
> know
> that the other side has authenticated them.  Here, a new identity is
> introduced
> while application data can be already in flight, and it's not clear to me
> when
> the sender of the exported authenticator can act assuming the peer has
> accepted
> its new identity.  My current understanding is that this issue is deferred
> to
> the application layer, but it would be nice to discuss those considerations
> explicitly.
>
> The last question I have is how does this interact with the state of TLS
> connection.  Does accepting a new identity mean that the entire connection
> now
> has that identity too?  Does this mean that the session tickets issued
> after
> the library receives the authenticator are valid for the new identity?
> Does it
> make the tickets sent previously on that connection valid for the new
> identity?
>
> Also, what is the distinction between "jointly authoritative for A and B"
> and
> "individually authoritative for A and individually authoritative for B"?
>
>   -- Victor.
> On Fri, Apr 14, 2017 at 12:29 AM, Joseph Salowey <joe@salowey.net> wrote:
>
>> Hey Folks,
>>
>> At the IETF 98 meeting in Chicago there was support in the room to adopt
>> draft-sullivan-tls-exported-authenticator [0]. We are looking for
>> feedback on adopting this draft form the list. Please respond if you
>> support the draft and are willing to review it. If you object to its
>> adoption, please let us know why. Please respond to the list by 20170501
>>
>> Cheers,
>>
>> J&S
>>
>> [0]
>> https://datatracker.ietf.org/doc/html/draft-sullivan-tls-exported-authenticator
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>