Following up, Yaron, do the responses by myself and Benjamin along with the does the following PR sufficiently address your comments/concerns?
https://github.com/tlswg/tls-exported-authenticator/pull/52 On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan <[email protected]> wrote: > Hi Yaron, > > Thank you for your thorough review. My answers will be inline, and I'll > incorporate some of Ben's replies if necessary. Here's a PR with proposed > changes in response to your comments: > https://github.com/tlswg/tls-exported-authenticator/pull/52 > > On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker < > [email protected]> wrote: > >> Reviewer: Yaron Sheffer >> Review result: Has Issues >> >> The document is generally clear in both its motivation and the proposed >> solution. >> >> I think it's playing a bit too liberal with TLS 1.3, in sort-of but not >> quite >> deprecating renegotiation, and in changing the IANA registry in a way that >> actually changes the protocol. Details below. >> >> Other comments: >> >> * Abstract: please reword to make it clear that it's the proof (not the >> cert) >> that is portable. > > > Proposed text here: > This document describes a mechanism in Transport Layer Security (TLS) for > peers to > provide a proof of ownership of a certificate. This proof can be exported > by one peer, transmitted out-of-band to the other peer, and verified by > the receiving peer. > > * Introduction: TLS 1.3 post-handshake auth "has the >> disadvantage of requiring additional state to be stored as part of the TLS >> state machine." Why is that an issue is practice, assuming this feature is >> already supported by TLS libraries? Also, are we in effect deprecating >> this TLS >> 1.3 feature because of the security issue of the mismatched record >> boundaries? >> > > My understanding is that post-handshake authentication as defined in the > TLS 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries and some > implementors would prefer to use exported authenticators. > > * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? > > I'm fine with this. > > >> * Authenticator Request: please clarify that we use the TLS 1.3 format >> even when >> running on TLS 1.2. > > Updated, though it might be a bit unnecessary. > > * Also, I suggest to change "is not encrypted with a >> handshake key" which is too specific to "is sent unencrypted within the >> normal >> TLS-protected data". > > This specific text is meant to differentiate the wire format of this > message from that of the CertificateRequest message, which is encrypted > with the handshake key. The specificity is warranted. > > * Before diving into the detailed messages in Sec. 3, it >> would be nice to include a quick overview of the message sequence. > > There are two message types and three potential sequences. I've added a > short overview. > > >> * Sec. 3: >> "SHOULD use TLS", change to MUST. There's no way it can work otherwise >> anyway. >> > As Ben noted, this could be any secure channel with equivalent security to > TLS, such as QUIC. We shouldn't forbid other secure out-of-band mechanisms. > > >> * "This message reuses the structure to the CertificateRequest message" - >> repeats the preceding paragraph. > > Fixed > > >> * Sec. 4: again, SHOULD use TLS -> MUST. > > Again, I don't see the need for a MUST here. > > >> * Is >> there a requirement for all protocol messages to be sent over a single TLS >> connection? If so, please mention it. Certainly this is true for the >> Authenticator message that must be sent over a single connection and >> cannot be >> multiplexed by the high-level protocol. I think this protocol actually >> assumes >> "nice" transport properties (no message reorder, reliability) that also >> require >> a single, clean TLS connection. > > There is no such requirement. Message ordering is managed by the > application layer protocol that utilizes exported authenticators. > > >> * Why no authenticator request for servers? >> Don't we care about replay? OTOH if the client wants to detect replays, it >> would need to keep state on received authenticators, which would be very >> messy. >> > I'm not sure I understand. It's possible to use authenticator requests for > servers. > > * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. > > Added "Sec. 7.5" > > * The >> discussion of Extended Master Secret only applies to TLS 1.2 - please >> clarify >> that, plus I suggest to reword this paragraph which I find hard to parse. > > re-worded > > * >> 4.2: "the extensions are chosen from the TLS handshake." - What does it >> mean >> exactly, and how does an application even know which extensions were used >> at >> the TLS layer? Reading further, we mention "ClientHello extensions." >> Maybe the >> authenticator should also include a ClientHello message to indicate >> supported >> extensions. Assuming we can peek into ClientHello contradicts the hopeful >> "even >> if it is possible to implement it at the application layer" in Sec. 6. > > > This could be clearer. Effectively, the Certificate message in the > Authenticator needs > to be constructed in a similar manner to how a Certificate message would > be created > in a TLS handshake. Namely, it can only contain extensions that were > present in either > the client hello or a preceding CertificateRequest. > > You're right that this makes an assumption that the party creating the > Authenticator > has access to the TLS handshake state. This implies that even if the > Authenticator > is created in the application space, an additional API needs to be exposed > to share > that information. > > * 4.2.1: >> the first sentence of the section is incomplete. > > > Fixed > > >> * Can I use TLS 1.3-specific >> extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there >> a >> situation where a certificate is acceptable for TLS 1.3 connections but >> not for >> TLS 1.2 connections? > > Yes TLS 1.3-specific extensions are allowed, the CertificateRequest > message is TLS 1.3-compatible. > > >> * "using a value derived from the connection secrets" - I >> think we should recommend a specific construction here to ensure people >> do it >> securely. > > This was a suggestion from the Additional Certificates use case ( > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-05). > I'm not sure we should get into the details here. > > >> * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If >> so, please say so. > > Yes, I'll put that in. > > * 4.2.4: "a constant-time comparison" - why is it actually >> required, what is the threat? An attacker can do very little because each >> authenticator being sent is different. > > As Ben noted, this was a safety note added during review. > > >> * 5: please say explicitly which >> messages are used in this case to construct the authenticator. > > > Re-written. > >> * 6.1: the >> "MUST" is strange in a section that's only supposed to be informative. >> Also, >> the library may provide this extension (and possibly others) without >> requiring >> it as input. > > How else do you propose wording the requirement that this API fail if the > connection doesn't support EAs? > > >> * 6.4: "The API MUST return a failure if the >> certificate_request_context of the authenticator was used in a previously >> validated authenticator." Are we requiring the library to keep previous >> contexts for replay protection? If so, please make it explicit. > > I think this can be a SHOULD based on the burden replay protection places > on the implementation. > > >> * 7.1: this is >> changing TLS 1.3 by allowing this extension in Cert Request! I think it's >> a >> really bad idea. Better to hack special support to existing libraries, >> allowing >> this specific extension for this special case, than to change the base >> protocol. Otherwise, this document should UPDATE 8446. > > > This is a good point and one that we struggled a bit with during design. > We needed to allow SNI in the CertificateRequest message because it can be > client-generated in this context. I'd be ok with creating a different > extension for this, but it's rather elegant to re-use it in this context. *I'd > like to hear some opinions from the working group* on this point > > >> * 8: I think the >> Security Considerations is the right place to talk about interaction >> between >> this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply >> RECOMMEND >> not to do it. Or else explain the use cases where renegotiation is still >> useful >> if there are any. >> > > I'm not sure this document should be prescriptive about use cases. This > doc is providing a new capability that may be leveraged at the application > to replace the functionality of existing mechanisms, but I'm not convinced > the evaluation of the trade-offs of different mechanisms should be > contained in this document. >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
