Re: [kitten] Request for review of a SASL mechanism using the OPAQUE aPAKE

[Nadja von Reitzenstein Cerpnjak <[e-mail]>]

> 
>      > In fact, the only way I'd approach a security layer is as
>     "STARTTLS in
>      > a trench coat" — i.e. by using in essence TLS-PSK to bootstrap the
>      > TLS context to
>      > then use as security layer.
> 
>     I'm not sure I understand.  Are you talking of TLS after SASL?
>     That is quite uncommon, it is unsafe for most SASL mechanisms
>     (I know OPAQUE can do this, but most application protocols will
>     probably not support STARTTLS after AUTH).
> 
> 
> I assumed that Nadja was suggesting TLS framed as a SASL Security Layer 
> for the OPAQUE mechanism, so the application protocol would not be doing 
> STARTTLS at all.
> 

Yes exactly, thank you Dave. And just to clarify, I am talking 
specifically about how I'd design a security layer for OPAQUE-* if I had 
to, and OPAQUE is fine with being transmitted in the clear. But my point 
from the GitHub discussion and my previous email still stands; I don't 
want to add a security layer.

> That's certainly possible, though having TLS prior to the SASL 
> negotiation has some security advantages in terms of downgrade 
> protection and confidentiality.
Yes and it makes it much easier to configure appropriate ciphers (e.g. 
only using AES on those systems that can hardware-accelerate it), allows 
multiplexing or versioning protocols thanks to ALPN, and can save 
round-trips by being able to already send data before the handshake has 
completed.
And, as you did allude to, having TLS protection prior to authentication 
hides the authid and authzid of the user logging in from eavesdroppers, 
which is certainly good for privacy. :)

It also has the advantage that protocols that can use unreliable 
datagram transports like SIP can be protected using the more appropriate 
DTLS, and that protocols that are transported over internally 
multiplexed streams, e.g. HTTP/3 that is transported over QUIC, can use 
their more specialized encryption that prevents head-of-line blocking in 
the face of packet loss.

I don't think that any of these more specialized situations are served 
well by a SASL security layer. Yes, (D)TLS has its drawbacks and it even 
has some warts, but well, à la guerre comme à la guerre.

~Nadja