I think that I am OK with the CertificateRequest-like concept (c). The idea that CertificateRequest might be used from client to server (a) is something that I think we might be willing to consider in the fullness of time, but for now I think that it is probably best to avoid making retroactive changes to 8446. But I really do think that this is really just a narrower representation of ClientHello that only includes just the bits that apply to certificate selection.
(Moved to TLS@) On Sun, Nov 17, 2019, at 16:42, Nick Sullivan wrote: > Hi Yaron, > > Thanks for reminding me about the codepoint issue. It's a sticky one. > > As far as I see it, there are three options: > > a) Change the document to UPDATE RFC 8446 > This feels like a heavyweight option and may complicate things since it > will mean that SNI is allowed but undefined for CertificateVerify in > the TLS handshake. > > b) Ask for a new extension point for SNI sent in a client-generated > authenticator request. > This has the downside of not scaling to future client hello extensions > that could be useful in exported authenticator requests -- it forces > the definition of a new code point for each new extension. > > c) Explicitly state that the CertificateRequest-like construction in > client-generated exported authenticator requests is a new type of > message (analogous to a ClientHello) and clarify the rules about which > extensions can be used when it is client-generated (specifically, say > that any extension supported in CH is allowed) > This is my preferred solution. > > I'm interested to hear what the working group thinks, and I'll happily > present the options at IETF 106 if there's time. > > Best, > Nick > > On Mon, Nov 4, 2019 at 6:20 PM Yaron Sheffer <[email protected]> wrote: > > Hi Nick,____ > > > __ __ > > > Apologies for not responding on time.____ > > > __ __ > > > I may be missing some follow-on discussions, but:____ > > > __ __ > > > * Ben suggested that we mention that QUIC is also an option, even if > > informatively, in addition to the “SHOULD use TLS” statement.____ > > * I think we left my question re: back-fitting this protocol into the IANA > > TLS registry open. Quoting: ____ > > __ __ > > > YS: 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.____ > > > __ __ > > > NS: 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____ > > > __ __ > > > BK: Or, since extension codepoints are cheap, just use a new codepoint.____ > > > __ __ > > > Thanks,____ > > > Yaron____ > > > __ __ > > > *From: *Nick Sullivan <[email protected]> > > *Date: *Monday, November 4, 2019 at 04:49 > > *To: *Yaron Sheffer <[email protected]> > > *Cc: *<[email protected]>, > > <[email protected]>, <[email protected]>, > > "<[email protected]>" <[email protected]> > > *Subject: *Re: Secdir last call review of > > draft-ietf-tls-exported-authenticator-09____ > > > __ __ > > > 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
