Hi Rich,
I think static DH, or reusing ephemerals, has always been a weak point of TLS
implementations: e.g. if you don’t validate the peer’s public value, you may
leak your (reusable) private value. In principle, if implemented correctly,
static DH can be ok if you don’t care about forward sec
Perhaps I am misunderstanding the design constraints and the following idea
has been thought of and discarded, but could we not remove trial decryption
and replace it with a trial HMAC, at the cost of adding yet more crypto.
- The outer ClientHello contains an ECH extension as usual.
- The ServerH
ve observer. This is something
> we are trying to avoid.
>
> On Fri, Sep 11, 2020 at 10:00 AM Karthik Bhargavan
> mailto:karthikeyan.bharga...@inria.fr>>
> wrote:
> Perhaps I am misunderstanding the design constraints and the following idea
> has been thought of and
> Any big issue keeping N=8
>
Regarding the length of N, I gather that the trade-off is that if it is too
short, the probability of collisions between the signal and randomly generated
server randoms becomes significant,
and so does the probability of an active MitM forging the signal. Is there
led to me.
Of course, the ServerHello.random trick should work for both, but at the cost
of implementation complexity.
-Karthik
>
> On Fri, Sep 11, 2020 at 10:00 AM Karthik Bhargavan
> mailto:karthikeyan.bharga...@inria.fr>>
> wrote:
> Perhaps I am misunderstanding the d
I support adoption.
> On 21 Nov 2019, at 06:53, Salz, Rich wrote:
>
>> I think it's a good starting point. I support adoption.
>
> Strongly agree.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
__
This is a bit of a shameless plug, but I think it is important to cite papers
that show that the use of weak hash functions for TLS signatures is actually
exploitable.
As far as I know, the last round of deprecating MD5 in TLS signatures was
triggered by the SLOTH attack:
https://www.mitls.org
We currently allow 0-RTT with Semi-static DH, with PSK resumption, and with
pure PSK.
Whether or not we keep all of these, it would be good to clean up the protocol
design
so that both the client and server have a uniform way of signaling their
preferences.
After implementing and analyzing TLS
> You mean combining the 0-RTT aspects of pre_shared_key extension with
> early_data? Because I don't think this type of structure can present what
> PSK extension presents (e.g. multiple candidate PSK identities).
Good question. For 0-RTT, multiple PSK identities make no sense,
because we can on
>
> Nit: This doesn't sound like a passive attacker to me...
>
>
> > Even if we eliminate client certificate authentication from 0-RTT, this
> > notion of “context" is still useful for two reasons:
> > (a) the application may use TokenBinding or
> +1 but I think we can go further here and specify 0RTT in such a way that it
> only works when the server maintains state, and so that any given 0RTT ticket
> may only be used once (to preserve forward secrecy as much as possible within
> the constrains of 0RTT).
Do you envision clients only
TLS 1.3 0-RTT introduces an “optimistic” mode where the client
encrypts data that the server can then accept or reject.
In the case when the server rejects 0-RTT, the server is left in a somewhat
ugly state where it will receive, in sequence:
(a) encrypted 0-RTT handshake data (that it needs to t
>
> The wire format is one thing, but there is work that has been done at a
> much higher level referencing "TLS 1.3", e.g. TRON work:
>
> http://prosecco.gforge.inria.fr/personal/karthik/pubs/
> proscript-tls-tron-2016.pdf
>
Thanks for the reference but this draft paper does not count as a
publi
13 matches
Mail list logo
