Re: [TLS] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS
Hi John, There are several orders associated with the settlement agreement - which is relevant here. You need a PACER account to access the docket. It was a complicated case that stretched over several years and cost ETSI a considerable amount of money - and involved several companies. Trueposition in its complaint alleged that the 3GPP SA standards were being manipulated through a conspiracy among the named parties to exclude Trueposition from the marketplace. The other parties must have incurred similar or greater expenses. The case reshaped the antitrust environment for standards setting bodies. See http://sullivanlaw.net/standard-setting-org-may-be-liable-for-antitrust-violations-of-member-leaders/. When the IETF role shifted from government/academic to public markets in the early 90s, the antitrust exposure increased significantly and the Internet Society purchased insurance to cover those in the IETF decision making process. Presumably, that still exists. Circa 2012, the IETF briefly visited the subject of antitrust culpability with a group that exchanged some email and hosted a BOF and then went quiet. See https://datatracker.ietf.org/wg/antitrust/about/ The Trueposition v. Ericsson case occurred after that point and was ground breaking. Antitrust law in this arena continues to evolve. Even individuals can be held accountable. Over the past year, the competition enforcement bodies on both sides of the Atlantic have made it clear they are concerned about anti-competitive actions in the internet sector and have established investigatory task forces. TLS is particular has a history going back to 1986 when the platform was first announced by the USG and the TLS specification was instantiated initially in the GOSIP standards and then in ITU/ISO standards. The are many TLS variants and platforms that produce revenue in the marketplace and bring competition to the industry. It seems best to avoid increased antitrust exposure by potentially restraining TLS competition via standards body activities and suggesting that certain platforms are "mandates." --tony On 2020-03-07 9:23 PM, John Levine wrote: In article you write: -=-=-=-=-=- One comment. Perhaps some caution might be advised in light of the antitrust court order in /Trueposition v. Ericsson/. Ref. Order in Case No. 2:11-cv-4574, (U.S. E.D. Pa, 14 Jul 2014). That's a single page dismissing 3GPP from the case. Really? https://ia800306.us.archive.org/15/items/gov.uscourts.paed.426719/gov.uscourts.paed.426719.296.0.pdf R's, John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS
On 08/03/2020 14:46, Tony Rutkowski wrote: > > TLS is particular has a history going back to 1986 when the platform was > first announced by the USG and the TLS specification was instantiated > initially in the GOSIP standards and then in ITU/ISO standards. That's false. I've seen it repeated a few times but it remains false. Mostly, this falsehood seems to be repeated in tandem with efforts one could interpret as attempts to create FUD about Internet related security. TLS started in the IETF as a compromise between Netscape and Microsoft proposals for how to secure HTTP. X.509 started as part of X.400, then X.500 and is used by TLS. Today, I would bet almost all implementers never need to look beyond RFC5280 for X.509. And I hope it stays that way until we somehow figure out how to retire X.509. S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] three ECHO issues
Hiya, Thanks for the new ECHO PR. [1] I think this is the right direction but I have three issues with how it's done in the PR right now that I think would benefit from list discussion before a new I-D is produced or the PR is merged. 1) Padding. This should be easy but somehow seems to be hard;-( ISTM the current text is broken as it'd expose length information about ALPN in the CH and also in the EncryptedExtensions. I think it'd be good if the list reached some level of agreement on the goals of padding here rather than keep making different tweaks that don't work. I think the goal for padding ought be that we don't expose information about the content of the inner CH via the length of any h/s message. If we agree that (or some similar thing) then hopefully it should be just a matter of tweaking the algorithm so it works. (I've raised this before but seemingly not convincingly enough;-) 2) Variance between inner and outer CH. The current scheme is that almost any variation is allowed. In the work I've done so far looking at how to code that up, the trial decryption required becomes a major pain in the client code as soon as the TLS key-share differs between inner and outer. I don't know if that affects other code bases or if that's mostly an OpenSSL thing but think we ought establish on the list if that level of flexibility is needed now, or maybe later, or even never. The cost there is not just working out how to code it up, but this also creates new complex code paths that will be rarely executed which is usually a recipe for sadness later. So, I'd hope other code bases are checked for this before we merge the PR. (The problem here could be OpenSSL's internal, eh... "intricacy" is a polite term I guess, or it could be me being dim, but it seems real;-) 3) I think we might be better off leaving out the compression stuff for now, and only figuring that out later. The current OuterExtensions thing is pretty ugly, and if the result of (2) above were that we constrain the variance between inner and outer some more then a generic compression scheme may not be needed. I do think we will want some compression thing in the RFC we end up with, but we might be better off to get interop without that first and then add compression later. (That's what I plan to do fwiw, so this is a less pressing issue for me given I'll be ignoring it for now:-) Cheers, S. [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/207/files 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] three ECHO issues
Thanks for raising these issues! Please see inline below. On 8 Mar 2020, at 8:18, Stephen Farrell wrote: Hiya, Thanks for the new ECHO PR. [1] I think this is the right direction but I have three issues with how it's done in the PR right now that I think would benefit from list discussion before a new I-D is produced or the PR is merged. 1) Padding. This should be easy but somehow seems to be hard;-( ISTM the current text is broken as it'd expose length information about ALPN in the CH and also in the EncryptedExtensions. I think it'd be good if the list reached some level of agreement on the goals of padding here rather than keep making different tweaks that don't work. I think the goal for padding ought be that we don't expose information about the content of the inner CH via the length of any h/s message. If we agree that (or some similar thing) then hopefully it should be just a matter of tweaking the algorithm so it works. (I've raised this before but seemingly not convincingly enough;-) We kept maximum_name_length so as to not change “too much” in the PR. As this is orthogonal to the overall change, it can be addressed separately. Can you please file an issue and propose text? 2) Variance between inner and outer CH. The current scheme is that almost any variation is allowed. In the work I've done so far looking at how to code that up, the trial decryption required becomes a major pain in the client code as soon as the TLS key-share differs between inner and outer. I don't know if that affects other code bases or if that's mostly an OpenSSL thing but think we ought establish on the list if that level of flexibility is needed now, or maybe later, or even never. The cost there is not just working out how to code it up, but this also creates new complex code paths that will be rarely executed which is usually a recipe for sadness later. So, I'd hope other code bases are checked for this before we merge the PR. (The problem here could be OpenSSL's internal, eh... "intricacy" is a polite term I guess, or it could be me being dim, but it seems real;-) Yes, this will be a pain to implement. But variance between the inner and outer CH is permitted, and indeed a goal. 3) I think we might be better off leaving out the compression stuff for now, and only figuring that out later. The current OuterExtensions thing is pretty ugly, and if the result of (2) above were that we constrain the variance between inner and outer some more then a generic compression scheme may not be needed. I do think we will want some compression thing in the RFC we end up with, but we might be better off to get interop without that first and then add compression later. (That's what I plan to do fwiw, so this is a less pressing issue for me given I'll be ignoring it for now:-) Can you elaborate on why it’s ugly? What could we do differently? Text suggestions are welcome! Thanks, Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS
In article <9af29b8f-856e-eb3f-6f12-e4cb0a866...@cs.tcd.ie> you write: >On 08/03/2020 14:46, Tony Rutkowski wrote: >> >> TLS is particular has a history going back to 1986 when the platform was >> first announced by the USG and the TLS specification was instantiated >> initially in the GOSIP standards and then in ITU/ISO standards. > >That's false. I've seen it repeated a few times but it >remains false. Mostly, this falsehood seems to be repeated >in tandem with efforts one could interpret as attempts >to create FUD about Internet related security. ... If anyone wants to confirm that this is FUD, you can find the case documents here: https://www.courtlistener.com/docket/4369665/trueposition-inc-v-lm-ericsson-telephone-company/ R's, John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS
Stephen, It is not false. It is simply largely unknown because of subsequent IETF related narratives that choose to omit the history. The documents are available online - although portions remain classified. A request is pending for their declassification and release. You can find some of the details in the links in this article. http://www.circleid.com/posts/20190124_creating_tls_the_pioneering_role_of_ruth_nelson/ Ruth Nelson - who led some of the important components - appeared at last October's NSA Crypto History Symposium. She filled in some of the details and the work was recognized by those there. Whit was also there also there and gave a great presentation. Unfortunately, women in this field seem not to get the credit they deserve. --tony On 2020-03-08 10:56 AM, Stephen Farrell wrote: On 08/03/2020 14:46, Tony Rutkowski wrote: TLS is particular has a history going back to 1986 when the platform was first announced by the USG and the TLS specification was instantiated initially in the GOSIP standards and then in ITU/ISO standards. That's false. I've seen it repeated a few times but it remains false. Mostly, this falsehood seems to be repeated in tandem with efforts one could interpret as attempts to create FUD about Internet related security. TLS started in the IETF as a compromise between Netscape and Microsoft proposals for how to secure HTTP. X.509 started as part of X.400, then X.500 and is used by TLS. Today, I would bet almost all implementers never need to look beyond RFC5280 for X.509. And I hope it stays that way until we somehow figure out how to retire X.509. 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] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS
On 08/03/2020 16:35, Tony Rutkowski wrote: > Stephen, > > It is not false. We disagree. SDNS != TLS. TLS was SSL with the middle S standing for socket, which wasn't part of SDNS or GOSIP that I recall. > It is simply largely unknown because of subsequent > IETF related narratives that choose to omit the history. The documents > are available online - although portions remain classified. Hah, that's funny. And with the classified documents defense of the falsehood, I'm done debunking this. S. > A request > is pending for their declassification and release. You can find some of > the details in the links in this article. > http://www.circleid.com/posts/20190124_creating_tls_the_pioneering_role_of_ruth_nelson/ > > > Ruth Nelson - who led some of the important components - appeared at > last October's NSA Crypto History Symposium. She filled in some of the > details and the work was recognized by those there. Whit was also there > also there and gave a great presentation. Unfortunately, women in this > field seem not to get the credit they deserve. > > --tony > > > On 2020-03-08 10:56 AM, Stephen Farrell wrote: >> >> On 08/03/2020 14:46, Tony Rutkowski wrote: >>> TLS is particular has a history going back to 1986 when the platform was >>> first announced by the USG and the TLS specification was instantiated >>> initially in the GOSIP standards and then in ITU/ISO standards. >> That's false. I've seen it repeated a few times but it >> remains false. Mostly, this falsehood seems to be repeated >> in tandem with efforts one could interpret as attempts >> to create FUD about Internet related security. >> >> TLS started in the IETF as a compromise between Netscape >> and Microsoft proposals for how to secure HTTP. >> >> X.509 started as part of X.400, then X.500 and is used by >> TLS. Today, I would bet almost all implementers never need >> to look beyond RFC5280 for X.509. And I hope it stays that >> way until we somehow figure out how to retire X.509. >> >> S. >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] three ECHO issues
Hiya, On 08/03/2020 16:07, Christopher Wood wrote: > Thanks for raising these issues! Please see inline below. > > On 8 Mar 2020, at 8:18, Stephen Farrell wrote: > >> Hiya, >> >> Thanks for the new ECHO PR. [1] I think this is the right direction >> but I have three issues with how it's done in the PR right now that >> I think would benefit from list discussion before a new I-D is >> produced or the PR is merged. >> >> 1) Padding. This should be easy but somehow seems to be hard;-( >> ISTM the current text is broken as it'd expose length information >> about ALPN in the CH and also in the EncryptedExtensions. I think >> it'd be good if the list reached some level of agreement on the >> goals of padding here rather than keep making different tweaks that >> don't work. I think the goal for padding ought be that we don't >> expose information about the content of the inner CH via the length >> of any h/s message. If we agree that (or some similar thing) then >> hopefully it should be just a matter of tweaking the algorithm so >> it works. (I've raised this before but seemingly not convincingly >> enough;-) > > We kept maximum_name_length so as to not change “too much” in the PR. > As this is orthogonal to the overall change, it can be addressed > separately. Can you please file an issue and propose text? Sure. But ECHO vs. ESNI does make a difference here e.g. due to the ALPN in the inner. If the outcome of (2) below is to keep the flexibility they may be other extensions that create length issues, either just in the inner CH or else there and possibly also in other bits of the h/s. That said, if the goal I stated above is something on which everyone's agreed, I'd be happy to craft a PR. But if that goal is not agreed, then probably any PR I make won't be useful, hence raising this on the list. >> 2) Variance between inner and outer CH. The current scheme is that >> almost any variation is allowed. In the work I've done so far >> looking at how to code that up, the trial decryption required >> becomes a major pain in the client code as soon as the TLS >> key-share differs between inner and outer. I don't know if that >> affects other code bases or if that's mostly an OpenSSL thing but >> think we ought establish on the list if that level of flexibility >> is needed now, or maybe later, or even never. The cost there is not >> just working out how to code it up, but this also creates new >> complex code paths that will be rarely executed which is usually a >> recipe for sadness later. So, I'd hope other code bases are checked >> for this before we merge the PR. (The problem here could be >> OpenSSL's internal, eh... "intricacy" is a polite term I guess, or >> it could be me being dim, but it seems real;-) > > Yes, this will be a pain to implement. But variance between the > inner and outer CH is permitted, and indeed a goal. I'm questioning whether that's a good goal or not. In my analysis of the various extensions, only SNI and ALPN seem to offer immediate value. Until one gets to new algos, which may mean PQC, there doesn't seem much more that's worth supporting really. And when one looks at the level of complexity to implement generic variance, I'm really not sure it's worthwhile. That said, I'd hack away at it as needed if others have taken a look at their code and found it ok to support. I've just not heard that so far and am concerned we're trading v, simple text in the I-D vs. really horribly complex and maybe flakey code, which doesn't seem like a good plan to me. Just to be clear: I do like the idea that the analysis be done on the flexible/full-variance scheme and I also like the idea of reconstructing a full CH from the recovered plaintext of the inner CH. Even with all that though, the ECHO spec can still impose interop restrictions on inner/outer CH variance to simplify implementation and make interop easier and more likely. My guess is that that'd be a worthwhile simplification. If more variation is needed later (e.g. to help incremental deployment of PQC algs), then that could just use a new extension instead of ECHO. > >> 3) I think we might be better off leaving out the compression stuff >> for now, and only figuring that out later. The current >> OuterExtensions thing is pretty ugly, and if the result of (2) >> above were that we constrain the variance between inner and outer >> some more then a generic compression scheme may not be needed. I >> do think we will want some compression thing in the RFC we end up >> with, but we might be better off to get interop without that first >> and then add compression later. (That's what I plan to do fwiw, so >> this is a less pressing issue for me given I'll be ignoring it for >> now:-) > > Can you elaborate on why it’s ugly? Allowing more than 1 OuterExtensions - that'd break some code in OpenSSL's generic extension handling. Not sure how bad that'll be to handle. > What could we do differently? If e.g. we required the same TLS ke
Re: [TLS] three ECHO issues
On 8 Mar 2020, at 10:14, Stephen Farrell wrote: Hiya, On 08/03/2020 16:07, Christopher Wood wrote: Thanks for raising these issues! Please see inline below. On 8 Mar 2020, at 8:18, Stephen Farrell wrote: Hiya, Thanks for the new ECHO PR. [1] I think this is the right direction but I have three issues with how it's done in the PR right now that I think would benefit from list discussion before a new I-D is produced or the PR is merged. 1) Padding. This should be easy but somehow seems to be hard;-( ISTM the current text is broken as it'd expose length information about ALPN in the CH and also in the EncryptedExtensions. I think it'd be good if the list reached some level of agreement on the goals of padding here rather than keep making different tweaks that don't work. I think the goal for padding ought be that we don't expose information about the content of the inner CH via the length of any h/s message. If we agree that (or some similar thing) then hopefully it should be just a matter of tweaking the algorithm so it works. (I've raised this before but seemingly not convincingly enough;-) We kept maximum_name_length so as to not change “too much” in the PR. As this is orthogonal to the overall change, it can be addressed separately. Can you please file an issue and propose text? Sure. But ECHO vs. ESNI does make a difference here e.g. due to the ALPN in the inner. If the outcome of (2) below is to keep the flexibility they may be other extensions that create length issues, either just in the inner CH or else there and possibly also in other bits of the h/s. That said, if the goal I stated above is something on which everyone's agreed, I'd be happy to craft a PR. But if that goal is not agreed, then probably any PR I make won't be useful, hence raising this on the list. In general I think it’s a fine goal, but I think it’s probably a bit more challenging to specify this correctly than we might think. Take ALPN as an example. Servers can’t possibly know what ALPN tokens each client might offer up in their CH, so how can they express a maximum limit? 2) Variance between inner and outer CH. The current scheme is that almost any variation is allowed. In the work I've done so far looking at how to code that up, the trial decryption required becomes a major pain in the client code as soon as the TLS key-share differs between inner and outer. I don't know if that affects other code bases or if that's mostly an OpenSSL thing but think we ought establish on the list if that level of flexibility is needed now, or maybe later, or even never. The cost there is not just working out how to code it up, but this also creates new complex code paths that will be rarely executed which is usually a recipe for sadness later. So, I'd hope other code bases are checked for this before we merge the PR. (The problem here could be OpenSSL's internal, eh... "intricacy" is a polite term I guess, or it could be me being dim, but it seems real;-) Yes, this will be a pain to implement. But variance between the inner and outer CH is permitted, and indeed a goal. I'm questioning whether that's a good goal or not. In my analysis of the various extensions, only SNI and ALPN seem to offer immediate value. Until one gets to new algos, which may mean PQC, there doesn't seem much more that's worth supporting really. And when one looks at the level of complexity to implement generic variance, I'm really not sure it's worthwhile. That said, I'd hack away at it as needed if others have taken a look at their code and found it ok to support. I've just not heard that so far and am concerned we're trading v, simple text in the I-D vs. really horribly complex and maybe flakey code, which doesn't seem like a good plan to me. Just to be clear: I do like the idea that the analysis be done on the flexible/full-variance scheme and I also like the idea of reconstructing a full CH from the recovered plaintext of the inner CH. Even with all that though, the ECHO spec can still impose interop restrictions on inner/outer CH variance to simplify implementation and make interop easier and more likely. My guess is that that'd be a worthwhile simplification. Yep, it can, and that’s something we can tighten down as needed later on. For example, if we later decide that we never want to duplicate key shares, we can just make that so. For now, starting general aligns with the analysis and gives us the flexibility we need to further refine as needed. If more variation is needed later (e.g. to help incremental deployment of PQC algs), then that could just use a new extension instead of ECHO. 3) I think we might be better off leaving out the compression stuff for now, and only figuring that out later. The current OuterExtensions thing is pretty ugly, and if the result of (2) above were that we constrain the variance between inner and outer some more then a generic compression scheme may not be needed. I do think we will want
Re: [TLS] three ECHO issues
Moar below... :-) On 08/03/2020 17:25, Christopher Wood wrote: > > > On 8 Mar 2020, at 10:14, Stephen Farrell wrote: > >> Hiya, >> >> On 08/03/2020 16:07, Christopher Wood wrote: >>> Thanks for raising these issues! Please see inline below. >>> >>> On 8 Mar 2020, at 8:18, Stephen Farrell wrote: >>> Hiya, Thanks for the new ECHO PR. [1] I think this is the right direction but I have three issues with how it's done in the PR right now that I think would benefit from list discussion before a new I-D is produced or the PR is merged. 1) Padding. This should be easy but somehow seems to be hard;-( ISTM the current text is broken as it'd expose length information about ALPN in the CH and also in the EncryptedExtensions. I think it'd be good if the list reached some level of agreement on the goals of padding here rather than keep making different tweaks that don't work. I think the goal for padding ought be that we don't expose information about the content of the inner CH via the length of any h/s message. If we agree that (or some similar thing) then hopefully it should be just a matter of tweaking the algorithm so it works. (I've raised this before but seemingly not convincingly enough;-) >>> >>> We kept maximum_name_length so as to not change “too much” in the >>> PR. As this is orthogonal to the overall change, it can be >>> addressed separately. Can you please file an issue and propose >>> text? >> >> Sure. But ECHO vs. ESNI does make a difference here e.g. due to the >> ALPN in the inner. If the outcome of (2) below is to keep the >> flexibility they may be other extensions that create length issues, >> either just in the inner CH or else there and possibly also in >> other bits of the h/s. >> >> That said, if the goal I stated above is something on which >> everyone's agreed, I'd be happy to craft a PR. But if that goal is >> not agreed, then probably any PR I make won't be useful, hence >> raising this on the list. > > In general I think it’s a fine goal, but I think it’s probably a bit > more challenging to specify this correctly than we might think. Take > ALPN as an example. Servers can’t possibly know what ALPN tokens > each client might offer up in their CH, so how can they express a > maximum limit? IMO there's no need. If a server wants to opine, then it could publish a min-length-inner-CH-plaintext value, to match the longest total of SNI+ALPN it knows about, but it no longer makes sense for a server to opine on the length of parts of the plaintext inner CH, only on the overall plaintext length, if even that. The client, being the one who knows what's in the inner CH plaintext and how those fields might vary in length, is really the only one who can figure out the padding. > >> 2) Variance between inner and outer CH. The current scheme is that almost any variation is allowed. In the work I've done so far looking at how to code that up, the trial decryption required becomes a major pain in the client code as soon as the TLS key-share differs between inner and outer. I don't know if that affects other code bases or if that's mostly an OpenSSL thing but think we ought establish on the list if that level of flexibility is needed now, or maybe later, or even never. The cost there is not just working out how to code it up, but this also creates new complex code paths that will be rarely executed which is usually a recipe for sadness later. So, I'd hope other code bases are checked for this before we merge the PR. (The problem here could be OpenSSL's internal, eh... "intricacy" is a polite term I guess, or it could be me being dim, but it seems real;-) >>> >>> Yes, this will be a pain to implement. But variance between the >>> inner and outer CH is permitted, and indeed a goal. >> >> I'm questioning whether that's a good goal or not. In my analysis >> of the various extensions, only SNI and ALPN seem to offer >> immediate value. Until one gets to new algos, which may mean PQC, >> there doesn't seem much more that's worth supporting really. And >> when one looks at the level of complexity to implement generic >> variance, I'm really not sure it's worthwhile. That said, I'd hack >> away at it as needed if others have taken a look at their code and >> found it ok to support. I've just not heard that so far and am >> concerned we're trading v, simple text in the I-D vs. really >> horribly complex and maybe flakey code, which doesn't seem like a >> good plan to me. >> >> Just to be clear: I do like the idea that the analysis be done on >> the flexible/full-variance scheme and I also like the idea of >> reconstructing a full CH from the recovered plaintext of the inner >> CH. Even with all that though, the ECHO spec can still impose >> interop restrictions on inner/outer CH variance to simplify >> implementation and m
Re: [TLS] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS
Hi Stephen, Amusing attempt to rewrite history. Your disagreement means nothing, fortunately, and folks can claim FUD all they want. The reality is that the actions in this group are facing increasing exposure to antitrust, tort, consumer protection, and tax-related actions. If you don't want to be cautious, then lawyer up...or at least get ISOC to buy you more insurance. :-) Oh, is it clear who is covered by the insurance? cheers, tony On 2020-03-08 12:59 PM, Stephen Farrell wrote: On 08/03/2020 16:35, Tony Rutkowski wrote: Stephen, It is not false. We disagree. SDNS != TLS. TLS was SSL with the middle S standing for socket, which wasn't part of SDNS or GOSIP that I recall. It is simply largely unknown because of subsequent IETF related narratives that choose to omit the history. The documents are available online - although portions remain classified. Hah, that's funny. And with the classified documents defense of the falsehood, I'm done debunking this. S. A request is pending for their declassification and release. You can find some of the details in the links in this article. http://www.circleid.com/posts/20190124_creating_tls_the_pioneering_role_of_ruth_nelson/ Ruth Nelson - who led some of the important components - appeared at last October's NSA Crypto History Symposium. She filled in some of the details and the work was recognized by those there. Whit was also there also there and gave a great presentation. Unfortunately, women in this field seem not to get the credit they deserve. --tony On 2020-03-08 10:56 AM, Stephen Farrell wrote: On 08/03/2020 14:46, Tony Rutkowski wrote: TLS is particular has a history going back to 1986 when the platform was first announced by the USG and the TLS specification was instantiated initially in the GOSIP standards and then in ITU/ISO standards. That's false. I've seen it repeated a few times but it remains false. Mostly, this falsehood seems to be repeated in tandem with efforts one could interpret as attempts to create FUD about Internet related security. TLS started in the IETF as a compromise between Netscape and Microsoft proposals for how to secure HTTP. X.509 started as part of X.400, then X.500 and is used by TLS. Today, I would bet almost all implementers never need to look beyond RFC5280 for X.509. And I hope it stays that way until we somehow figure out how to retire X.509. 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] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS
Hi Folks. This isn't a topic for this working group list. Please take the discussion elsewhere. Thanks, Joe On Sun, Mar 8, 2020 at 12:41 PM Tony Rutkowski wrote: > Hi Stephen, > > Amusing attempt to rewrite history. Your disagreement means nothing, > fortunately, and folks can claim FUD all they want. > > The reality is that the actions in this group are facing increasing > exposure to antitrust, tort, consumer protection, and tax-related > actions. If you don't want to be cautious, then lawyer up...or at least > get ISOC to buy you more insurance. :-) Oh, is it clear who is covered > by the insurance? > > cheers, > tony > > > On 2020-03-08 12:59 PM, Stephen Farrell wrote: > > > > On 08/03/2020 16:35, Tony Rutkowski wrote: > >> Stephen, > >> > >> It is not false. > > We disagree. SDNS != TLS. TLS was SSL with the middle > > S standing for socket, which wasn't part of SDNS or > > GOSIP that I recall. > > > >> It is simply largely unknown because of subsequent > >> IETF related narratives that choose to omit the history. The documents > >> are available online - although portions remain classified. > > Hah, that's funny. And with the classified documents > > defense of the falsehood, I'm done debunking this. > > > > S. > > > >> A request > >> is pending for their declassification and release. You can find some of > >> the details in the links in this article. > >> > http://www.circleid.com/posts/20190124_creating_tls_the_pioneering_role_of_ruth_nelson/ > >> > >> > >> Ruth Nelson - who led some of the important components - appeared at > >> last October's NSA Crypto History Symposium. She filled in some of the > >> details and the work was recognized by those there. Whit was also there > >> also there and gave a great presentation. Unfortunately, women in this > >> field seem not to get the credit they deserve. > >> > >> --tony > >> > >> > >> On 2020-03-08 10:56 AM, Stephen Farrell wrote: > >>> On 08/03/2020 14:46, Tony Rutkowski wrote: > TLS is particular has a history going back to 1986 when the platform > was > first announced by the USG and the TLS specification was instantiated > initially in the GOSIP standards and then in ITU/ISO standards. > >>> That's false. I've seen it repeated a few times but it > >>> remains false. Mostly, this falsehood seems to be repeated > >>> in tandem with efforts one could interpret as attempts > >>> to create FUD about Internet related security. > >>> > >>> TLS started in the IETF as a compromise between Netscape > >>> and Microsoft proposals for how to secure HTTP. > >>> > >>> X.509 started as part of X.400, then X.500 and is used by > >>> TLS. Today, I would bet almost all implementers never need > >>> to look beyond RFC5280 for X.509. And I hope it stays that > >>> way until we somehow figure out how to retire X.509. > >>> > >>> 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 > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] three ECHO issues
On 3/8/2020 10:14 AM, Stephen Farrell wrote: > I'm questioning whether that's a good goal or not. In my > analysis of the various extensions, only SNI and ALPN seem > to offer immediate value. Uh, No. First, we do have fingerprinting attacks that look at the pattern of extensions. If the extensions are encrypted in the ESNI, they cannot do that. And then, we have extensions that reveal a lot about the app, like for example the QUIC parameters extension. Those are just as sensitive as the ALPN. -- Christian Huitema signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] three ECHO issues
On Sun, Mar 8, 2020 at 9:08 AM Christopher Wood wrote: > Thanks for raising these issues! Please see inline below. > Were the comments on the previous PR considered in drafting this one? Some of them were just nits, but others were substantive. If there's no answer, I'd be happy to inspect the new PR for the old issues. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] three ECHO issues
On Sun, Mar 8, 2020, at 7:30 PM, Rob Sayre wrote: > On Sun, Mar 8, 2020 at 9:08 AM Christopher Wood wrote: > > Thanks for raising these issues! Please see inline below. > > Were the comments on the previous PR considered in drafting this one? > Some of them were just nits, but others were substantive. > > If there's no answer, I'd be happy to inspect the new PR for the old issues. Yes, they were. Please do check the diffs! Best, Chris > > thanks, > Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
