Re: [TLS] Tricking TLS library into crypto primitives library
Pure-python forbids using the cryptography package. Only python code and the python stdlib are allowed. The fact that TLS uses AES at all means it might be possible to trick the python ssl module to do arbitrary AES, with some effort. At the end of the day, the TLS protocol is also part of the ssl module's API surface. It's not the API surface you'd usually interact with, but nothing really stops you from doing so. On 6/25/23 14:31, Eric Rescorla wrote: I believe https://cryptography.io/en/latest/ is what you want. TLS does not use AES in a way that is consistent with what you would get if you just used a typical AES library. -Ekr On Sun, Jun 25, 2023 at 10:21 AM Soni L. <mailto:fakedme%2b...@gmail.com>> wrote: Python doesn't expose raw AES, etc. But it does expose a fairly rich TLS library. Wondering if it would be possible to just connect a TLS socket to a raw TCP socket and somehow write bytes into TLS and get ciphertext out or write bytes into the raw TCP socket and get plaintext out. The point is to use AES for non-TLS protocols. On 6/25/23 14:15, Eric Rescorla wrote: I'm not aware of any. Why would you want to do this? Most such libraries I am aware of expose low-level primitives or are built on libraries which do. -Ekr On Sun, Jun 25, 2023 at 6:28 AM Soni L. mailto:fakedme%2b...@gmail.com>> wrote: Has anyone done any work towards tricking a TLS library into providing cryptographic primitives? We know of similar work with regards to javacard https://arxiv.org/abs/1810.01662 but not sure if it can be applied to 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] Tricking TLS library into crypto primitives library
Python doesn't expose raw AES, etc. But it does expose a fairly rich TLS library. Wondering if it would be possible to just connect a TLS socket to a raw TCP socket and somehow write bytes into TLS and get ciphertext out or write bytes into the raw TCP socket and get plaintext out. The point is to use AES for non-TLS protocols. On 6/25/23 14:15, Eric Rescorla wrote: I'm not aware of any. Why would you want to do this? Most such libraries I am aware of expose low-level primitives or are built on libraries which do. -Ekr On Sun, Jun 25, 2023 at 6:28 AM Soni L. <mailto:fakedme%2b...@gmail.com>> wrote: Has anyone done any work towards tricking a TLS library into providing cryptographic primitives? We know of similar work with regards to javacard https://arxiv.org/abs/1810.01662 but not sure if it can be applied to 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
[TLS] Tricking TLS library into crypto primitives library
Has anyone done any work towards tricking a TLS library into providing cryptographic primitives? We know of similar work with regards to javacard https://arxiv.org/abs/1810.01662 but not sure if it can be applied to TLS. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Re: Servers sending CA names
So like a "client" cert is just a way to say "yes I'm really example.org" yeah? That seems particularly useful for federated networks (XMPP, etc). Why not call these server-to-server certs? On 4/18/23 20:45, Peter Gutmann wrote: Richard Barnes writes: >Let's Encrypt issues roughly 3 million publicly trusted certificates per day >that contain the client authentication EKU But they just set that by default for every cert they issue so it's pretty much meaningless. There are public CAs that set keyAgreement for RSA certs, and emailProtection for TLS server certs, doesn't mean any of them ever get used for that. (My more snarky response would have been that I should have asked that the IETF define a peaceOnEarth EKU so Let's Encrypt could set that as well :-). Peter. ___ 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] E164 in X509
Hello, Is there a possibility to support E164 in X509, for DTLS over SMS? Thanks. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Upgrading TLS session resumption from TLS 1.2 to TLS 1.3?
Ah, okay. That's unfortunate, tho, resumption upgrades would be useful with TLS-SRP, to get the benefits TLS 1.3 brings without having to update login details. Thanks tho. On 2021-06-24 12:11 p.m., David Benjamin wrote: > No, resumption should happen after version negotiation, and be > declined if inconsistent. The way it works is: > > 1. Suppose the client previously connected to the server and received > a TLS 1.2 session. It connects again. The client supports TLS 1.2 and > 1.3, but doesn't know a priori whether the server now supports TLS 1.3 > server. So, as always, it sends a ClientHello good for either version. > That means, it has TLS 1.3 extensions like supported_versions and > key_shares. It probably also has TLS 1.2 extensions like > ec_point_formats. And it has the TLS 1.2 session identifier, either in > the session_id field or in the session_ticket extension. > > 2. The server negotiates the TLS version before anything else: > > 2a. If the server only supports TLS 1.2, it negotiates that and > resumes the TLS 1.2 session, as usual. This is important because it > allows clients to enable TLS 1.3 without regressing existing TLS 1.2 > servers. (Of course, TLS 1.2 resumption has weaker privacy and > security properties than TLS 1.3 resumption, so the client > /may/ eventually choose to reduce or remove TLS 1.2 resumption, but > that's a separate decision from enabling TLS 1.3.) > > 2b. If the server supports TLS 1.3, it negotiates that. Sessions are > not resumed across versions and TLS 1.3 doesn't even use the same > ClientHello fields for session identifiers, so the server ignores it > and does a full handshake. This new connection will likely issue a new > TLS 1.3 session to the client. That should replace the TLS 1.2 session > in the client's session cache, so the next connection will resume at > TLS 1.3. > > This is generally the pattern with resumption. The client offers > everything it is okay with: the session, older versions, and newer > versions. The server evaluates its preferences and then only resumes > if the session is consistent with them. > > David > > On Thu, Jun 24, 2021 at 8:50 AM Soni L. <mailto:fakedme%2b...@gmail.com>> wrote: > > What's the story on backwards compatibility between TLS 1.2 session > resumption and TLS 1.3 session resumption? Appendix D. Backward > Compatibility doesn't seem to say anything about it. It seems like TLS > 1.2 session resumption is gonna keep using TLS 1.2 even if both sides > support TLS 1.3? > > ___ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Upgrading TLS session resumption from TLS 1.2 to TLS 1.3?
What's the story on backwards compatibility between TLS 1.2 session resumption and TLS 1.3 session resumption? Appendix D. Backward Compatibility doesn't seem to say anything about it. It seems like TLS 1.2 session resumption is gonna keep using TLS 1.2 even if both sides support TLS 1.3? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
