Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)
Okay that’s fine. It was just the wording of this one sentence that made me ask this question. > Am 13.12.2019 um 07:45 schrieb Benjamin Kaduk : > > On Wed, Dec 11, 2019 at 12:48:58PM -0500, Russ Housley wrote: >> Mirja: >> >>> -- >>> COMMENT: >>> -- >>> >>> Just a small thing to double-check: I wonder if this sentence would actually >>> require an update to RFC8446: >>> "TLS 1.3 does not permit the server to send a CertificateRequest >>> message when a PSK is being used. This restriction is removed when >>> the "tls_cert_with_extern_psk" extension is negotiated, allowing >>> certificate-based authentication for both the client and the server." >>> Or maybe it should be phrased differently, just: >>> "If the "tls_cert_with_extern_psk" extension is negotiated, >>> certificate-based >>> authentication is allowed for both the client and the server." I guess it >>> depends on what exactly is said in RFC8446 (and I didn't went and tried to >>> find >>> it). >> >> I do not believe that an update is needed or appropriate. First, the >> presence of this extension is an indication that this behavior will be >> different. Second, this is going to be an Experimental RFC, so it should >> not update a standards-track RFC. > > I agree; this is just an extension working as normal. (Not that I haven't > asked the same question before for other documents) > > -Ben > >>> And as a side note, it is usually recommended to provide the link to the >>> registry in the IANA section (to make life for IANA easier) >> >> I will gladly add a reference to the registry: >> >> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml >> >> Russ >> > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-tls-tls13-cert-with-extern-psk-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ -- COMMENT: -- Just a small thing to double-check: I wonder if this sentence would actually require an update to RFC8446: "TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed when the "tls_cert_with_extern_psk" extension is negotiated, allowing certificate-based authentication for both the client and the server." Or maybe it should be phrased differently, just: "If the "tls_cert_with_extern_psk" extension is negotiated, certificate-based authentication is allowed for both the client and the server." I guess it depends on what exactly is said in RFC8446 (and I didn't went and tried to find it). And as a side note, it is usually recommended to provide the link to the registry in the IANA section (to make life for IANA easier). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-tls-sni-encryption-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ -- COMMENT: -- Thanks for clearly writing down attacks and requirements in this document. One small technical comment on this sentence: Sec 2.3: "Per-stream QoS can be provided by a combination of packet marking and end-to-end agreements." If this sentence is meant to mean use of DSCP, I don't think this is true, as DSCP is usually not available end-to-end but most often gets changed or bleached somewhere on the path. And two editorial comments: Sec 2.1: "The SNI was defined to facilitate management of servers, though the developers of middleboxes soon found out that they could take advantage of the information." "soon found out" does sound a bit story-telling like to me. I recommend a more objective phrasing like: "The SNI was defined to facilitate management of servers, though other usages by middleboxes also take advantage of the information." or something similar... Also sec 2.1: "The SNI is probably also included in the general collection of metadata by pervasive surveillance actors." This sentence is phrased a bit speculatively and at the same kind seems inherently true as a "pervasive surveillance actor" usually just collect all available data/traffic... I guess the more interesting question would be if and how this information is used. Anyway I recommend some rephrasing like: "The SNI could also be utilised by the general collection of metadata by pervasive surveillance actors." ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-grease-03: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-tls-grease-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ -- COMMENT: -- Sorry one more comment/question I forgot earlier: Why is this document informational? Shouldn't it be at least experimental? -- previous comment -- One comment/question: I think I didn't quite understand what a client is supposed to do if the connection fails with use of greasing values...? The security considerations seems to indicate that you should not try to re-connect without use of grease but rather just fail completely...? Also should you cache the information that greasing failed maybe? And a note on normative language: "Implementations sending multiple GREASE extensions in a single block thus must ensure the same value is not selected twice." Should this be a "MUST"? Also this is an interesting MUST: "... MUST correctly ignore unknown values..." While this is the whole point of the document, I assume this is already normatively specified in RFC8446 and therefore it could make sense to use non-formative language here... ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-grease-03: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-tls-grease-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ -- COMMENT: -- One comment/question: I think I didn't quite understand what a client is supposed to do if the connection fails with use of greasing values...? The security considerations seems to indicate that you should not try to re-connect without use of grease but rather just fail completely...? Also should you cache the information that greasing failed maybe? And a note on normative language: "Implementations sending multiple GREASE extensions in a single block thus must ensure the same value is not selected twice." Should this be a "MUST"? Also this is an interesting MUST: "... MUST correctly ignore unknown values..." While this is the whole point of the document, I assume this is already normatively specified in RFC8446 and therefore it could make sense to use non-formative language here... ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] maprg session on Tue Nov 6, 1610-1810
Hi security folks! I just wanted to point you at our next maprg session in Bangkok as we have a couple of security relevant presentations on the agenda, e.g. The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem (by Matthias Wählisch) Is the Web Ready for OCSP Must Staple? (Nick Sullivan) Both of these talks are at the end of the session, so maybe if secdispatch finishes early, you maybe able to make it! The maprg session is Tuesday, 6 November 2018, Afternoon Session II 1610-1810 Room Name: Chitlada 1 See you there! Mirja (chair) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-tls-tls13-vectors-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ -- COMMENT: -- Why is it really necessary to publish the test vectors in an RFC? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-tls-record-limit-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ -- COMMENT: -- Thanks for the well written doc! One minor comment the title of sec 5: not sure if "deprecating" is the best word as that maybe be read as "moved to historic" in IETF world... Tiny typo in sec 5: s/and "max_fragment_length"/an "max_fragment_length"/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-tls-iana-registry-updates-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ -- COMMENT: -- 1) Section 18: "However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published." This sounds like it's simply the early allocation process (rfc7120). Maybe it's useful to name it like this to avoid confusion. 2) Also section 18: "IANA [...] SHOULD direct all requests for registration to the review mailing list." Why is this not a MUST? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-tls-tls13-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ -- COMMENT: -- 1) I'm a bit uncertain if obsoleting is the right approach as many other protocols usually do not obsolete older versions. However, I understand that this has been the approach TLS has previously taken and is supported by the way the document is written. Still, I find it especially confusing that also two TLS1.2 extensions are deprecated which are not needed with TLS1.3 anymore but still probably valid to be used with TLS1.2, right? I would recommend for this version to at least already note in the abstract or very early in the intro that it changes the versioning mechanism itself, and thereby basically declares the TLS handshake as an invariant for all future versions and extensibility is only provided using extensions anymore. 2) Can you provide further explanation (potentially in the draft) why the Pre-Shared Key Exchange Modes are provided in an extra/separate extension? 3) I know previous versions of TLS didn't say that much either, but I find it a bit wired that there are NO requirements for the underlaying transport in this document. Previous version this at least said in the intro that a reliable transport (like TCP) is assumed, but even this minimal information seems to have gotten lost in this document. However, I would usually also expect to seen some minimal text about connection handling, e.g. is it okay to transparently try to reestablish the connection by the underlying transport protocol if it broke for some reason? Or it is okay to use the same TCP connection to first send other data and then start the TLS handshake? 4) Regarding the registration policies: I assume the intend of changing them is to make it easier to specify and use new extensions/mechanism. However, I am wondering why the policies have been changed to "Specification Required" and not "IETF consensus" or RFC Required"? 5) I find it a bit strange that basically the whole working group is listed as contributors. My understanding was that Contributors are people that have contributed a "significant" amount of text, while everybody else who e.g. brought ideas in during mailing list discussion would be acknowledged only. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-tls-dnssec-chain-extension-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ -- COMMENT: -- Two minor, mostly editorial comments: 1) Intro (sec 2): " It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records because of an interfering or broken middlebox on the path between the client and a DNS server." Is that actually a well-known problem (can you provide a reference?) or would it be enough to say something like this: " It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records when DNS server is not reachable." 2) IANA Considerations should probably be updated. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
