Re: [TLS] Industry Concerns about TLS 1.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Salz, Rich wrote: >> I understand your concern over what the nation-state actors are >> doing but it is not the same as what Enterprises do to manage their >> private servers, networks and clients. > > Okay, in technical terms only, what is the difference? > >> My personal perspective would be, that the approach to achieving an >> answer to that important question, would start with: > > It's too late for that. We're at the end-game, not the start. I'm > only a WG member, not editor, chair, or Area Director, but I would be > extremely surprised if there was any consensus to delay things. This whole thread looks scarily close to an attempt at throwing a spanner into the machinery. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======== Joachim Strömbergson Secworks AB joac...@secworks.se -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIbBAEBCAAGBQJX6466AAoJEF3cfFQkIuyN+xEP+OFOliFsdy8qzTlYFXwEKaHm CsujoaU/vswzXK6y3MadGn4rVhBjuaA1P4Iu5E1/w8Wlm7B6HOTXqM2iJVCv1bQs D8iS5JRS9TR3cnXtEDk51V+nYQmDxFBhNILwukVrp8alvvVh/ww21bLxrp9xrLy5 8rfynu6BD2QreVfRGYDjT4rfxU5t+EecwCsxBn1JM/+Uv0/e/cFQVI55dnWm4OWi WwX7ieRyd/N76VadyHhAV9VFXnpIewBSINyroCfBEHDeiDmYEQcCcIOVjMI6EHp8 T3D/rCZR865G06PO7gxY4IVsS4pbd3lXYyG/+9SSDm/axWJ7FasoaoaqXm19EaCc p9399BaJss7kLS+1c63axzm7xcdRE1fqJN2oJNlRnD7zv6ycvcg2cbuC5HUKasHx H9RL7VAry33KP8EGBMPbf8Ep9IfX2l/dtMe1FMuNaTajsXj9vMKi0eOZ5EVPykqZ fuX9rwMUXafNkWVrVUflxQHU9fY6+5ZkncoEtUUQASlGeL2K9edMdUD0vs5WceHe HYc4mLdJsi88crwE5/HPQHl8ncZCTwlMTxxyAdySf4uotKPQytnPha1mPrijOUQS A4KEzIA1BcEFSdMR/3v2Bw8qNLA5HU5fV22NBlS8nYkgdqmmF9nwUTgJ7G2x8zcw 2HBLYpaDWnMyGEcaAv0= =9iJ/ -END PGP SIGNATURE- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] chacha/poly interop?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! David Benjamin wrote: > TLS-ChaCha is actually RFC 7539 which comes with its own test > vectors and isn't TLS-specific. > > Our implementation matches RFC 7539 and seems to match the one test > vector I tried too. Note that that draft includes a number of things > like 128-bit keys and 8 or 12 rounds which are not applicable. The > test vector whose answer begins "0x76 0xb8 0xe0 0xad 0xa0" is the one > you want. Also worth noting is that in RFC 7539, ChaCha has 96 bit IV/nonce and 32 bit counter instead of a 64 bit IV and 64 bit counter. The 32 extra IV bits are used to initialize the state in the same way as 32 bits in the counter. So its a simple matter of mapping the IV bits to the counter bits and chacha will match the test vectors in RFC 7539. It tripped me up when integrating the ChaCha core into my RFC 7539 ChaCha20_Poly1305 core. https://github.com/secworks/chacha https://github.com/secworks/ChaCha20-Poly1305 Note: the chacha-poly1305 core is not completed yet. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ==== Joachim Strömbergson Secworks AB joac...@secworks.se -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIbBAEBCAAGBQJX27e0AAoJEF3cfFQkIuyNERkP9j+Dp71dbqKIBEYkcW8dOMUv RbHDfg9vRAelOyvSppOjXu3bSoNUNg2qC7KJEfY85SZERXSsLUTBzQIzinRRx33K 2HacSqSR0TmhhWThziDADOMpPoFAWyRrjVAXWTj4oThHZ4B8yM3lCC6bF+WuNiJz JiiYLc8BvQqdGOMhyuoACpd7b12Dm25nbRcXFUUTZOBnIMhjevBPhUzLj/EQuWkS oDQ/3F3g33AFE0zUmZNMbkHcmkr9A5jWGOW7NbhqcifLl+llp9o8J2EFw2daF7nE jrwMmalUJu4s9vlvW0Md9N8TSHEPOWUxDpoCs+6slxwHFEK+0HmOHnYsMLJMoQs9 C6dUNsCeOA1N6jmw+40TveE597YkmEqvOgz0RG3XxIIRX2S0F9OSjgYdw4taPWJ6 7Zoc7YblNifbdyB+HT6T5udlBgGLvk8EzrIklVzDwLtOljy4Ryd4HDMF6/3jJh6W v/QVhoOkXecglriU95SgNipBousTvID+hxrHaCq4BqlMtojI4Buyv76mMRGLRXpZ lIiJOuJ4iM1xCZ58YiNaTU++jIqml0TX7YgEW7ZvbPP0nXaJ7xaW0tBYk9ho/Q/7 zLMZWIXr/bbaycAuJ8k6our0HCphh0kg/AN/F8FAvUL7xD4nM/Zn9ATVjHR+LyTv iX0edtmGXGJ6KJBzEio= =ERLC -END PGP SIGNATURE- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Cfrg] 3DES diediedie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Derek Atkins wrote: > Because this is a light bulb that sells for $6-10. Adding $2 to the > price is just completely unreasonable. The price point needs to be > pennies. Note that this is just one example, but yes, these level of > products are getting "smarter" and we, as security professionals, > should encourage "as strong security as possble" without getting the > manufacturers to just say "sorry, too expensive, I'll go without." > (which is, unfortunately, exactly what's been happening) There are connected light bulbs and LEDs that contains ARM based MCUs on the market today. Those MCUs costs less then 10 cents in high volume. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======== Joachim Strömbergson Secworks AB joac...@secworks.se -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJXz72YAAoJEF3cfFQkIuyNkTMP/ixcCRpt4e5BlVvKqWbeXzjo Rv3OPqnnezPwUb823g2ODWGzbumc2kD9buREtTF1fr87T+bH77vS5SATsY62M2PL DFYbRCzV5IED5RXgO8YqiyHQJMCeMVmDmrlIEFWqEWkM6V2tlj9vLRKW0EuCdXAa GhnVDr3Qn7hchkxE/MWlUQiG6sTsC7KSofCsW2TNKQ0rVbovcS14VC99eul4mxk/ 1SVBMPdWbejyB5gBZ3r2brFEeRfDrJL2YLYJlU9aIanY4ZT3hNLlIWAgp4hLwLFw VPQkjby7zuLS53RZ2wOvQxdwl2poNX3KgrMqFxJnd06FWE4GhMVRXDyeu+sAzYpD bpsVvWpxfjbRYsh9PLCelqwuuhUyVJpcjuJeXBNkV1rqPbpQ6cA9yMARE3um3EAa qUx3gp0uMryqRmBLWNsqHvQAD4OpQqgS8pT4HTRuRKmZggtHKMObqUcBtUcIrJx+ VyFVwsDhgkeHD56SKN/hywjwPV4dZHnJGPUSXPwXa5rU21vjFCNInAm/+MQBAtEV 7XUDi2ejdTykuQpcs6QuZyKpXzEn5hbtN1b3lM35AJUIex1srPhUUcojU9GH02NT l/7qMQH40qybEB+DPaTSMW1jT6niyWVLtaQHEwJPR+xNTzJRyNc68ZWs/c6zvMCC rKcczay2SEf4EWLER2Yt =P0FV -END PGP SIGNATURE- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Cfrg] 3DES diediedie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Hilarie Orman wrote: > An ARM is far too much hardware to throw at "read sensor/munge > data/send data". No, they are not. The Cortex M0+ is aimed at these kinds of very simple systems that runs for many years on a single battery. Look at the STM32L0 series from ST for example. These devices can run on energy harvesting and very tiny physically and very, very cheap (ten-ish cents in high volume): http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32l0-series.html?querycriteria=productId=SS1817 The STM32L021 has an AES-128 core. Not very fast (200+ cycles), but several times faster than SW. You can also run the AES core wile the CPU core is in power save mode. Another example is the Zero Gecko from Silicon Labs. Same price range, a huge number of power modes. And an AES core that is really fast. 50+ cycles for AES-128, which basically means 4 cycles/round (which implies 4 S-boxes) https://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko/pages/efm32-zero-gecko.aspx Pre-shared key is whats easiest. But I've implemented Curve25519 for key exchange on the STM32 device and can achieve <1 sec performance with about 1 kByte RAM and 8 kByte code. I'm sure Peter Schwabe has some much better results. Yes, you can limit yourself to an 8-bit MCU and shave off some cents and a little bit of power. But for most applications I see, a Cortex M0+ meets technical and commercial requirements too. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======== Joachim Strömbergson Secworks AB joac...@secworks.se -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJXx923AAoJEF3cfFQkIuyN4tkP+QGscSmBzUAPbamlaRqpm7sh zVwhMwhllJMdTs+HozeSbMvtw7JlO5vu+PyD/El4sxP2SAQhv1LqJFaC0nxuCJ2P I+RxISEkrxYYB2YDRGlPd3Cfm4cRrDBd/BQCPMZuAQurWxH7ptMMKIZ3hS6NuOIb gyluKMDMrUW9qFx0lrpa3yAMPHrBqlhHl1GmcUMJwoRVGOxDdc243YjNB7J/FEDh pJCzI8Dv4uyWEufr0cBv1xCiSY4eaalv25H/Cyc3rZ78Os7d52DUyuBD8IAuAkkH i32L2gK7CbrCF/3zw+Tv2aDn1ncGOiucENmQIzO99hwWwtJFC7TN59rCtoArmh5U EC0Ncq1IIbicrot+DLibHNvSWk0c15bvtg1c06UecME21SF2t8ZigF0OuYKGdeu1 a4h0dUcNUyQxUbAs9JDTXtwABvR7CMNZi3kD5Vh8NfvK7DmojPVThrQ1r/2x+6hS QnPiZcuvedjkM19y1hRchZQT23qPJQ4TrC5MvQSHnU20oW3QomPJfTAXtCctsN5s 3b+ZdWh5/EAysPpgjzzwKP0mWN3tkeSKROsh6BabMku84zerKPzCn5MwhyhUqHLD Sv453a5oK0ne5pD/b7CIPWRwK2Z6/6pFN+jWPG0SZtZTgEJjkSVPaskMd51SVSga EkqJv7VnqIa5lP5es+Is =ri48 -END PGP SIGNATURE- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Peter Gutmann wrote: > In these situations, crypto comes at about position 77 in the > priority list, with most of the previous ones taken up by > "reliability" and "availability". If you write a spec that in effect > mandates a 15-second delay in communicating commands to a controller, > guess what vendors are going to do? They are going to do the handshake once every day (or even less) and keep the session alive. Or use session resumption. Based on what I've seen in PLCs you normally don't start a new session for every single command. YMMV. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======== Joachim Strömbergson Secworks AB joac...@secworks.se -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJW8RjHAAoJEF3cfFQkIuyNVTEP/ip7HWyE6MROHjT1OhDHnYa2 R+dcW4nW8cf6BzCg3SmQl5ldB4Fw5t6m/htySDzmSMgGSAnXO9XaFaALHrKHQKc5 csI00gWz6bO+LXRgsFnXD5z7lcEAu6NJ6IPMR9z1ueUXIzZoRUkE1o4G4zUmAgjR nNITn9HRmPyeysKiYPHwkHrQTQTf1kBgdp7yfvLPu0j8WQUOhzxLPk1S/9pbRgI6 9CnpngVNf4aRBRzqmRDQwtNsSswNP7xRwEVvjObfzXqOME7CZsxegEN/wNDPkx5H Gp7J1Q/l5zUBW7wRXHJdlmq2vlUc6B4kJMC1deZDLA0sNM+3BNVN1SEaroW9TMDj GdEjdVO6MImBgrLBpOlpgHoD/FRXJXENv+QR8AQMFbUejkP3gcyb0xtz2PTC79xl Qvr2pwCCStr8QIoWVaDTF9ia8CCPtZpVEZ0Zl8B91QqQ0+7tSoDqUy84JA0m3kMN rskv70CREq48U8yvPDh7EWbd9eOIz8jIiy7dMSAYprNdeZ0K5QMZe+iZbpz70Djn vZd5vyBySxMeKHqvf8BV0H2hx6gU0Y+RC/A+DQ69ieBicdzpb2BZrgpW/rFrM+TA 3L+3nKOIvL3xZ7xhlAayj7bbvaN6NloSH2OG246Zus4UAPZTzifKYEPQ3ogEC7VQ L37kW5FIZxmdAgzi2eTs =eO/5 -END PGP SIGNATURE- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Include Speck block cipher?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Efthymios Iosifides wrote: > The reputation aspect is not necessarily and strictly correlated > with it's provenance, but with it's actual security and performance. > And the SPECK we shall note that performs quite well. Also we shall > not forget that even the infamous AES has been approved by the NSA > before the widespread use of it. In any case i wouldn't like for us > to stand on the popular press. On the other hand we shall evaluate if > the SPECK could be actually used. For example, the fact that it lacks > extensive cryptanalysis is a serious argument for not using it today, > but what about the future specifications. Hold on here. There is imho a fairly big difference of how AES came about with an open competition compared to how Simon and Speck has been developed. Yes, NSA was an important part in the selection of Rijndael as AES. But that is not the same thing as they actually designed it. Right? Also, there has been tens of ciphers proposed the last few years aiming for the ultralight space. Some of them are as complex in terms of code and data requirements as Speck and sports about the same performance. See for example: https://eprint.iacr.org/2013/295.pdf http://www.ijsce.org/attachments/File/v3i5/E1933113513.pdf Most of these are Feistel based and some of them uses S-boxes. But there are really quite a few alternatives. And besides, as is shown in those links AES can be implemented to not hog resources. The internal operations operates on Bytes. The big issue is the S-box and the extra space needed if you need to expand the key (which is only really needed if you need to decrypt. If you use a good cipher mode, it i not needed.) > On top to that what if we could prove that the SPECK can have better > performance than other algos without sacrificing the security. Start by proving that. Based on what is published I think it will be hard to show significant gains with Speck compared to other ciphers. The two papers published so far on the cryptanalysis does not give me a good warm feeling for long term security of Speck. And the last point is really the thing, right? We are talking about a cipher for embedded stuff, Internet of Things devices. These things are deployed and will be doing their chores for 20-30+ years without much love and maintenance. The communication are typically low bandwidth and with good delay resilience. So what is needed is something cheap (compact in terms of resources) and good, well proven security. I don't see Speck shining much brighter than others in this respect, on the contrary in fact. If you look at what MCUs are used for IoT today and moving forward it is quite probably an ARM based device (Cortex M0, M0+ for example). AES can be implemented very compact and give good performance on this architecture. And even better, for well under 1 USD you can get an ARM based MCU with AES in HW. I fail to see why anyone would be interested in Speck and would never recommend anyone to use it. But hey, write a draft and try to get an informational RFC for it if it scratches your itch. There are several other RFCs describing ciphers not being used very much. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======== Joachim Strömbergson Secworks AB joac...@secworks.se -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJW8Qz+AAoJEF3cfFQkIuyN2eoQAK85EwmpLc2iqAMkA/I2ogB+ DsCvYl7ZxwpBgWzTfHSeVwccclC0FwcGvPIvCegAU5Barv58Mc5L+7mLnJ1hn8LR qTfQYz9yXyipn/6L0PDca2gpoSi/QqbJtlBRWfNYdmaqb1K8X5A8qgljtJMHNDEP eSHgmLFKLVpJFQbp2aGlqSwysEwaseTvLWfbWLBeA6itBivwxm2LtN1GT9ZTHlD9 /NfZockKF3bLOYaachtS84tIA8CKUhmRvf2/5e1MVDEZ53JivoSNZuNAjeMAlCED NMG6IfsKrEWisQaBliUaE3OzGxh2y1AGpw72/Fx2MmduaroR4nhiYWnMfvk2PRue ALEx0qFmBqverSTK78NzseGQBGu+iER7mQl2wK7d+1NDoNTNiijqB4aYNZeGwRc9 IeeVIKo/qTbZBH5qoI5nQRKsCdvsN36Sw7kSy1oCw5NMBMQBnk9vOZeAna7TUMas jnAF1ReH3dc2XeKJ9GdomZk60eHambIQBrPVlkziXcfECQo9CtXHK/OvYtGDHCmr Owb5ftgqojWKZdp+IA0hHWQe01x1nwrwE95G2VtWfN+ZqpSTcE21GBDRRL6TcogQ gfRMfcSMrggSE3BH/i+Bmaloee9vvo13t1SS7YpxJjjMZgCtngaWbtgS8xlcf0TQ ioZfyFBxQMckohswjyWp =s6MB -END PGP SIGNATURE- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Peter Gutmann wrote: > Hubert Kario <hka...@redhat.com> writes: > >> Note that I asked for "being able to handle", not "selects and >> uses". > > The issue here is that a Cortex M3 isn't going to be able to handle > RSA-2048, no matter what an RFC says :-). That's what the "ability > of the hardware to deal with large keys" was meant to say. When you say that "a Cortex M3 isn't going to be able to handle RSA-2048", what do you mean specifically? Considering that it is being done by for example SharkSSL [1], is supported by ARM mbed TLS (nee PolarSSL) [2] I fail to see what hardware limits you are seeing. Yes, the speed you get is not impressive (1-2 seconds to decrypt), but it might be ok, depending on your application. [1] https://realtimelogic.com/products/sharkssl/Cortex-M3/ [2] https://tls.mbed.org/ - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ==== Joachim Strömbergson Secworks AB joac...@secworks.se -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJW7/IsAAoJEF3cfFQkIuyNRlIQALbyX6t1xkXXQhj1PKLXvJqk OGWio/xk6pGow5Cqm3szXaUBOUThsuO6qkjFwZWrgj+sd+IXLd6rPxUlsPlJaAU5 hwib7jp5eCo/gFz9qTXe7PE8dZ2MU9BxRI8cB7paiR9VXxOS9v7m56SLsiPZRYNx S1U+trMzYPOZXJcy+HyTMQGvVpwWWcXsg03t66b5Lwem0SJK6yRSjnDmH5kCwJrX YsN4sQWvNCFsYf8e0A1/pTWeEo/+JqmNYo7b6sa/RanY7dhH8nwDJYPQnMTbOsdb MP73CC6yu1+tM30i6ubN89TLBzhtHpClW06tFr5rES06AE0UlW4hw43+3nfyp6QF j6gvpCO43LC36eIvu/sY/MBlZ2S3RfHAjexbSZo4TXJM3e/kavlPmPEyFJmEu0q4 kdM+VtXoq89cL10jqCPeTLzsWwJoap+iJzmPIOhlY9os4eGCV49z6wxMgV4WNu1v G7icxZnIdjSJiOs1DBt0jr2gDs1KTs936EzBp3LjeElo43IituUtYhyaiWG3trjI YDMcQpZa1uQDh7rMfNzyjVtV7FBUVUDDLOLk4vHO/0jL0q1PGA6lZjQ2Bg9cAFTs yhFbQhb9xgsI69aPcfqaVVZJEEyMZ7YMyhfykltp208iCgQTwlIVE3liqnlCwH2V xzxKDvzDwGqaNawLEZx7 =FHTY -END PGP SIGNATURE- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Include Speck block cipher?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Tom Ritter wrote: > On 17 March 2016 at 21:09, Martin Thomson <martin.thom...@gmail.com> > wrote: >> On 18 March 2016 at 12:37, Mike Hamburg <m...@shiftleft.org> >> wrote: >>> No. The goal should be to remove ciphers, not add new ones, >>> unless we have a really compelling reason. >> A necessary, but sufficient set of reasons might include: >> >> 1. thorough cryptanalysis 2. advantages over existing ciphers on >> important metrics like security and speed, though this would likely >> need to be significant at this point 3. interest in implementation >> >> Speck is 0 from 3. > > I might make it .5 for 3. Speck is specifically designed to be a > lightweight cipher for constrained devices. With RC4 dead in the > water - we don't have one of those. (Unless ChaCha20 is better than > Speck/Simon/related...) ChaCha20 was not explicitly designed to be lightweight. That said, it is fairly compact and get good performance on smaller architectures. Even though the internal variables ate 64-bit, the ARX operations are easy to map to smaller registers. The closely related Salsa20 cipher requires about 5 cycles/byte on ARM: https://www.hyperelliptic.org/tanja/vortraege/20121129.pdf But if we wanted algorithms optimized for embedded, small architectures we could look at the ECRYPT eSTREAM profile 2 ciphers: http://www.ecrypt.eu.org/stream/ AFAIK they did get a fair amount of analysis. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. Joachim Strömbergson Secworks AB joac...@secworks.se -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJW768TAAoJEF3cfFQkIuyNI6kQAJqE8LL0RJl4hZGufq/qeMId q4t6m+kHLu0mZhufNUAs15yMz5XA4El0ZBOKuNml4sUUYRZWyUCinALjXvJ6gxEV jptsj9XiEKYGrmIOjOZxBo85oeKYgDKDvvXmgS5BWmsOFzvjTteuIV2udwEzydWo yWoHmYba47vI/R6GwNLykkaum3dYpYuZQtcRYHZO34/+asxcmhDydR03iYKOJWM6 EG1HyT2Wc9nzeXifzp21IdMFYe67IFz3E9/0YLExyInBA2ZCE1/ziQn/m2ZpSsBN DFjp6Rg3U6FkcvJ9f/xz0ltG5rp5+NZAGfzc5rcRNZ3sZfF1DbyV9bCcppWngjmd /7HYuzAWoveMmxcWU64ClFdUhkyMDyeBd3gRDq74GWXjHszZifFNxtEG2IKclqco HmrP7OWdEpeaaSF1EmKZwSjwNlpWD7OAYykTYoRqtETF4hzj2jqniFuG+QEy7MsS 9oMnI2ojNVkfDISlWmeDDIXEnH5m/RHQqXqK9YQwSM/YDz1mGidQjjJm576+M10y Ok9v/WswIuqwATtfKX8AWXci1YojwhY9iBegTDawphwRLtV11JRsY0C+iUD1xjJ3 Jywlx7d+HDZ0XX10NJS80FhJE9wzo12F93fntGlKsLDPzKhtiQfmulY4RFrr/LlU INSG+VzHMYQmPAjTVDCc =2IW+ -END PGP SIGNATURE- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
