Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

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 authors (the
> opposite of the intended effect).
>
> Currently, if a malware author wants to match the TLS characteristics of
> the host device, they have to do some work to characterize its TLS
> behavior.  This may be difficult, especially in the case of partial
> compromise, or for malware that targets a wide variety of hosts.  However,
> with this MUD module in place, the malware can read the TLS behavior right
> out of the MUD profile, and configure its behavior to match.
>

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 be present on the IoT device.


> Note that, except in the case of TLS termination, the proxy cannot verify
> anything about the TLS session by observing it.  Just because a connection
> appears to use a particular SNI or certificate does not prove anything
> about the actual destination.
>

Yes, it is discussed in
https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05#section-4

Cheers,
-Tiru


>
> On Thu, Sep 10, 2020 at 11:47 AM Michael Richardson 
> wrote:
>
>> On 2020-09-02 11:05 a.m., Joe Clarke (jclarke) wrote:
>> > Hello, opsawg.  This draft as underwent a number of revisions based on
>> reviews and presentations at the last few IETF meetings.  The authors feel
>> they have addressed the issues and concerns from the WG in their latest
>> posted -05 revision.  As a reminder, this document describes how to use
>> (D)TLS profile parameters with MUD to expose potential unauthorized
>> software or malware on an endpoint.
>> >
>> > To that end, this serves as a two-week call for adoption for this
>> work.  Please reply with your support and/or comments by September 16, 2020.
>>
>> I have read the document in a number of different revisions, and I
>> support adoption.
>>
>> I have been concerned that this document codifies a kind of TLS snooping
>> by middle boxes which has in the past caused significant harm to
>> development of TLS. (In particular, TLS version negotiation has had to
>> evade existing middle box policies!)
>>
>> However,  this document seems to walk the fine line between causing
>> protocol ossification and providing real security.  To the extent that
>> it reduces the pressure by enterprises to invade the TLS encryption
>> envelope through use of Enterprise certificates [is there a term for the
>> activity describe in section 4.1? I wish there was] this document is a
>> very useful thing.
>>
>> I would like to suggest that upon adoption, that this document go
>> through a TLS WG review of some sort before OPSAWG does a WGLC.
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> OPSAWG mailing list
> ops...@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[Nick Lamb]

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 be present on the IoT device.

RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and
over LLDP without - so far as I was able to see - any mechanism by which
it should be meaningfully "encrypted" as to prevent an attacker on your
network from reading it.

Nick.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

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 provides the attacker with
> > guidance on what vulnerabilities may be present on the IoT device.
>
> RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and
> over LLDP without - so far as I was able to see - any mechanism by which
> it should be meaningfully "encrypted" as to prevent an attacker on your
> network from reading it.
>

RFC 8520 allows other means (see sections 1.5 and 1.8) like 802.1X (for
example, TEAP (it does not allow TLS cipher suites without encryption).
The client identity (certificate carrying the MUD URL) is encrypted and not
visible to eavesdroppers. Further, RFC8520 discusses IoT devices may not
even omit the URL. It recommends to use a proxy to retrieve the MUD file
for privacy reasons.

-Tiru


>
> Nick.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Static DH timing attack

[Salz, Rich]

>   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

Re: [TLS] TLS ECH, how much can the hint stick out?

[Salz, Rich]

  *   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 
want deployable confidentiality, and “don’t stick out” is something we believe 
is a necessary requirement to be deployable.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS ECH, how much can the hint stick out?

[Blumenthal, Uri - 0553 - MITLL]

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 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 
> want deployable confidentiality, and “don’t stick out” is something we 
> believe is a necessary requirement to be deployable.
>  
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS ECH, how much can the hint stick out?

[Karthik Bhargavan]

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 ServerHello ALWAYS echoes the ECH extension, whether it chooses the inner 
or outer ClientHello.
- This ServerHello extension contains an HMAC  of (say) an empty bytestring (or 
the current transcript)
   with a key derived from the chosen handshake secret (i.e. either using the 
innerCH or outerCH),
- On receiving the ServerHello, the client generates both possible handshake 
secrets and both
  possible HMAC keys, verifies the HMAC and uses it to choose the correct 
handshake secret.

Does the above still conflict with QUIC and open up active MitM attacks?

Best,
Karthik

> On 8 Sep 2020, at 17:19, Christian Huitema  wrote:
> 
> The ECH proposal for Encrypted SNI is almost ready, but for a very small
> debate. The original proposal was using trial description to distinguish
> between ECH aware responses to the encrypted inner Client-Hello from non
> ECH aware response to the "cover" outer CH. This is problematic in the
> QUIC use case. The latest proposal is to embed a "hint" in 8 bytes of
> the Server Random. The proposal was for ECH-aware servers to use eight
> bytes of a hash of the inner Client Random as a hint. Analysis shows
> that this enables two attacks:
> 
> 1) If the Client Hello is replayed, the same hint will be present in the
> response to the original CH and to the response to the copy, providing
> observers with a clear indication that ECH was used.
> 
> 2) If the Client Hello is intercepted by an MITM attacker, the attacker
> can rewrite the server's response before presenting it to the client.
> The attacker formats its own Server Hello that reuses the Server Random
> from the original server response, but use its own key share, etc. The
> hint will cause the ECH aware client to create an handshake key using
> the inner CH. In a QUIC set up, the MITM attacker can easily detect
> that, before even transmitting the server's certificate. Thus, the MITM
> attacker can detect usage of ECH.
> 
> We have a simple proposal that solves the replay attack: set the hint as
> a hash of both the inner Client Random and the "non-hint" bytes of the
> Server Random. That's clearly a good idea, but it does not solve the
> active MITM attack. Solving that requires tying the hint with the
> handshake key derived by the original server, for example by hashing the
> inner Client Random, the "non-hint" bytes of the Server Random, and the
> server key share. That's harder to implement, so the question is about
> cost and opportunity.
> 
> This all relates to how much ECH is "sticking out". The current stance
> is that a passive attacker cannot distinguish between a client using ECH
> to access a hidden SNI and a client merely greasing the ECH extension.
> The observation is that there may be many potential active attacks,
> especially if the server shares its ESNI/ECH configuration publicly. If
> there are many such attacks, and if defense of the hint against MITM is
> hard to implement, implementing the defense might make the code more
> fragile, with little actual gain. But I am not convinced by that
> argument, because it smells a lot like "the other side of the boat is
> leaking too, why should I plug this particular leak?"
> 
> And so, at Chris Wood's request, I am sending this message to the list.
> 
> -- Christian Huitema
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Static DH timing attack

[Russ Housley]

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 25519 and only used ECDSA for signatures).
> 
> What I'm specifically referring to is DH run sideways, as someone put it
> during the X9.42 discussion, i.e. used in static-ephemeral mode to try and
> make it work like it's RSA.
> 
> In all the code audits I've done of 25519 used that way, I've never seen it
> used correctly.  Usually there isn't just one mistake made but many of them.
> It's such an obvious problem that that and misuse of RC4-equivalent modes/
> algorithms like GCM and ChaCha20 are the first things I look for in crypto
> code.

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.  Then, the ephemeral DH key pair is 
generated using the parameters from the certificate.  One important aspect of 
this approach was to avoid picking a single group for all of the DH keys.

Russ

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Static DH timing attack

[Filippo Valsorda]

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, because it's unnecessary and has been a requirement for many attacks 
now.
 * Non-ephemeral ECDH ciphersuites (TLS_ECDH_*) ought to be a SHOULD NOT, 
because again ECDH share reuse enables a whole class of attacks.
 * FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DHE_*) ought to be a SHOULD NOT, 
because they are specified in a dangerous way that is not secure if shares are 
reused.
If any of the above are not already the case, it should be a quick and easy 
document.

2020-09-11 16:06 GMT+02:00 Russ Housley :
> 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 25519 and only used ECDSA for signatures).
> > 
> > What I'm specifically referring to is DH run sideways, as someone put it
> > during the X9.42 discussion, i.e. used in static-ephemeral mode to try and
> > make it work like it's RSA.
> > 
> > In all the code audits I've done of 25519 used that way, I've never seen it
> > used correctly.  Usually there isn't just one mistake made but many of them.
> > It's such an obvious problem that that and misuse of RC4-equivalent modes/
> > algorithms like GCM and ChaCha20 are the first things I look for in crypto
> > code.
> 
> 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.  Then, the ephemeral DH key pair is 
> generated using the parameters from the certificate.  One important aspect of 
> this approach was to avoid picking a single group for all of the DH keys.
> 
> Russ
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS ECH, how much can the hint stick out?

[Karthik Bhargavan]

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 gather the consensus is that we should try to obtain (2) at least until ECH 
support becomes ubiquitous on the server side?
Since TLS 1.3 moves all but a few SH extensions to EE, I suppose there isn’t 
any other extension to hide this signal in.

In that case, I guess using a value derived from the handshake key as part of 
the ServerRandom should probably work.
That is, when constructing the ServerHello:

- first set the first N bytes of the server random to 0
- compute the hanshake secret (based on either the inner or outer CH)
- compute the signal of N bytes as
  signal = HKDF-Expand-Label(handshake secret, “s hs hmac”, 
Transcript-Hash(ClientHello..ServerHello), N)
- replace the first N bytes of the server random with signal

This is a somewhat icky design, but I think we should be able to justify it for 
(say) N <= 16 bytes.



> On 11 Sep 2020, at 16:08, Ben Schwartz  wrote:
> 
> Karthik: That approach works, but unless the ECH echo is universally 
> deployed, it still reveals to a passive observer whether the server is 
> ECH-enabled.  That means, at least for several years, exchanges that are 
> using ECH will likely "stick out" to a passive 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 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 ServerHello ALWAYS echoes the ECH extension, whether it chooses the 
> inner or outer ClientHello.
> - This ServerHello extension contains an HMAC  of (say) an empty bytestring 
> (or the current transcript)
>with a key derived from the chosen handshake secret (i.e. either using the 
> innerCH or outerCH),
> - On receiving the ServerHello, the client generates both possible handshake 
> secrets and both
>   possible HMAC keys, verifies the HMAC and uses it to choose the correct 
> handshake secret.
> 
> Does the above still conflict with QUIC and open up active MitM attacks?
> 
> Best,
> Karthik
> 
> > On 8 Sep 2020, at 17:19, Christian Huitema  > > wrote:
> > 
> > The ECH proposal for Encrypted SNI is almost ready, but for a very small
> > debate. The original proposal was using trial description to distinguish
> > between ECH aware responses to the encrypted inner Client-Hello from non
> > ECH aware response to the "cover" outer CH. This is problematic in the
> > QUIC use case. The latest proposal is to embed a "hint" in 8 bytes of
> > the Server Random. The proposal was for ECH-aware servers to use eight
> > bytes of a hash of the inner Client Random as a hint. Analysis shows
> > that this enables two attacks:
> > 
> > 1) If the Client Hello is replayed, the same hint will be present in the
> > response to the original CH and to the response to the copy, providing
> > observers with a clear indication that ECH was used.
> > 
> > 2) If the Client Hello is intercepted by an MITM attacker, the attacker
> > can rewrite the server's response before presenting it to the client.
> > The attacker formats its own Server Hello that reuses the Server Random
> > from the original server response, but use its own key share, etc. The
> > hint will cause the ECH aware client to create an handshake key using
> > the inner CH. In a QUIC set up, the MITM attacker can easily detect
> > that, before even transmitting the server's certificate. Thus, the MITM
> > attacker can detect usage of ECH.
> > 
> > We have a simple proposal that solves the replay attack: set the hint as
> > a hash of both the inner Client Random and the "non-hint" bytes of the
> > Server Random. That's clearly a good idea, but it does not solve the
> > active MITM attack. Solving that requires tying the hint with the
> > handshake key derived by the original server, for example by hashing the
> > inner Client Random, the "non-hint" bytes of the Server Random, and the
> > server key share. That's harder to implement, so the question is about
> > cost and opportunity.
> > 
> > This all relates to how much ECH is "sticking out". The current stance
> > is that a passive attacker cannot distinguish between a client using ECH
> > to access a hidden SNI and a client merely greasing the ECH extension.
> > The observation is that there may be many potential active attacks,
> > especially if the server shares its ESNI/ECH configuration publicly. If
> > there are many such attacks, and if defense of the hint against MITM is
> > hard

Re: [TLS] TLS ECH, how much can the hint stick out?

[Christian Huitema]

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 from learning whether the server
> supports ECH at all.
>
> I gather the consensus is that we should try to obtain (2) at least
> until ECH support becomes ubiquitous on the server side?
> Since TLS 1.3 moves all but a few SH extensions to EE, I suppose there
> isn’t any other extension to hide this signal in.
>
> In that case, I guess using a value derived from the handshake key as
> part of the ServerRandom should probably work.
> That is, when constructing the ServerHello:
>
> - first set the first N bytes of the server random to 0
> - compute the hanshake secret (based on either the inner or outer CH)
> - compute the signal of N bytes as
>   signal = HKDF-Expand-Label(handshake secret, “s hs hmac”,
> Transcript-Hash(ClientHello..ServerHello), N)
> - replace the first N bytes of the server random with signal
>
> This is a somewhat icky design, but I think we should be able to
> justify it for (say) N <= 16 bytes.

I like that design a lot. It is more robust than my proposal to mix the
key share in the hint.

In other words, makes the hint dependent on the actual handshake secret.
That's pretty much what I was aiming for when asking to make the hash
dependent on the key components of the handshake secret. I was concerned
with a potential circular dependency between the secret, the hint and
the server random, which is why I was looking at mixing various elements
in the hash that computes the hint. But Karthik is of course right, the
handshake secret itself does not depend on the transcript; that
dependency is only introduced when the label is derived.

Any big issue keeping N=8?

-- Christian Huitema

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Static DH timing attack

[Peter Gutmann]

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 be a MUST NOT in all
>   TLS versions, because it's unnecessary and has been a requirement for 
> many
>   attacks now.
>
>   Non-ephemeral ECDH ciphersuites (TLS_ECDH_*) ought to be a SHOULD NOT,
>   because again ECDH share reuse enables a whole class of attacks.
>
>   FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DHE_*) ought to be a SHOULD NOT,
>   because they are specified in a dangerous way that is not secure if 
> shares
>   are reused.

I agree with the first two but not the last.  Why is non-ephemeral DH a MUST
NOT but non-ephemeral ECDH a SHOULD NOT?  There's nothing magic about the EC
form that makes it any better or safer.

And for the FFDHE ciphersuites, they're not specified in a dangerous way,
people implement them in a dangerous way.  You really have to go out of your
way to get it wrong, in the case of RACCOON it's actually more effort to get
it wrong (keep old copies of values floating around and reuse them over and
over) than to get it right (generate a fresh value every time).  So it doesn't
need a "don't do FFDHE", it needs a "here's a lot of stupid things you can do
with FFDHE if you put your mind to it.  Don't do any of them".

Or maybe it can be turned into a more general "here are some dumb things that
people have done with TLS over the years.  Check your server to make sure
you're not doing them".  Posting your web server's private key as a .p12 file
in a subdirectory below $DocumentRoot, for example, would be high on my list.

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Static DH timing attack

[Peter Gutmann]

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 making it quack like RSA, with a certified static public key.  That's
exactly the point I was making about running DH sideways, taking a key
agreement mechanism and beating it into a form where it worked more like RSA
key transport.

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls