[Cryptography-dev] TLS-API update

[Christopher Armstrong]

On May 3, 2014 2:59 PM, "Glyph" <glyph at twistedmatrix.com> wrote:
>
> On May 3, 2014, at 12:33 PM, Christopher Armstrong <
radix at twistedmatrix.com> wrote:
>
>> - This made ClientSession and ServerSession identical, so I merged them
into one class, “Session”.
>
>
> Woot.  This was sticking out for me.
>
>> I specifically want to call into question the existence of the “alert”
method. I think it’s too low level for the common use case, and we should
just relegate TLS alerts to an implementation detail. If necessary, we can
add some contract to verify_callback to make e.g. certain exceptions raised
translate to TLS alerts sent to the peer. Any thoughts?
>
>
> If this is a library that is designed to expose the TLS specification to
application code in a way which faithfully respects the spec's intent, then
you can't relegate "alert" to an "implementation detail"; it's a part of
the spec and therefore a part of the interface in some way.
>
> If this is a library that is designed to provide transport security
(which might also use, say, NaCl) and not particularly expose all of the
TLS specification, then it should have a layer which faithfully exposes the
TLS specification below it and then have an abstract API which might paper
over things like alerts.
>
> In either case you can't call an alert an implementation detail unless
you are trying to construct a deliberately incomplete API. ;-)

Fair call: "implementation detail" isn't the right phrase to use. However,
I emphatically do not want to faithfully respect the full flexibility of
TLS, personally. So far, I'm thinking a good acid test for whether a
feature should be included in this API is: has this ever been requested by
a user of Twisted, or, say, the ssl module? I don't *think* that's the case
for alerts, but maybe I'm wrong.

>
> And you can't just stuff it into verify_callback because alerts can be
sent later in the stream than the handshake, right?
>
>> Another thing is we need to figure out some more APIs around
certificates, like what methods “Certificate” should have, and how we
should allow the user to construct Certificates. (I need to spend some time
looking at the new Python “pem” module). Any input here will help.
>
>
> The 'pem' module is for splitting up strings in one particular format and
thus would not be a great rubric for a generalized
constructing/loading/saving API for certificates.  The thing you want to
look at is the "Certificate" object in Twisted's API, which is what pem
uses for building something that looks like an object.  Remember Twisted,
it's a library you used to work on? :-)
>
> In case I haven't been clear about this, I would very much like the stuff
in twisted/internet/_sslverify.py to align as much as possible with the API
being specified here.  First off, it would be great to get rid of as many
OpenSSL-isms as possible, and secondly, the more that our existing
implementation can be made to approximate this, the easier it should be for
Twisted to get out of the business of doing TLS at all (eventually).
>
> -g
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140503/3621e11e/attachment.html>