Bill,
I agree that we need to find the "least bad" option, if for no other reason
than to prove there is no acceptable solution. If I may, I'd like to suggest
another possible way to get to "least bad".
Perhaps our goal should not be to prevent servers collaborating with the
monitoring, which
As an earlier poster asked, what advantage does this approach have over
TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which I am
familiar is able to terminate at TLS connection, inspect/copy/filter, and then
encrypt on a new TLS sessions.
For high performance customers, the SSL a
+1 and a preference for MUST, just so people understand the importance.
Since we're agreed that 0-RTT data and 1-RTT data have (almost) the same
security properties once the handshake completes, it seems to me, unless I've
missed something, that a lot of protocols will accept 0-RTT but withhold
One small nit.
> ECDHE provides perfect forward secrecy
I thought we had decided to change “perfect forward secrecy” to just “forward
secrecy” since “perfect” is such a difficult standard to reach?
Tim
—
Tim Jackson | Product Security Architect | MobileIron, Inc.
On 5/18/17, 10:45 AM, "TLS on b
>The (mis)use of long-term STEKs is not particularly special among such
> practices.
This may be true, but that still doesn’t make it a good idea. We should
probably do *something* about this. J
>The protocol design should avoid setting traps for the unwary.
>If libraries implem
I have a question on RFC5246 (TLS 1.2) and how it’s going to interact with
RSASSA-PSS as we roll out TLS 1.3. Does the prohibition against RSASSA-PSS
apply only to the signatures that can be used for signing handshakes or does it
apply to the entire certificate chain as well? I ask because while
At this point, my personal opinion is to move on from TLS 1.3 to either TLS
4/4.0 or TLS 2017.
After 15 years, everyone but us still calls it SSL. We need to admit that we
lost the marketing battle and plan for a world where everyone calls “TLS X”
“SSL X”. Even “new” implementations call themse
We probably want to discuss the potential for side-channels introduced by
alerting. I’ve seen at least one case where there were two possible classes of
errors at a particular state in the protocol. One caused an alert, the other
caused the TLS stack to close the channel. Unfortunately, this dif
I’ve noted that many (most?) TLS implementations choose their ECDHE curves
seemingly without regard to the cipher suite strength. Thus, they'll select an
AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then
generate an ECDHE key on the P256 curve. This seems odd to me, since t
