feat(aws-kms-tls-auth): add codec and parsing #5398
Conversation
- vec with capacity - fix codec module documentation - client hello/psk parsing unit test - remove protocol - fix fuzz test ci name - remove blob new method
- update unit test name
- public export of client hello and other structs for fuzz testing
- use s2n-tls to retrieve PSK extension
| - name: run psk-identities fuzzer | ||
| run: cargo fuzz run psk_client_hello -- -max_total_time=30 |
There was a problem hiding this comment.
What's our longest CI job rn?
There was a problem hiding this comment.
I think currently ~1 hour.
| //! 1. client -> [A], server -> [A] | ||
| //! 2. client -> [A], server -> [A, B] | ||
| //! 3. client -> [A, B], server -> [A, B] | ||
| //! 4. client -> [B], server -> [A, B] | ||
| //! 5. client -> [B], server -> [B] |
There was a problem hiding this comment.
Does the client need [A,B] in this process? Couldn't it just be:
| //! 1. client -> [A], server -> [A] | |
| //! 2. client -> [A], server -> [A, B] | |
| //! 3. client -> [A, B], server -> [A, B] | |
| //! 4. client -> [B], server -> [A, B] | |
| //! 5. client -> [B], server -> [B] | |
| //! 1. client -> [A], server -> [A] | |
| //! 2. client -> [A], server -> [A, B] | |
| //! 4. client -> [B], server -> [A, B] | |
| //! 5. client -> [B], server -> [B] |
There was a problem hiding this comment.
Yes, but for most fleet owners there is no way to atomically switch all clients from A to B, so I figure it was useful from that perspective.
There was a problem hiding this comment.
But you shouldn't need atomic. From my understanding, a client will only ever use one key (nothing prompts it to choose) so it'll either use A or B, and not care about any other values in a list. So the server needs the list to handle a mixed fleet of some clients using A and some using B, but each individual client only ever uses A or B?
There was a problem hiding this comment.
So the server needs the list to handle a mixed fleet of some clients using A and some using B, but each individual client only ever uses A or B
Yup, this is totally correct.
What I wanted to communicate was
The server must continue to hold
Auntil no clients are holdingA. Only then can it be safely dropped
When someone is thinking about modelling a safe deployment of this, they absolutely must be tracking how the client change is rolling out through a pipeline. There will always be some stage during which some portion of the client are using A, and some portion of the clients are using B. During this stage the sever must hold both A and B.
There was a problem hiding this comment.
Yeah I guess my problem is that client -> [A, B] represents clients with A OR B, but server -> [A, B] represents servers with A AND B :/ You're using the same representation to mean different things
There was a problem hiding this comment.
Ya, I was going for "the client population has A AND B", but can see how that is a bit funky.
I'll switch the representation to clients -> [A] [B], server -> [A & B] as a followup
Description of changes:
This PR adds a new crate,
aws-kms-tls-auth. This will be used to provide the following two items.This PR is laying the ground work for that
Call-outs:
s2n-tls parser vs new parser: We could do some of the client hello parsing with s2n-tls, using methods like
s2n_client_hello_get_extenion_by_id. However this doesn't remove the need for all of the codec (EncodeValue,DecodeValue) traits, and we'd still have the parse the actual extension ourself. Also, adding the PSK extension to the public s2n-tls API is a one-way door, and it is a feature that most customer should not use.eventually parser stuff will be in a different crate: The entirety of
client_hello_parser,codec, andprefixed_listshould live in a different crate. In fact they already live in a different crate in one of my personal repos but we haven't gotten around to open sourcing them yet.crate home: I expect this crate to live in it's own repo under the
awslabsorg. For now I will be putting it alongside thestandardandextendedworkspaces ins2n-tls/bindings/rust/. It must be in it's own workspace because the AWS-SDK require an MSRV 1.88, which breaks our standard "6 month" MSRV promise.Testing:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.