[TLS] (bonus) AD review draft-ietf-tls-subcerts
As this document already saw an AD review by Ben Kaduk, I will not further hold up this document. Ben's write up can be found at: https://mailarchive.ietf.org/arch/msg/tls/qa908s0dMNxbUOZhnUel0qEVBSg/ Please treat the below as you would treat any other comments. Test vectors available but still not included - did these get verified ? Can these be included? expected_cert_verify_algorithm - why is this not called dc_cert_verify_algorithm or dc_verify_algorithm ? As in, why is there an "expected" prefix? We talk about signature_algorithms and not expected_signature_algorithms ? algorithm: The signature algorithm used to verify DelegatedCredential.signature. This reads weird. If the signature algorithm is "used", it was to create the signature. The verification is in the future though. Perhaps say "The signature algorithm used to create the DelegatedCredential.signature" 1. A string that consists of octet 32 (0x20) repeated 64 times. - Why is there a 64 spaces prefix ? - Should it say a non-null terminated string? Or perhaps "octet stream" instead of "string" ? 2. The context string "TLS, server delegated credentials" for server authentication and "TLS, client delegated credentials" for client authentication. - Same here, non-null terminated string? 3. A single 0 byte, which serves as the separator. a few lines up it used hex notation for 0x20 and named it octet. Should this be called a single octet of value 0x00 ? A client which supports this specification SHALL send a "delegated_credential" extension in its ClientHello. This oddly means that a client that supports this cannot really choose to not use it. Normally, this is more written as "A client that is willing to use DC includes a "delegated_credential" extension in its ClientHello" If the client receives a delegated credential without having indicated support in its ClientHello According to the above, this "SHALL" not happen because to recognise the extension it needs to support it and if it supports it, it SHALL send it :) The server MUST ignore the extension unless (D)TLS 1.3 or a later version is negotiated. That is oddly phrased as a MUST with an exception (which is really a SHOULD) Perhaps: "When a (D)TLS version negotiated is less than 1.3, the server MUST ignore this extension" The client MUST ignore the extension unless (D)TLS 1.3 or a later version is negotiated. Same here. The server MUST send the delegated credential Should that be "delegated_credential", eg underscore instead of space? Or use DC ? the server SHOULD ignore delegated credentials sent as extensions to any other certificate. Why is the case a "SHOULD ignore" where all the other cases of unexpected DC uses "MUST " ? I'm a little confused by Section 7.4. Interactions with Session Resumption. The session resumption uses a seperate continue mechanism that omits needing to re-authenticate the peer. It has its own session ticket lifetimes to keep its state. Why is that mechanism on its own not enough? If the server still has the session state why would a valid DC be a requirement to use an existing ticket? Or phrased differently, one could say that a session resumption ticket lifetime should never fall outside the DC validity period (if that is what you want to enforce, but I'm not sure that is what you want or should do). NITS: Please fix nits as per genart review: https://datatracker.ietf.org/doc/review-ietf-tls-subcerts-12-genart-lc-davies-2022-04-08/ Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-subcerts-13.txt
All of the changes are simple and straight forward. I did spot one typo: Section 4.2: s/This documnt defines/This document defines/ Russ > On May 9, 2022, at 8:37 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > >Title : Delegated Credentials for (D)TLS >Authors : Richard Barnes > Subodh Iyengar > Nick Sullivan > Eric Rescorla > Filename: draft-ietf-tls-subcerts-13.txt > Pages : 17 > Date: 2022-05-09 > > Abstract: > The organizational separation between operators of TLS and DTLS > endpoints and the certification authority can create limitations. > For example, the lifetime of certificates, how they may be used, and > the algorithms they support are ultimately determined by the > certification authority. This document describes a mechanism to to > overcome some of these limitations by enabling operators to delegate > their own credentials for use in TLS and DTLS without breaking > compatibility with peers that do not support this specification. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-13 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'Exported Authenticators in TLS' to Proposed Standard (draft-ietf-tls-exported-authenticator-15.txt)
The IESG has approved the following document: - 'Exported Authenticators in TLS' (draft-ietf-tls-exported-authenticator-15.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ Technical Summary This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. Working Group Summary As further background, Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternativ e to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes. The document author presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through three WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC. The 3rd WGLC addressed changes introduced as a result of a secdir review that returned the draft to the WG. EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets. The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates. [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03 [2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf [3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00 Document Quality EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet. See [2] for formal security reviews. Personnel Sean Turner is the document shepherd Roman Danyliw is the responsible AD. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
