Russ Housley writes:
>I am sure you know that ephemeral-static DH was original used for S/MIME. The
>reasoning for ephemeral-static DH was not to make it work like RSA. Rather,
>the idea was to provide authentication of the static DH key holder by
>certifying the static DH public key.
... thus m
Filippo Valsorda writes:
>I feel like there should be nothing controversial in the context of TLS.
>
> Non-ephemeral FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DH_*) ought to be a
> MUST NOT, because they can't be implemented securely.
>
> Reusing ephemeral shares for ECDHE and DHE ought to
On 9/11/2020 4:20 PM, Karthik Bhargavan wrote:
> Ok, in that case it is worth making the don’t “stick out” property
> more precise.
>
> 1) We can either try to prevent the attacker from learning whether ECH
> was actually used in a particular connection, or
> 2) We can try to prevent the attacker
Ok, in that case it is worth making the don’t “stick out” property more precise.
1) We can either try to prevent the attacker from learning whether ECH was
actually used in a particular connection, or
2) We can try to prevent the attacker from learning whether the server supports
ECH at all.
I
I feel like there should be nothing controversial in the context of TLS.
* Non-ephemeral FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DH_*) ought to be a
MUST NOT, because they can't be implemented securely.
* Reusing ephemeral shares for ECDHE and DHE ought to be a MUST NOT in all TLS
versions, beca
Peter:
> Achim Kraus writes:
>
>> Does using x25519 for ECDHE is significant less secure than using it with
>> e.g. secp384r1?
>
> The NIST curves AFAIK are never used that way, it's only done with 25519
> (there was something about it in an OpenPGP draft, but I think GPG went
> straight to 255
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
IMHO, Rich is 100% correct here.
If it’s not deployable (and to me it means **universally** deployable, not
merely within the US), if fails *all* of the security goals completely.
Regards,
Uri
> On Sep 11, 2020, at 09:27, Salz, Rich
> wrote:
>
>
> I think we should be careful with the wo
* I think we should be careful with the word "broken" ... here we're
talking about "don't stick out", which is a deployment consideration only. The
main security goal is confidentiality of the ClientHelloInner.
Perhaps this is just being pedantic, but I disagree with the tone of this. We
wa
> Which, given that it's such a footgun would IMHO be a good thing, but others
will probably disagree :-).
Got it, thanks.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Fri, 11 Sep 2020 at 16:11, Nick Lamb wrote:
> On Fri, 11 Sep 2020 12:32:03 +0530
> tirumal reddy wrote:
>
> > The MUD URL is encrypted and shared only with the authorized
> > components in the network. An attacker cannot read the MUD URL and
> > identify the IoT device. Otherwise, it provide
On Fri, 11 Sep 2020 12:32:03 +0530
tirumal reddy wrote:
> The MUD URL is encrypted and shared only with the authorized
> components in the network. An attacker cannot read the MUD URL and
> identify the IoT device. Otherwise, it provides the attacker with
> guidance on what vulnerabilities may b
Hi Ben,
Please see inline
On Fri, 11 Sep 2020 at 07:05, Ben Schwartz wrote:
> Thanks for highlighting this, Michael. I don't support adoption of this
> draft, because I don't think it is fit-for-purpose. Specifically, I think
> it is likely to provide a significant advantage to malware author
13 matches
Mail list logo
