Re: [TLS] [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact
From: OPSEC on behalf of Jen Linkova Sent: 28 July 2020 14:05 This email starts the WG Last Call for draft-ietf-opsec-ns-impact , Impact of TLS 1.3 to Operational Network Security Practices, https://datatracker.ietf.org/doc/draft-ietf-opsec-ns-impact/. Taking into account IETF108, the WGLC is extended to 3 weeks and ends on Aug 18th, 23:59:59 UTC. Please review the document and express your support or concerns/comments. OPPOSE (yes, I am shouting) This is nowhere near ready and putting it forward so soon is ... well ludicrous comes to mind. After WG adoption, comments were made to which there was no acknowledgement, no response, I was about to oppose the adoption of the other I-D from these authors on the grounds that until they respond to comments nothing else should happen because when they do there are more comments waiting to be aired. I am still of that view. I do see that a revised I-D has just appeared in among the thousand or so I-D that appear around the time of an IETF meeting, a timing that I sometimes think is designed to let it slip through unnoticed. Given all those other I-D - silly authors - it may be more than three weeks before I get my thoughts together. Tom Petch Thanks! -- SY, Jen Linkova aka Furry on behalf of the OpSec Chairs. ___ OPSEC mailing list op...@ietf.org https://www.ietf.org/mailman/listinfo/opsec ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp
From: OPSEC on behalf of Nancy Cam-Winget (ncamwing) Sent: 25 July 2020 04:04 OPPOSE There is a place for this I-D as and when the authors respond to the unanswered comments on the last I-D that they got adopted in OPSEC. If they do not acknowledge, let alone respond to, comments then that should be a bar to new work because as and when the comments are addressed there are more comments waiting. I do see a revised I-D of that other I-D in among the vast number that have appeared as they always do around the time of an IETF, but given that it is one among hundreds it will be a while before I am ready with more comments on that other I-D. Tom Petch This draft provides guidelines for TLS proxy implementations; given current activities using TLS with proxying I believe this document is useful for the community and implementors. I support its adoption. Warm regards, Nancy On 7/22/20, 6:31 PM, "OPSEC on behalf of Jen Linkova" wrote: One thing to add here: the chairs would like to hear active and explicit support of the adoption. So please speak up if you believe the draft is useful and the WG shall work on getting it published. On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica wrote: > > Folks, > > > > This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp. > > > > Please send comments to op...@ietf.org by August 3, 2020. > > > > Ron > > > > > Juniper Business Use Only > > ___ > OPSEC mailing list > op...@ietf.org > https://www.ietf.org/mailman/listinfo/opsec -- SY, Jen Linkova aka Furry ___ OPSEC mailing list op...@ietf.org https://www.ietf.org/mailman/listinfo/opsec ___ OPSEC mailing list op...@ietf.org https://www.ietf.org/mailman/listinfo/opsec ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact
From: Jen Linkova Sent: 28 July 2020 23:14 To: tom petch On Wed, Jul 29, 2020 at 2:07 AM tom petch wrote: >> This email starts the WG Last Call for draft-ietf-opsec-ns-impact , >> Impact of TLS 1.3 to Operational Network Security Practices, >> https://datatracker.ietf.org/doc/draft-ietf-opsec-ns-impact/. > > OPPOSE (yes, I am shouting) > > This is nowhere near ready and putting it forward so soon is ... well > ludicrous comes to mind. > > After WG adoption, comments were made to which there was no acknowledgement, > no response, I was about to oppose the adoption of the other I-D from these > authors on the grounds that until they respond to comments nothing else > should happen because when they do there are more comments waiting to be > aired. I am still of that view. Sorry, it's partially my fault. I did explicitly ask the authors to address your comments and submit a new version. I should have double-checked that the new version incorporates the feedback. Jen, it is more than that. I think that the IETF way of working is to make comments, get an acknowledgement and a response, from author, others, Chair, AD i.a., discuss the issues, accept or reject changes, new version, rinse and repeat. In this case, the next post after my comments was WGLC. This is not the process I expect. ( I thought there were other comments at adoption but cannot see them now). I did see Kathleen promising a further review; that would be helpful. And as I alluded to, four weeks ago was a quiet time, a time to progress this. Now, cut-off and post cut-off, it is that time of madness in the IETF when everyone comes out of hibernation and posts revised I-D. I track TEAS and they have just posted 484 - yes four hundred and eighty four - pages of revised I-Ds which will keep me quiet for much of August. Interesting as TLS is, it is behind them in the queue. Tom Petch Dear authors, would you be able to address Tom's comments ASAP so the new revision can be reviewed during the WGLC? > I do see that a revised I-D has just appeared in among the thousand or so I-D > that appear around the time of an IETF meeting, a timing that I sometimes > think is designed to let it slip through unnoticed. Given all those other > I-D - silly authors - it may be more than three weeks before I get my > thoughts together. Just to clarify: would you prefer not to have the WGLC around IETF weeks at all? -- SY, Jen Linkova aka Furry ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft minutes for TLS at IETF 108
From: TLS on behalf of Christopher Wood Sent: 04 August 2020 19:16 The official minutes are now up: https://datatracker.ietf.org/doc/minutes-108-tls/ What is Benjamin talking about at the end? It looks as if you are proposing action on all or some RFC that have TLS 1.0 or 1.1 as MTI, related to oldversions-deprecate but that is a guess from reading between the lines and that topic is a live one for me so I would appreciate clarity. Tom Petch Best, Chris, on behalf of the chairs On Tue, Jul 28, 2020, at 9:29 AM, Christopher Wood wrote: > Hi folks, > > Draft minutes for today's TLS meeting at IETF 108 are now available: > >https://github.com/tlswg/wg-materials/blob/master/ietf108/minutes.md > > Thanks to Carrick and others for taking notes! Please send any > corrections or updates to the list or as pull requests to the > repository. > > Thanks, > Chris, on behalf of the chairs > ___ 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
Re: [TLS] Draft minutes for TLS at IETF 108
From: Benjamin Kaduk Sent: 11 August 2020 18:06 On Wed, Aug 05, 2020 at 10:30:39AM +, tom petch wrote: > From: TLS on behalf of Christopher Wood > > Sent: 04 August 2020 19:16 > > The official minutes are now up: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_minutes-2D108-2Dtls_&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=bJwecPEDnXCm7Huw2ovjHwHyzCjhyu2kGMG-qijduH0&s=ksaUzUpfyd4LFplcfnjfXdGBN-jTrMiqS2Z1vk_Iftw&e= > > > What is Benjamin talking about at the end? > > It looks as if you are proposing action on all or some RFC that have TLS 1.0 > or 1.1 as MTI, related to oldversions-deprecate but that is a guess from > reading between the lines and that topic is a live one for me so I would > appreciate clarity. oldversions-deprecate is already taking action on all RFCs that have TLS 1.0 or 1.1 as MTI (there are some 80-odd documents in the Updates: header). The particular itesm I was mentioning in the meeting relate to various subsets of those documents that may need some additional handling on top of the basic "don't use TLS 1.0/1.1; use 1.2 and 1.3 instead" that is currently the content of the updates. Details are at https://mailarchive.ietf.org/arch/msg/tls/K9_uA6m0dD_oQCw-5kAbha-Kq5M/ So: - RFC 5469 defines DES and IDEA ciphers that are not in TLS 1.2; the document as a whole should be historic - The downgrade-detection SCSV of RFC 7507 is probably in a similar boat - We should be more clear about "if the document being updated says you MUST use TLS 1.0/1.1, that part is removed" Benjamin This is the bit I could not guess; the rest of the minutes I could guess but your explanation is much easier to understand. I have been tracking 'diediedie', including the AD review, since it first appeared and more a comment on that for Kathleen and Stephen is that RFC5953 does not get a mention although since it is Obsoleted and the Normative Reference is to RFC4347 then that is a category that does not seem to fit in any of the paragraphs of the I-D; Obsolete and TLS1.0 yes, Obsolete and DTLS1.0 no. RFC6353 I did expect to find; Internet Standard, STD0078, Normative Reference to RFC4347; the Security Considerations of that RFC say 'MUST NOT negotiate SSL 2.0' which might not be considered sufficiently strong for 2020 but how do you update a Standard? Tom Petch - No change proposed w.r.t. MTI ciphers (even though the old MTI ciphers are no longer considered very good) Were there additional specific items you were unsure about? -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fw: Draft minutes for TLS at IETF 108
Kathleen I have some thoughts below on RFC5953 and RFC6353 which I cannot find in deprecate but thought that I would. Tom Petch From: TLS on behalf of tom petch Sent: 13 August 2020 12:33 To: Benjamin Kaduk Cc: TLS Chairs; TLS@ietf.org Subject: Re: [TLS] Draft minutes for TLS at IETF 108 From: Benjamin Kaduk Sent: 11 August 2020 18:06 On Wed, Aug 05, 2020 at 10:30:39AM +, tom petch wrote: > From: TLS on behalf of Christopher Wood > > Sent: 04 August 2020 19:16 > > The official minutes are now up: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_minutes-2D108-2Dtls_&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=bJwecPEDnXCm7Huw2ovjHwHyzCjhyu2kGMG-qijduH0&s=ksaUzUpfyd4LFplcfnjfXdGBN-jTrMiqS2Z1vk_Iftw&e= > > > What is Benjamin talking about at the end? > > It looks as if you are proposing action on all or some RFC that have TLS 1.0 > or 1.1 as MTI, related to oldversions-deprecate but that is a guess from > reading between the lines and that topic is a live one for me so I would > appreciate clarity. oldversions-deprecate is already taking action on all RFCs that have TLS 1.0 or 1.1 as MTI (there are some 80-odd documents in the Updates: header). The particular itesm I was mentioning in the meeting relate to various subsets of those documents that may need some additional handling on top of the basic "don't use TLS 1.0/1.1; use 1.2 and 1.3 instead" that is currently the content of the updates. Details are at https://mailarchive.ietf.org/arch/msg/tls/K9_uA6m0dD_oQCw-5kAbha-Kq5M/ So: - RFC 5469 defines DES and IDEA ciphers that are not in TLS 1.2; the document as a whole should be historic - The downgrade-detection SCSV of RFC 7507 is probably in a similar boat - We should be more clear about "if the document being updated says you MUST use TLS 1.0/1.1, that part is removed" Benjamin This is the bit I could not guess; the rest of the minutes I could guess but your explanation is much easier to understand. I have been tracking 'diediedie', including the AD review, since it first appeared and more a comment on that for Kathleen and Stephen is that RFC5953 does not get a mention although since it is Obsoleted and the Normative Reference is to RFC4347 then that is a category that does not seem to fit in any of the paragraphs of the I-D; Obsolete and TLS1.0 yes, Obsolete and DTLS1.0 no. RFC6353 I did expect to find; Internet Standard, STD0078, Normative Reference to RFC4347; the Security Considerations of that RFC say 'MUST NOT negotiate SSL 2.0' which might not be considered sufficiently strong for 2020 but how do you update a Standard? Tom Petch - No change proposed w.r.t. MTI ciphers (even though the old MTI ciphers are no longer considered very good) Were there additional specific items you were unsure about? -Ben ___ 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
Re: [TLS] Last Call: (Deprecating MD5 and SHA-1 signature hashes in TLS 1.2) to Proposed Standard
I think that the first sentence could be improved. 'The MD5 and SHA-1 hashing algorithms are steadily weakening ...' sounds as if they are under attack from electrolytic corrosion or the death-watch beatle. I suggest NEW 'The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack and this document deprecates their use in TLS 1.2 digital signatures.' And /This draft/This document/ Tom Petch On 14/10/2020 19:40, The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Deprecating MD5 and SHA-1 signature hashes in TLS 1.2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-10-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The MD5 and SHA-1 hashing algorithms are steadily weakening in strength and their deprecation process should begin for their use in TLS 1.2 digital signatures. However, this document does not deprecate SHA-1 in HMAC for record protection. This document updates RFC 5246 and RFC 7525. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce . ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
I am confused about the treatment here of DTLS. The Abstract seems clear about the proposed action for TLS but then the second paragraph has " This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347)" Mmmm, really? There is a list of current RFC that Normatively reference the deprecated versions of DTLS and TLS; and then a list of obsolete RFC that Normatively reference TLS but for DTLS...? I look, for example, for RFC5953 which is obsolete and which Normatively references DTLS 1.0 but without success; nor can I find RFC6353 which is current and which Normatively references DTLS 1.0 (and which is part of a STD - not sure what that does to the Standard) And, in several places /supercede/supersede/ Tom Petch On 09/11/2020 22:26, The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Deprecating TLSv1.0 and TLSv1.1' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document, if approved, formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents (will be moved|have been moved) to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLSv1.2 has been the recommended version for IETF protocols since 2008, providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347), but not DTLS version 1.2, and there is no DTLS version 1.1. This document updates many RFCs that normatively refer to TLSv1.0 or TLSv1.1 as described herein. This document also updates the best practices for TLS usage in RFC 7525 and hence is part of BCP195. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5024: ODETTE File Transfer Protocol 2.0 (Informational - Independent Submission Editor stream) rfc5024: ODETTE File Transfer Protocol 2.0 (Informational - Independent Submission Editor stream) rfc5023: The Atom Publishing Protocol (Proposed Standard - IETF stream) rfc5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments (Proposed Standard - IETF stream) rfc5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments (Proposed Standard - IETF stream) rfc5018: Connection Establishment in the Binary Floor Control Protocol (BFCP) (Proposed Standard - IETF stream) rfc4992: XML Pipelining with Chunks for the Internet Registry Information Service (Proposed Standard - IETF stream) rfc4992: XML Pipelining with Chunks for the Internet Registry Information Service (Proposed Standard - IETF stream) rfc4976: Relay Extensions for the Message Sessions Relay Protocol (MSRP) (Proposed Standard - IETF stream) rfc4975: The Message Session Relay Protocol (MSRP) (Proposed Standard - IETF stream) rfc4975: The Message Session Relay Protocol (MSRP) (Proposed Standard - IETF stream) rfc4964: The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular (Informational - IETF stream) rfc4964: The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular (Informational - IETF stream) rfc4851: The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) (Informational - IETF stream) rfc4851: The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) (Informational - IETF stream) rfc4823: FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet (Informational - IETF stream) rfc4823: FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet (Informational - IETF stream) rfc4791: Calendaring Extensions to WebDAV (CalDAV) (Proposed Standard - IETF stream) rfc4791: Calendaring
Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On 10/11/2020 11:18, Stephen Farrell wrote: Hiya, On 10/11/2020 10:21, tom petch wrote: I am confused about the treatment here of DTLS. The Abstract seems clear about the proposed action for TLS but then the second paragraph has " This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347)" Mmmm, really? Sorry, I don't understand the comment. If you're just teeing up what's below that's fine, but I wasn't sure. Try looking at the I-D References and see what you find for RFC6347 and see if you want to deprecate it! There is a list of current RFC that Normatively reference the deprecated versions of DTLS and TLS; and then a list of obsolete RFC that Normatively reference TLS but for DTLS...? I look, for example, for RFC5953 which is obsolete and which Normatively references DTLS 1.0 but without success; nor can I find RFC6353 which is current and which Normatively references DTLS 1.0 (and which is part of a STD - not sure what that does to the Standard) Could be we missed some references for sure. An early version of those lists was produced from a script I wrote and those were edited as people commented - I always figured we'd make that better when getting comments at IETF LC. Is the gist of your comment then "add 6353 and 5953 to the relevant lists" (which'd be fine by me) or that we need to do something else/more? (In the latter case, I'm not sure what you're suggesting so clarifying that'd be good.) I was not looking for anything missing but, even so, came across these two without even looking so I am suspecting that the algorithm you used did not cater for DTLS 1.0, perhaps when it is in combination with TLS or some such, as it is in these two cases, and that there will be more out there that have been missed. Perhaps a second look at the algorithm to work out why these got missed to get a fix on how many more there may be. Tom Petch And, in several places /supercede/supersede/ One for the RFC editor I guess. But sure, will make 'em all the same:-) Thanks, S. Tom Petch On 09/11/2020 22:26, The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Deprecating TLSv1.0 and TLSv1.1' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On 04/12/2020 05:32, Rob Sayre wrote: Hi, What is the definition of “enterprise”? You could try the 16 RFC with 'enterprise' in their title such as RFC7381. Perhaps those who use as opposed to operators who provide, those whose business is funded by those who have little or no interest in what the IETF does, just in making or serving or selling or operating physical transport or ... anything but a network and getting paid for doing so; and who only take notice of security after the disaster has struck and now can see the cost of not having security by way of fines from state bodies, loss of customers who no longer have trust, ransom payments and such like. I speak from a little experience in this area, of being told that they wished they had listened to my advice but only after disaster had struck although here I am speaking more generally than just of security breaches. Tom Petch Thanks, Rob On Thu, Dec 3, 2020 at 7:48 PM Ackermann, Michael wrote: Deborah Thanks so much for your informative and positive message. I have not followed the OPs area too much, but will make an effort to do so now. Any specific drafts you might suggest, I will review. In particular, I am interested in what specific IPv6 document from the OPs area you refer too? I took a look at the ISOC IPv6 doc you listed. Interesting but it appears to be quite old. Do you feel it is still relevant?Enterprises need a lot of info on IPv6 and I want to point them in the most effective directions. By increasing visibility, do you mean ways to get Enterprises more involved or aware of IETF? I can sadly say none that have yet been effective, but I do intend to keep trying. Perhaps you have ideas? And finally, I checked out your Pragmatic Link. Still laughing, even though it unfortunately seems to have very little relevance to my world 😊 Once again I really appreciate your constructive comments and information. Mike -Original Message- From: BRUNGARD, DEBORAH A Sent: Thursday, December 3, 2020 5:10 PM To: STARK, BARBARA H ; 'Watson Ladd' < watsonbl...@gmail.com>; Ackermann, Michael Cc: 'Peter Gutmann' ; 'Eliot Lear' ; 'last-c...@ietf.org' ; ' tls-cha...@ietf.org' ; ' draft-ietf-tls-oldversions-deprec...@ietf.org' < draft-ietf-tls-oldversions-deprec...@ietf.org>; 'tls@ietf.org' < tls@ietf.org> Subject: RE: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice [External email] As Barbara builds her confidence for the IETF list and while we have Mike's attention- Mike, you commented "More, it is a lack of understanding of how things work within Enterprise Networks and the lack of Enterprise engagement in Standards Development processes. And finally, this may not be a gap that the IETF should care about or address, but someone should, IMHO." I wanted to +1 on to Barbara's message - many of us will say - "we do care". As IETF is "huge" (for many operators/users that is the biggest bottleneck on participating), not sure if you follow the ops area (I'm a routing AD, but ops always has my attention😊), they have several documents on enterprises. Currently a document on the impact of TLS1.3 on operational network security practices. They also have an IPv6 one. I think in all the Areas (I know best the routing area), we encourage operators and users to participate. If you have suggestions - we are interested. How to increase visibility? Do you have suggestions? Liaisons? ISOC? When RFC7381 (Enterprise IPv6) was done, it was an ISOC blog: https://www.internetsociety.org/blog/2014/10/new-rfc-7381-enterprise-ipv6-deployment-guidelines/ Possibly this draft should be a blog? Suggestions? Thanks again for the interesting thread- Deborah for some humor - I'm still stumbling on the draft's requirement "Pragmatically, clients MUST NOT send". I'm not sure operationally how to ensure pragmatic client behavior - maybe a "pragmatic client" profile😊 I'll save that question for my ballot comment. And of course a google of pragmatic is very entertaining: https://www.google.com/search?q=pragmatic&tbm=isch&source=iu&ictx=1&fir=UnkLahjDGGZYtM%252C2VmBAP_98FtW_M%252C%252Fm%252F0c6h9&vet=1&usg=AI4_-kQHPVOk9B-3gfzcXUP1bBCiuOQ5TQ&sa=X&ved=2ahUKEwjxqN-W1rLtAhXKhK0KHWuFBGYQ_B16BAgrEAE#imgrc=WzKrFQWEFvjiWM -Original Message- From: last-call On Behalf Of STARK, BARBARA H Sent: Thursday, December 3, 2020 12:03 PM To: 'Watson Ladd' ; 'Ackermann, Michael' < mackerm...@bcbsm.com> Cc: 'Peter Gutmann' ; 'Eliot Lear' < lear=40cisco@dmarc.ietf.org>; 'last-c...@ietf.org' ; 'tls-cha...@ietf.org' ;' draft-ietf-tls-oldversions-deprec...@ietf.o
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On 14/12/2020 14:53, Stephen Farrell wrote: Hi Tom, On 10/11/2020 11:33, Stephen Farrell wrote: On 10/11/2020 11:30, tom petch wrote: Perhaps a second look at the algorithm to work out why these got missed to get a fix on how many more there may be. Sure, that's reasonable. (Mightn't be today.) Just did that check by comparing [1] to the RFCs referenced in the draft and best I can see only 5953 and 6353 were missing in the end. I'd argue it's ok to add those without re-doing the IETF LC as they were mentioned in early on, in the LC, but of course that's the AD's call. I'm doing the edits for draft-10 now so it'll pop out shortly. Stephen Thank you for checking. With those two being SNMP and having both DTLS and TLS I was thinking of conspiracy theories but no:-) I should see the announcement of the updated I-D and will check it when I do. Like you, I do not see the need for a further LC just for the addition of those two RFC, Tom Petch Cheers, S. [1] https://datatracker.ietf.org/doc/rfc4347/referencedby/ Cheers, S. ___ 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
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On 14/12/2020 16:36, tom petch wrote: On 14/12/2020 14:53, Stephen Farrell wrote: Hi Tom, On 10/11/2020 11:33, Stephen Farrell wrote: On 10/11/2020 11:30, tom petch wrote: Perhaps a second look at the algorithm to work out why these got missed to get a fix on how many more there may be. Sure, that's reasonable. (Mightn't be today.) Just did that check by comparing [1] to the RFCs referenced in the draft and best I can see only 5953 and 6353 were missing in the end. I'd argue it's ok to add those without re-doing the IETF LC as they were mentioned in early on, in the LC, but of course that's the AD's call. I'm doing the edits for draft-10 now so it'll pop out shortly. Stephen, indeed, it had popped while I was replying to your e-mail. I see RFC5953, RFC6353 have been added. RFC5953 is obsoleted so should it be listed in 1.1 in the list of RFC already obsoleted, the one that start with RFC5101? Tom Petch Stephen Thank you for checking. With those two being SNMP and having both DTLS and TLS I was thinking of conspiracy theories but no:-) I should see the announcement of the updated I-D and will check it when I do. Like you, I do not see the need for a further LC just for the addition of those two RFC, Tom Petch Cheers, S. [1] https://datatracker.ietf.org/doc/rfc4347/referencedby/ Cheers, S. ___ 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
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On 15/12/2020 12:51, tom petch wrote: On 14/12/2020 16:36, tom petch wrote: On 14/12/2020 14:53, Stephen Farrell wrote: On 10/11/2020 11:33, Stephen Farrell wrote: On 10/11/2020 11:30, tom petch wrote: Perhaps a second look at the algorithm to work out why these got missed to get a fix on how many more there may be. Sure, that's reasonable. (Mightn't be today.) Just did that check by comparing [1] to the RFCs referenced in the draft and best I can see only 5953 and 6353 were missing in the end. I'd argue it's ok to add those without re-doing the IETF LC as they were mentioned in early on, in the LC, but of course that's the AD's call. I'm doing the edits for draft-10 now so it'll pop out shortly. Stephen, indeed, it had popped while I was replying to your e-mail. I see RFC5953, RFC6353 have been added. RFC5953 is obsoleted so should it be listed in 1.1 in the list of RFC already obsoleted, the one that start with RFC5101? Stephen, I have downloaded -11 (using FTP, of course:-) and it looks good to me, Tom Petch Tom Petch Stephen Thank you for checking. With those two being SNMP and having both DTLS and TLS I was thinking of conspiracy theories but no:-) I should see the announcement of the updated I-D and will check it when I do. Like you, I do not see the need for a further LC just for the addition of those two RFC, Tom Petch Cheers, S. [1] https://datatracker.ietf.org/doc/rfc4347/referencedby/ Cheers, S. ___ 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
Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard
Some editorial quirks s.2 lacks the boiler plate of RFC8174 s.3 I found this unclear until I had understood it all (or perhaps I do not understand it) "...or again, alternately, to use a zero-length CID)." This suggests that a zero length CID is valid in Application Data which later text seems to contradict; otherwise I cannot see what this is saying. " If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages " arguably sending a zero CID and receiving a zero CID is a successful Hello negotiation perhaps " If DTLS peers have negotiated the use of a non-zero CID in at least one direction, using the ClientHello and the ServerHello messages" "The DTLS peers determine whether incoming and outgoing messages need.." seems not to cater for unidirectional CIDs; perhaps "The DTLS peers determine whether incoming or outgoing, or both, messages need.. " s.4 /always recieve CIDs/always receive CIDs/ s.5.1 "the with Encrypt-then-MAC processing described in [RFC7366]." I do not understand why 'with' is needed s.5.2 ditto s.8 /this aspects SHOULD refuse/these aspects SHOULD refuse/ s.10 I would find this clearer as three sections for the three IANA actions 10.1 new column for ExtensionType 10.2 new value for ExtensionType 10.3 new value for ContentType " IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in [RFC5246],.." well no; whatever you think of RFC8447 the name has changed " IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, defined in [RFC5246],.." or, if you are picky (which I am not), IANA is requested to allocate an entry to the existing "TLS "ExtensionType Values" registry, defined in [RFC5246], and renamed by RFC8447 An extra column is added but I cannot see what value should be placed in that column for existing entries. "The tls12_cid ContentType is only applicable to DTLS 1.2." Good information but I struggle to see what IANA will do with it; I see nowhere for it to go. Tom Petch On 08/03/2021 11:19, The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Connection Identifiers for DTLS 1.2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-03-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce . ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard
On 12/03/2021 16:18, Achim Kraus wrote: Hi Tom, Hannes, Thomas, "A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID (or again, alternately, to use a zero-length CID)." My feeling is, the text in the paragraphs following that seems to introduce first the idea of a "zero-length CID", and later use that only to negate the use of tls_cid record. It may be more straight forward, if the use of a "zero-length CID" is limited to the ClientHello and the ServerHello extensions. And later the use of a tls_cid record is then only for negotiated non-empty CID. WDYT? I think that I cannot make sense of that 'alternately'. The subsequent paragraphs seem to rule it out as an option. On a first read I thought that a zero length CID was a valid option for Application Data and wanted to know which form of header and MAC was appropriate but my understanding of the later paragraphs became that a zero length CID can only appear in Hello; but I do think that this needs fixing. I did track the WG discussion last October and did not see anything very clear then. Tom Petch best regards Achim Kraus Am 12.03.21 um 12:58 schrieb Hannes Tschofenig: Hi Tom, I added a few PRs to address your review (see https://github.com/tlswg/dtls-conn-id/pulls). Regarding the zero-length CID I believe the current version in the repo at https://github.com/tlswg/dtls-conn-id might have already address your remark. In general, the zero-length CID in the ClientHello / ServerHello allows us to use CIDs unidirectionally. Ciao Hannes -Original Message- From: TLS On Behalf Of Thomas Fossati Sent: Friday, March 12, 2021 11:58 AM To: tom petch ; last-c...@ietf.org Cc: tls@ietf.org; tls-cha...@ietf.org; draft-ietf-tls-dtls-connection...@ietf.org Subject: Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard Hi Tom, Thanks very much! Your review is tracked in the issues below. On 12/03/2021, 10:39, "tom petch" wrote: Some editorial quirks s.2 lacks the boiler plate of RFC8174 https://github.com/tlswg/dtls-conn-id/issues/88 s.3 I found this unclear until I had understood it all (or perhaps I do not understand it) "...or again, alternately, to use a zero-length CID)." This suggests that a zero length CID is valid in Application Data which later text seems to contradict; otherwise I cannot see what this is saying. " If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages " arguably sending a zero CID and receiving a zero CID is a successful Hello negotiation perhaps " If DTLS peers have negotiated the use of a non-zero CID in at least one direction, using the ClientHello and the ServerHello messages" "The DTLS peers determine whether incoming and outgoing messages need.." seems not to cater for unidirectional CIDs; perhaps "The DTLS peers determine whether incoming or outgoing, or both, messages need.. " https://github.com/tlswg/dtls-conn-id/issues/89 s.4 /always recieve CIDs/always receive CIDs/ s.5.1 "the with Encrypt-then-MAC processing described in [RFC7366]." I do not understand why 'with' is needed s.5.2 ditto s.8 /this aspects SHOULD refuse/these aspects SHOULD refuse/ https://github.com/tlswg/dtls-conn-id/issues/90 s.10 I would find this clearer as three sections for the three IANA actions 10.1 new column for ExtensionType 10.2 new value for ExtensionType 10.3 new value for ContentType " IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in [RFC5246],.." well no; whatever you think of RFC8447 the name has changed " IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, defined in [RFC5246],.." or, if you are picky (which I am not), IANA is requested to allocate an entry to the existing "TLS "ExtensionType Values" registry, defined in [RFC5246], and renamed by RFC8447 An extra column is added but I cannot see what value should be placed in that column for existing entries. "The tls12_cid ContentType is only applicable to DTLS 1.2." Good information but I struggle to see what IANA will do with it; I see nowhere for it to go. https://github.com/tlswg/dtls-conn-id/issues/91 cheers, t Tom Petch On 08/03/2021 11:19, The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Connection Identifiers for DTLS 1.2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-03-28. Exceptionally, comments may be sent
Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard
On 12/03/2021 18:32, Thomas Fossati wrote: Hi Tom, all, On 12/03/2021, 17:29, "tom petch" wrote: On 12/03/2021 16:18, Achim Kraus wrote: Hi Tom, Hannes, Thomas, "A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID (or again, alternately, to use a zero-length CID)." My feeling is, the text in the paragraphs following that seems to introduce first the idea of a "zero-length CID", and later use that only to negate the use of tls_cid record. It may be more straight forward, if the use of a "zero-length CID" is limited to the ClientHello and the ServerHello extensions. And later the use of a tls_cid record is then only for negotiated non-empty CID. WDYT? I think that I cannot make sense of that 'alternately'. The subsequent paragraphs seem to rule it out as an option. On a first read I thought that a zero length CID was a valid option for Application Data and wanted to know which form of header and MAC was appropriate but my understanding of the later paragraphs became that a zero length CID can only appear in Hello; but I do think that this needs fixing. Is your suggestion to remove the parenthetical? I.e.: OLD A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID (or again, alternately, to use a zero-length CID). NEW A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID. Thomas Yes, that would fix this particular problem I have within this section. I word it that way since I did raise two other doubts about the wording in this section in my original post, one about successful negotiation, which seems to me an undefined term, and one about sending and receiving, which seems over-restrictive in the context. Tom Petch I did track the WG discussion last October and did not see anything very clear then. Tom Petch IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard
On 13/03/2021 18:03, Thomas Fossati wrote: hi Tom, On 13/03/2021, 11:54, "tom petch" wrote: Is your suggestion to remove the parenthetical? I.e.: OLD A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID (or again, alternately, to use a zero-length CID). NEW A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID. Thomas Yes, that would fix this particular problem I have within this section. I word it that way since I did raise two other doubts about the wording in this section in my original post, one about successful negotiation, which seems to me an undefined term, and one about sending and receiving, which seems over-restrictive in the context. At the top of the thread, you suggested to change: If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages into: If DTLS peers have negotiated the use of a non-zero CID in at least one direction, using the ClientHello and the ServerHello messages which is fine with me. However, I think it doesn't completely remove the ambiguity you are pointing at. So I'd suggest we also change the paragraph just above from: If DTLS peers have not negotiated the use of CIDs then the RFC 6347-defined record format and content type MUST be used. to: If DTLS peers have not negotiated the use of CIDs, which includes the case where both sent a zero-length cid in their connection_id extensions, then the RFC 6347-defined record format and content type MUST be used. Thomas Yes, I agree, that is needed as well. Tom Petch Regarding your suggestion: "The DTLS peers determine whether incoming and outgoing messages need.." seems not to cater for unidirectional CIDs; perhaps "The DTLS peers determine whether incoming or outgoing, or both, messages need.." It surely works for me. cheers, thanks! IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
