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
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
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
> 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
* 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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
