[Cryptography] Revocation is Authorization, not Authentication.

[Phillip Hallam-Baker]

Forgive me if I was being slow. But it just occurred to me that revocation
is not an authentication process, it is always an authorization process.
And this is a critical distinction.

I came across this in the design of the Mesh presentation binding. The
purpose of which is to enable both parties in a session to (1) decrypt the
data sent by the other and (2) verify that it is authentic.

One particular little twiddle here is that I want to be able to use the
presentation layer over UDP and so I would like connection packets to fit
inside the Ethernet MTA of 1200 bytes.

Every Mesh device has a separate identity. So there are always two sets of
credentials that are required.

1) The public credential of the device
2) The public credential of the profile under which it is acting.

We might have revocation of either credential. But here was the epiphany:

We don't need to check that a credential is valid to use it to
decrypt/authenticate the message. We only need to check it is valid as part
of the authorization. And this is especially important when we are
dealing with revoked credentials as even a revoked credential is fine for
purposes of returning a reason for rejecting the authorization.

User case: Alice loses her phone, discovers the loss and disables the
device. Mallet picks the phone up and attempts to use it to connect to
Alice's Mesh. The device connects, is told that it is compromised and
deletes all the data on the device.


The other thing I realized is that I only need to use the device level
credentials to negotiate a session. Get the secure session established
between the devices and only then exchange fat certificate chains etc and
only if needed.

So does my device credential work? Lets see, using X448 and 256 bit
fingerprints:

Profile Fingerprint 2 32 64
Device Authentication Key 1 56 56
Algorithm Id 2 8 16
Signature 1 56 56
Packaging 6 2 12
204

Thats looking pretty good. I should be able to keep the initial connection
request down to 500 bytes leaving me 700 bytes for payload. It is critical
that all the requests from the initiator fit into a single packet until the
connection is established to keep it stateless. But the responder can send
multiple packets back in response as the initiator can be stateful.

My original goal was to achieve the 'zero start' capability in TLS/1.3 but
I am sorta meh on that now. I require the client credential to be sent in
ciphertext for a start and I don't want to drop a non repudiable proof that
the client tried to connect to a service, especially not enclair!

Another reason to be meh about zero start is that the host might well
change between the first and second interactions. For example, MSP A tries
to deliver a message to MSP B. A uses discovery to get the IP address of a
service for MSP B. but that host is merely a switcher that tells A that
they really want to go talk to this other host which is the one that is
actually waiting to slurp that data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210301/0e24fa4b/attachment.htm>