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

[Karthik Bhargavan]

> 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 some 
other concern? 
8 bytes seems fine for these considerations. Is the idea that we would reuse 
the downgrade sentinel?

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

Re: [TLS] Static DH timing attack

[Filippo Valsorda]

2020-09-12 05:48 GMT+02:00 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.

Non-ephemeral DH is affected by the Raccoon attack, ECDH is not.

> 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.

There are two peers involved in ciphersuite selection, so recommending everyone 
avoids an unsafe ciphersuite can protect connections even if only one side 
takes the advice, and even if it's not the side that made the implementation 
error.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On Sat, Sep 12, 2020, at 21:55, Karthik Bhargavan wrote:
> > 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 some other concern? 
> 8 bytes seems fine for these considerations. Is the idea that we would 
> reuse the downgrade sentinel?

If they collide, you could test with trial decryption, but 8 bytes seems like 
it might be enough that you might choose not to bother.

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

[TLS] Sabotage?

[Michael D'Errico]

Hi,

I get a weird feeling that the internet is being hijacked and soon it 
will be impossible to reverse course.  I have not followed the 
development of TLS 1.3 but it seems very different from TLS 1.2. Also 
TLS 1.2 is very different from TLS 1.0/1.1 (which are being 
deprecated).  QUIC looked good at a glance, but it seems to rely on TLS 
to share key material, and also I'm more than a bit concerned about its 
capability to track users.


Then there's Zoom video conferencing, where everybody working from home 
or in virtual school has an audio and video feed streaming to their 
servers.  Github is owned by Microsoft with some dire consequences.  
Lots of large companies trying to be everything to everyone, and it 
turns out they're cruel.


Anyone?

Mike

___
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]

> 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.

I would like to return to this point, after some discussion with Chris Wood, 
who points out that anybody can query a server to see if it supports ECH.

So, hiding whether a server supports ECH or not (which I called level 2) is a 
significantly higher bar than hiding whether a particular connection is using 
ECH or not (level 1).
I would like to understand how the WG feels about this requirement and that 
there is consensus that we need (2) and not just (1).

If we only need (1) then using a ServerHello ECH extension feels more 
principled 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 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.o

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

[Christian Huitema]

The ServerHello ECH extension approach has lots of good properties, but
also one big risk. What if a server decides that ECH is not needed for
this connection, and does not send the extension at all? The connection
will work just fine, because for the client absence of the extension
implies "using the outer CH". Implementation laziness could easily lead
to a state in which only the ECH-using connections use the ECH
extensions in the Server Hello. That would fail both (1) and (2).

-- Christian Huitema


On 9/12/2020 9:59 AM, Karthik Bhargavan 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.
>
> I would like to return to this point, after some discussion with Chris
> Wood, who points out that anybody can query a server to see if it
> supports ECH.
>
> So, hiding whether a server supports ECH or not (which I called level
> 2) is a significantly higher bar than hiding whether a particular
> connection is using ECH or not (level 1).
> I would like to understand how the WG feels about this requirement and
> that there is consensus that we need (2) and not just (1).
>
> If we only need (1) then using a ServerHello ECH extension feels more
> principled 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
>> > > 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 an

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

[Christopher Patton]

I agree with Christian. The reason to use the ServerHello.random trick is
to make real ECH connections look like connections in which the client
sends a dummy ECH extension to a non-ECH server. In particular, this design
pattern is needed for property (1).

Property (2) is achievable if the ECH configuration is secret, i.e., if the
server is deployed in such a way that it does not reveal it speaks ECH
unless the client offers the right configuration. In particular, the server
need not publish the ECH config, either via DNS or the ECH retry logic.
This won't be feasible for the vast majority of deployments.

As I said above, I think ECH should support use cases for which keeping the
configuration secret is feasible. The trial decryption mechanism might
provide this already, but overall the trial HMAC approach is a much better
design. It would be useful if someone from QUICville could chime in on how
painful it would be to implement. (It doesn't seem that bad for vanilla
TLS.)

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

Re: [TLS] Sabotage?

[Kathleen Moriarty]

Hi Mike,

This is a pretty big topic that’s been explored quite a bit.  The long term 
impact of these changes could be very positive.  I just published a book on the 
topic of embracing E2E among other topics after exploring the impact on 
operators in RFC8404.  In other words, both directions were explored to reach a 
possible way forward with increased security and how to get the 
control/visibility in order to embrace these changes.  

I’m happy to talk more, but fear the length of a thread on this list and may 
not keep up with it given my current workload.

Best regards,
Kathleen 

Sent from my mobile device

> On Sep 12, 2020, at 11:07 AM, Michael D'Errico  wrote:
> 
> Hi,
> 
> I get a weird feeling that the internet is being hijacked and soon it will be 
> impossible to reverse course.  I have not followed the development of TLS 1.3 
> but it seems very different from TLS 1.2. Also TLS 1.2 is very different from 
> TLS 1.0/1.1 (which are being deprecated).  QUIC looked good at a glance, but 
> it seems to rely on TLS to share key material, and also I'm more than a bit 
> concerned about its capability to track users.
> 
> Then there's Zoom video conferencing, where everybody working from home or in 
> virtual school has an audio and video feed streaming to their servers.  
> Github is owned by Microsoft with some dire consequences.  Lots of large 
> companies trying to be everything to everyone, and it turns out they're cruel.
> 
> Anyone?
> 
> Mike
> 
> ___
> 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