Hi Brian, Thanks for your comments. Answers inline.
On Mon, Mar 13, 2017 at 8:13 PM Brian Sniffen <bsnif...@akamai.com> wrote: > Can you help me understand what this means? > > servers that are authoritative for multiple domains the same > connection but do not have a certificate that is simultaneously > authoritative for all of them > > I'm sure there's a word or two missing between "domains" and "the" in > the first line, but I'm not sure what they are. > This should be: servers that are authoritative for multiple domains but do not have a certificate that is simultaneously authoritative for all of them A common example is an HTTPS reverse proxy that sits in front of domain1 and domain2, has a certificate for each, but not a single certificate that covers both. > > More generally, it's great to see a replacement for renegotiation. Can > you expand (maybe just here?) on the last paragraph of the security > considerations? I think you mean that the sender of an authenticator > can't tell when it was received & understood. But I'm not sure the > receiver can tell when it was sent---say, in the case of a smartcard > insertion, or access to a key from satisfying some local attestation > scheme, whether that key access precedes or follows the sending of a > request. > The application protocol can and should do the accounting for which exported authenticators are created and when they are accepted. The authenticating application can choose its own context id when creating the authenticator and the reciever can use it to map the opaque blob back to the same context id. Here's a simple example: - Party 1 creates an authenticator A1 = authenticate(id1, cert chain, key) - Party 1 sends A1 to Party 2 as part of the application protocol (say as an H2 frame) - Party 2 receives and validates A1, obtaining id1 and cert chain - Party 2 sends back an ACK message such as (id1, valid) at the Application layer. At this point, both parties know the authentication status of the connection and the TLS layer does not. The application keeps track of the accounting, the TLS layer just mints and validates authenticators. This enables applications like HTTP/2 to use TLS certificates for features that would have previously used renegotiation. Nick > -Brian > > Nick Sullivan <nicholas.sulli...@gmail.com> writes: > > > All, > > > > I have updated the draft in preparation for the IETF 98: > > https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-01 > > > > The details of the protocol haven't changed, but I've included some > > security considerations after speaking with Karthikeyan Bhargavan and > > others about the cryptographic soundness of the construction. > > > > Nick > > > > On Tue, Jan 3, 2017 at 8:59 PM Joseph Salowey <j...@salowey.net> wrote: > > > >> There seemed to be support for > draft-sullivan-tls-exported-authentication > >> ( > https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00) > >> in Seoul. Since there has not been much discussion of this draft on > the > >> list we are giving the working group a chance to review the draft before > >> calling for adoption later this month. > >> > >> Cheers, > >> > >> J&S > >> _______________________________________________ > >> 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 > > -- > Brian Sniffen > Akamai Technologies >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
