> How many Certificate+CertificateVerify messages would a client be permitted > to send. 1? N?
I don't see a good reason to restrict to 1, although in many cases it would probably suffice. > If the answer to the above is N, does the client's > Certificate+CertificateVerify somehow identify the CertificateRequest? > That is, how does the server identify whether this is unilateral or in > response to its own request? The model I'm thinking of is where the server receives a request from the client, determines that the request requires authentication, then queries session state to see whether a suitable client credential is available. If such client credential is not available, the server sends CertificateRequest. In this model, it does not matter whether the client volunteered a credential or responded to the server's request. > How does a client determine if the NewSessionTicket that it receives includes > its authentication? That is, how can a client know whether a resumed session > will need a certificate or not? (I'm not sure about this one, but the first > thought that occurs is that the server could include an indicator in the > NewSessionTicket message.) I'd say the client should send the latest ticket it has, assume that it has all session context including client identity, and the server will request creds if this is not the case. > Does the session need to be rekeyed as a result of this new information? (I > think not, though see above regarding analysis.) Agree on both points: the need for rekey is not obvious; until proved otherwise, I'm assuming no rekey. > Do we allow for application data between Certificate and CertificateVerify? > (I think not.) No application data between Certificate and CertificateVerify. > What value do you see in having a spontaneous NewSessionTicket messages? Is > this just a case of not wanting to bind it more formally to something that > the client sends? The reason I want to allow NewSessionTicket messages in mid-stream is to allow the server to include newly obtained client creds in the session state. If the server wants to do this, it can send NewSessionTicket after processing the client's CertificateVerify. -----Original Message----- From: Martin Thomson [mailto:martin.thom...@gmail.com] Sent: Tuesday, September 15, 2015 2:38 PM To: Andrei Popov <andrei.po...@microsoft.com> Cc: tls@ietf.org Subject: Re: [TLS] Review of PR #209 This sounds like a good idea. I certainly like how it eliminates a number of variations (particularly the one that #209 added). It enables unilateral client authentication, which is a big plus. My biggest concern would be the one you note and how this interacts with the session transcript. It seems OK to me, but I'd like Hugo or Karthik to spend a few cycles thinking about that one before I'm confident there isn't an actual problem. How many Certificate+CertificateVerify messages would a client be permitted to send. 1? N? (I think 1) If the answer to the above is N, does the client's Certificate+CertificateVerify somehow identify the CertificateRequest? That is, how does the server identify whether this is unilateral or in response to its own request? How does a client determine if the NewSessionTicket that it receives includes its authentication? That is, how can a client know whether a resumed session will need a certificate or not? (I'm not sure about this one, but the first thought that occurs is that the server could include an indicator in the NewSessionTicket message.) Does the session need to be rekeyed as a result of this new information? (I think not, though see above regarding analysis.) Do we allow for application data between Certificate and CertificateVerify? (I think not.) Question: What value do you see in having a spontaneous NewSessionTicket messages? Is this just a case of not wanting to bind it more formally to something that the client sends? I worry that we'll have cases where the session tickets encompass new states if we permit that. On 15 September 2015 at 13:17, Andrei Popov <andrei.po...@microsoft.com> wrote: > Perhaps we can simplify the protocol by pulling client auth out of the > handshake as follows: > > 1. CertificateRequest, client Certificate, CertificateVerify and > NewSessionTicket messages use a new content type distinct from "handshake". > 2. The client can send Certificate and CertificateVerify at any time > application data is permitted, regardless of whether the server had > previously sent CertificateRequest. > 3. The server can send CertificateRequest and NewSessionTicket at any time > application data is permitted. Alternatively, the server can encapsulate > CertificateRequest in an application protocol message. > > Encapsulating CertificateRequest in an application protocol message allows > the client to determine which specific application request resulted in the > need for client auth. The application protocol would of course need to allow > this. > > As far as I can tell, the above scheme seems to work in both 0-RTT and 1-RTT > modes. > > We can decide exactly what CertificateVerify would be signing: whether it's > the handshake hash or some form of RFC5705 Exported Keying Material (EKM). > > Thoughts? > > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson > Sent: Saturday, July 25, 2015 8:00 AM > To: tls@ietf.org > Subject: [TLS] Review of PR #209 > > Andrei proposes two changes in > https://github.com/tlswg/tls13-spec/pull/209 > > The first expands the ways in which a server can identify certificates. This > is fine. I do wonder whether we can remove CertificateType entirely for TLS > 1.3 though (that can be done separately). > > The second is worrisome. I don't like that a handshake message now has two > different potential locations that it might appear in. That seems like a > hazard. I think that we need a new content type for a new message that can > be used after the handshake completes. Then there are two options: > a) remove CertificateRequest from the handshake entirely and allow > the handshake to complete before authenticating (this has a number of > hazards that make it probably worse than the duplication it addresses) > b) use CertificateRequest within the handshake, and the new content > type outside of it > > _______________________________________________ > 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
