Re: [TLS] Regarding the identity bidding issue when using raw public key with TLS
Dear ilari, Thanks very much for the reply :-）. Please see my comments inline below. -Original Message- From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] Sent: Thursday, July 12, 2018 8:17 PM To: Wang Haiguang Cc: Subject: Re: [TLS] Regarding the identity bidding issue when using raw public key with TLS On Thu, Jul 12, 2018 at 09:30:40AM +, Wang Haiguang wrote: > Hello, everyone, > > To solve the complex issue caused by the certification, in RFC 7250, > it is recommended to use raw public for authentication. > However, when using RAW public directly for authentication, identity > and public key binding is required. That is, server need to maintain a > large table to map the public key and identity. > For networks with huge amount of IoT devices, the maintenance of such > a huge database might be a challenge issue. It seems to me that getting the information to provisioning to the database is the biggest issue. Any semi-decent database program should not even be breaking sweat with million row table on quite low-end server hardware (if the indexing is even remotely sane). [HG-1] Yes. Getting the information and provisioning to the database for massive IoT is a big issue. Using IBC as raw public key, then we might be able to get ride of this issue, especially for network operators. They may just care about the number of devices connected to network instead of knowing the details of each device. > Currently we are thinking to use identity-base public key to solve the > issue. Is there any better solution to solve the identity binding > issue? If you do not want to use server-side database, create an internal CA and issue as compact certificates as possible. The overhead should be in low two hundred bytes. But this does not save you from having to figure out what those IoT devices actually are! [HG-1] Internal CA and compact certificate can help in some scenarios, but it will limit the authentication to a local domain. With IBC, we can keep the certificate compact, at same time, it can be used cross domain. > Can anyone give us some comments regarding using IBC as raw public key > for TLS for massive IoT authentication? I do not think there is any way currently to do that. The only defined signature algorithms are ([*] means removed from TLS 1.3): - RSA PKCS#1 v1.5[*] - DSA[*] - ECDSA - EdDSA2 (Ed25519 and Ed448) These are also the only algorithms that can be used with raw public key authentication. None of these is IBC algorithm.. Also, the way the raw public keys work is the same in both TLS 1.2 and 1.3 (the precise messages are different, but it still works the same). [HG-1] Yes. With TLS-1.3, IBC algorithm is not supported at the moment. So we hope that we can develop a separate RFC based on 1.3 and support IBC for massive IoT usage scenarios only? RFC 6507 specifies an IBC signature method based on ECC, it is similar to ECDSA. We can start with that first. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt
(Chair hat off.) On Wed, Jul 11, 2018 at 10:37 AM, David Benjamin wrote: > On Mon, Jul 9, 2018 at 12:58 PM Eric Rescorla wrote: >> >> On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla wrote: >>> >>> Thanks for writing this. >>> >>> I would be in favor of deprecating old versions of TLS prior to 1.2. >>> Firefox Telemetry shows that about 1% of our connections are TLS 1.1 >> >> >> This should be 1.0. >> >> >>> (on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible. >>> >>> This is probably a higher number than we'd be comfortable turning off >>> immediately, but it is probably worth starting the process. > > > Metrics from Chrome report 0.43% of our connections are TLS 1.0 and 0.03% of > them are TLS 1.1, which is a similar situation. I too am in favor of > deprecating them and getting things started. Our system-wide metrics indicate 0.36% and 99.6% of connections are TLS 1.0 and 1.2, respectively. This does not include all code paths, though it covers the overwhelming majority of use cases, including mobile mail. Thus, similar to others, I'm in favor of deprecating TLS 1.0 and 1.1. Best, Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt
Hiya, On 13/07/18 13:24, nalini elkins wrote: > Stephen, > > Sorry for the late reply. I was travelling to Montreal from India and > was jet lagged. No problem. And that'll be me tomorrow:-) I generally agree with Ekr's mail just now but a little bit more below... > >> >>> I am thinking the following: >>> >>> Location: U.S. / Canada (possibly U.K.) >>> >>> - 3 banks (hopefully from the top 5) >>> - 3 large insurance companies (includes back end processing) >>> - 3 U.S. federal government agencies >>> - 3 companies in the Wall Street / Stock brokerage sector (includes back >>> end processing) >>> - 3 large credit card / processors (ex. Visa, Discover, MasterCard, > etc.) >>> - 3 in the retail sector (Home Depot, Target, Lowes, et al) > >> Those are pretty small numbers unless they're interacting with >> a lot of TLS services. It'd be hard to know if they'd be >> representative of something or not if they're anonymised in the >> results. > > I would expect that these people would have quite a few applications > using TLS. Telnet, FTP, MQSeries, SMTP, and many written by the > organization itself. > > What numbers do you feel WOULD be representative? Well, for externally visible services, that information is public already and visible via e.g. censys.io and similar so you could just omit those from any numbers you report I guess. I've not thought so much about things that are only visible internally, though I did (have a student:-) do some scanning of our university n/w early this year, but I've yet to look at that data so a) I still need to verify it, and b) I'm not sure how I'd report on it in detail. That said, what he reported for port 443, was ~800 regularly seen servers in the bits of n/w he scanned with: SSLv3 (18%), TLSv1.0 (35%), TLSv1.1 (0%), TLSv1.2 (45%), TLSv1.3 (0%) Which is a tad sad;-( I think many of the SSLv3 and TLSv1.0 servers were on things like printers, conferencing boxes, access points and servers that are have basically been left running when nobody cares for 'em any more. But that's the bit I'd like to go re-check before standing over those numbers. And I'd also like to know more about how those change over time too, and look at other ports and not just 443. (Doing that is somewhere down towards the end of my to-do list but maybe I'll set another student on it later in the year.) If you could quote figures (and rate of change) like those for identified networks that'd I think be useful. If you anonymise and/or aggregate then it's a bit harder to know how to interpret the data. (E.g. the fact we're a university likely means we've more forgotten web servers I guess;-). And if they're guesses and not measurements, or if it's not clear what was measured, then it's really not so useful. I guess the thing to keep in mind is that it's better if the findings can be replicated or otherwise validated. (If it helps, my student's scanning code is at [1] but I reckon there's a good bit of work to be done to make that usable for anyone else.) >> I'd encourage you to try get people to be open about >> things here - there's no particular shame in having 10% TLSv1.0 >> sessions after all:-) > > It isn't a question of shame but it is just a bit too much information > to provide a potential adversary. That is, to say that Stock Exchange XYZ > has n% of TLS1.0 clients provides a potential attacker too much > information. Not sure I agree there tbh. If they're externally visible services, then it's public already. If they're not, and the attacker is inside the n/w, then the bad actor can find it out then. But I do understand organisations being shy about such things. Cheers, S. [1] https://github.com/mikeyPower/final-year-project > As I say, most organizations that I know are trying very hard > to migrate from older versions. It is not as simple as it might seem. > > If the organizations need to be identified by name, then I think this will > be a show stopper for any kind of data that I might be able to provide. > Having said that, I completely understand (and share) your distrust of > anonymous data. I am at a loss as to how to proceed. > > I am open to any constructive suggestions. > > Thanks, > Nalini > > > On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell > wrote: > >> >> Hiya, >> >> On 11/07/18 06:45, nalini elkins wrote: >>> Stephen, >>> I'd love to add more detail like that and/or more sections for other >>> protocols if folks have data to offer with references. >>> >>> I believe that I can reach out to various people I know. Please comment >>> if my methodology is acceptable and if you think this will be helpful. >> >> It's not whether the methodology is acceptable to me or not >> but whether or not the references to the numbers are credible >> for readers:-) >> >> A few comment below, >> >>> >>> I am thinking the following: >>> >>> Location: U.S. / Canada (possibly U.K.) >>> >>> - 3 banks (hopefully from the top 5) >>> - 3 large
Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt
On Fri, Jul 13, 2018 at 5:24 AM, nalini elkins wrote: > Stephen, > > Sorry for the late reply. I was travelling to Montreal from India and > was jet lagged. > > > > >> I am thinking the following: > >> > >> Location: U.S. / Canada (possibly U.K.) > >> > >> - 3 banks (hopefully from the top 5) > >> - 3 large insurance companies (includes back end processing) > >> - 3 U.S. federal government agencies > >> - 3 companies in the Wall Street / Stock brokerage sector (includes > back > >> end processing) > >> - 3 large credit card / processors (ex. Visa, Discover, MasterCard, > etc.) > >> - 3 in the retail sector (Home Depot, Target, Lowes, et al) > > >Those are pretty small numbers unless they're interacting with > >a lot of TLS services. It'd be hard to know if they'd be > >representative of something or not if they're anonymised in the > >results. > > I would expect that these people would have quite a few applications > using TLS. Telnet, FTP, MQSeries, SMTP, and many written by the > organization itself. > > What numbers do you feel WOULD be representative? > > > I'd encourage you to try get people to be open about > > things here - there's no particular shame in having 10% TLSv1.0 > > sessions after all:-) > > It isn't a question of shame but it is just a bit too much information > to provide a potential adversary. That is, to say that Stock Exchange XYZ > has n% of TLS1.0 clients provides a potential attacker too much > information. > Well, this seems like it is primarily true due to deficiencies in TLS 1.0 or the software running it, in which case so much the more reason to recommend updating. As I say, most organizations that I know are trying very hard > to migrate from older versions. It is not as simple as it might seem. > > If the organizations need to be identified by name, then I think this will > be a show stopper for any kind of data that I might be able to provide. > Having said that, I completely understand (and share) your distrust of > anonymous data. I am at a loss as to how to proceed. > As I said earlier, I don't think the deployment fraction is that relevant here. The question of whether the IETF should deprecate TLS 1.2 is primarily one we should make based on the technical merits of the older protocol versions compared to TLS 1.2. Given that we know that 1.2 is more secure and that 1.0 has serious deficiencies, it seems like the two next questions are: 1. Are there respects in which TLS 1.2 is not an adequate replacement for TLS 1.0? I think the answer here is pretty much no. [0] 2. Is the deployment of TLS 1.2 so low that it's just silly to tell people to cut over. That's clearly not true in the Web environment, though perhaps it's true in some other environment. However, that would be a number more like 30% TLS 1.0 rather than 5-10%. Is the number that high? Absent those things, then it's a sensible recommendation for the IETF to make. -Ekr [0] This is less obvious for TLS 1.3 in that we removed features with low usage. > I am open to any constructive suggestions. > > Thanks, > Nalini > > > On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell < > stephen.farr...@cs.tcd.ie> wrote: > >> >> Hiya, >> >> On 11/07/18 06:45, nalini elkins wrote: >> > Stephen, >> > >> >> I'd love to add more detail like that and/or more sections for other >> > protocols if folks have data to offer with references. >> > >> > I believe that I can reach out to various people I know. Please >> comment >> > if my methodology is acceptable and if you think this will be helpful. >> >> It's not whether the methodology is acceptable to me or not >> but whether or not the references to the numbers are credible >> for readers:-) >> >> A few comment below, >> >> > >> > I am thinking the following: >> > >> > Location: U.S. / Canada (possibly U.K.) >> > >> > - 3 banks (hopefully from the top 5) >> > - 3 large insurance companies (includes back end processing) >> > - 3 U.S. federal government agencies >> > - 3 companies in the Wall Street / Stock brokerage sector (includes >> back >> > end processing) >> > - 3 large credit card / processors (ex. Visa, Discover, MasterCard, >> etc.) >> > - 3 in the retail sector (Home Depot, Target, Lowes, et al) >> >> Those are pretty small numbers unless they're interacting with >> a lot of TLS services. It'd be hard to know if they'd be >> representative of something or not if they're anonymised in the >> results. I'd encourage you to try get people to be open about >> things here - there's no particular shame in having 10% TLSv1.0 >> sessions after all:-) >> >> > >> > Note: I put in "back end processing" because these are the folks that >> most >> > often have many connections to other business partners and so in some >> ways >> > have the most complex systems to deal with. >> > >> > Note #2: This is aspirational! I hope I can get all these people to >> > cooperate. I will try at least to get some in each category. >> > >> > >> > I will ask them
Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt
Stephen, Sorry for the late reply. I was travelling to Montreal from India and was jet lagged. > >> I am thinking the following: >> >> Location: U.S. / Canada (possibly U.K.) >> >> - 3 banks (hopefully from the top 5) >> - 3 large insurance companies (includes back end processing) >> - 3 U.S. federal government agencies >> - 3 companies in the Wall Street / Stock brokerage sector (includes back >> end processing) >> - 3 large credit card / processors (ex. Visa, Discover, MasterCard, etc.) >> - 3 in the retail sector (Home Depot, Target, Lowes, et al) >Those are pretty small numbers unless they're interacting with >a lot of TLS services. It'd be hard to know if they'd be >representative of something or not if they're anonymised in the >results. I would expect that these people would have quite a few applications using TLS. Telnet, FTP, MQSeries, SMTP, and many written by the organization itself. What numbers do you feel WOULD be representative? > I'd encourage you to try get people to be open about > things here - there's no particular shame in having 10% TLSv1.0 > sessions after all:-) It isn't a question of shame but it is just a bit too much information to provide a potential adversary. That is, to say that Stock Exchange XYZ has n% of TLS1.0 clients provides a potential attacker too much information. As I say, most organizations that I know are trying very hard to migrate from older versions. It is not as simple as it might seem. If the organizations need to be identified by name, then I think this will be a show stopper for any kind of data that I might be able to provide. Having said that, I completely understand (and share) your distrust of anonymous data. I am at a loss as to how to proceed. I am open to any constructive suggestions. Thanks, Nalini On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell wrote: > > Hiya, > > On 11/07/18 06:45, nalini elkins wrote: > > Stephen, > > > >> I'd love to add more detail like that and/or more sections for other > > protocols if folks have data to offer with references. > > > > I believe that I can reach out to various people I know. Please comment > > if my methodology is acceptable and if you think this will be helpful. > > It's not whether the methodology is acceptable to me or not > but whether or not the references to the numbers are credible > for readers:-) > > A few comment below, > > > > > I am thinking the following: > > > > Location: U.S. / Canada (possibly U.K.) > > > > - 3 banks (hopefully from the top 5) > > - 3 large insurance companies (includes back end processing) > > - 3 U.S. federal government agencies > > - 3 companies in the Wall Street / Stock brokerage sector (includes back > > end processing) > > - 3 large credit card / processors (ex. Visa, Discover, MasterCard, > etc.) > > - 3 in the retail sector (Home Depot, Target, Lowes, et al) > > Those are pretty small numbers unless they're interacting with > a lot of TLS services. It'd be hard to know if they'd be > representative of something or not if they're anonymised in the > results. I'd encourage you to try get people to be open about > things here - there's no particular shame in having 10% TLSv1.0 > sessions after all:-) > > > > > Note: I put in "back end processing" because these are the folks that > most > > often have many connections to other business partners and so in some > ways > > have the most complex systems to deal with. > > > > Note #2: This is aspirational! I hope I can get all these people to > > cooperate. I will try at least to get some in each category. > > > > > > I will ask them the following questions: > > > > 1. How many applications do you have? (This may end up being only the > > mission critical ones as otherwise it may be too hard to obtain.) > > I'm not sure that's so interesting for this question. And I'm not > sure that different people would count things as applications in > the same way. > > > 2. How many are using TLS and how many are still plain text? (We will > > disregard SSH and other such variants.) > > Again, that's not so interesting here. > > > 3. What percent of clients are using a pre-TLS1.2 version? (This will > be > > an estimation. > I don't see why this needs to be estimated, this is kinda the key > measurement needed and easy to measure. There should be no need for > anyone to stick their thumb in the air for this:-) > > It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and > TLSv1.3) and to say for how many TLS sessions or hosts/IPs the > figures apply. > > And of course providing as much context as possible so that it's > possible to understand the numbers and whether or not the numbers > from different sources are based on the same or different kinds of > measurement. > > > > > 4. Do you have an active project to migrate off of older versions of > TLS? > > Sure. > > > > > 5. What do you estimate your percent of clients using pre-TLS1.2 > versions > > to be next year? > > I
