Re: [TLS] Requiring that (EC)DHE public values be fresh

[Brian Smith]

Adam Langley  wrote:
> Since this defeats forward security, and is clearly something that
> implementations of previous versions have done, this change
> specifically calls it out as a MUST NOT. Implementations would then be
> free to detect and reject violations of this.
>
> This does have a cost because it also excludes the reasonable practice
> of amortising public value generation over all connections for a few
> seconds. The draft could attempt to specify a precise, maximum
> duration for reuse but that is more complex and no value is clearly
> optimal.

We should brainstorm the unintended negative consequences of this.

It would make self-hosting a small that can survive a spike in traffic
("slashdot effect") more difficult, thus encouraging sites to use
CDNs, which decrease the integrity, confidentiality, and privacy
properties of all connections between the client and the origin
server. Unfortunately I don't know how to quantify that.

Another unintended consequence is that it makes the PSK modes
relatively more attractive. For some very small devices doing ECDH
agreement on every connection and only doing a occasionally doing a
ECDH keygen could be at the edge of their performance/power limits,
and needing to do the ECDH keygen for every connection could easily
make using ECDH prohibitive. OTOH, we don't want these devices to use
have a fixed ECDH key burned into their ROM, or similar, either.

Another unintended consequence is that it makes resumption (formulated
as a sort of server-generated PSK in TLS 1.3) more necessary. Although
many implementations will probably implement resumption, I think there
are a lot of cases where one might prefer to avoid implementing and/or
enabling it. Also, even when it is enabled, making ECDH more expensive
relative to PSK/resumption would encourage building more complex
server software to distribute PSKs across machines. And/or the server
may choose to reuse PSKs longer. And/or the server may choose to use
the non-ECDHE form of PSK-based resumption (IIUC). Again, though, I
can't quantify the effect here.

> Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse
> values and manage fine today. The generation of (EC)DH public values
> is also a fixed-based operation and thus can be much faster than DH
> key-agreement.

According to the paper, a large majority of servers in the Alexa top
1M are reusing keys. That 14.4% number is a fraction of the 80%
servers consistently in the Alexa top 1M that use browser-trusted
certificates and that use ECDHE. IIUC, approximately 20% of servers in
the Alexa top 1M that use browser-trusted certificates are using RSA
key exchange, which means they are also reusing the same key for every
connection. Also, according to the paper, more than half of servers
aren't using TLS or aren't using browser-trusted certificates, which
means that web browser connections to them are likely using the same
NULL key.

Also, the Alexa top 1M isn't representative of every use of TLS, but
rather only one kind of application.

> Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling
> TLS connections to be decrypted and monitored by a middlebox. TLS is
> not designed to be decrypted by third-parties—that's kind of the
> point. Thus anyone doing this should not be surprised to hit a few
> MUST NOTs and, potentially, to have to configure implementations to
> allow such a deployment.

The (presumably) accidental reuse of keys for long periods of time is
bad, and this MitM idea is even worse. But, if reuse were made a MUST
NOT, wouldn't such systems just use a different, perhaps worse, more
complex, and undetectable mechanism, like the one Dan Brown suggested
in the earlier thread? I think we should assume that while we may be
able to help prevent the former accidental badness with such a rule,
such a mechanism probably isn't going to have much effect on the
latter intentional badness.

With all this in mind, absent other information. In the case of
servers hosting websites, I do think a limit of less than a minute is
reasonable. However, I think for the small device (IoT) case, the
limit should be longer, perhaps even hours.

Cheers,
Brian
-- 
https://briansmith.org/

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

Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh)

[Adam Langley]

On Thu, Dec 29, 2016 at 11:08 AM, Eric Rescorla  wrote:
>> >> As an individual, I'd be in favour of this change but reading
>> >> over [1], section 5, I wondered if we'd analysed the effects of
>> >> 0rtt/replayable-data with that kind of cross-domain re-use in mind?
>> >> The situation being where session ID based caches or session ticket
>> >> equivalents in tls1.3 are shared over multiple domains.

I think there is the following interaction:

Given two servers, S1 and S2, which are nominally s1.example.com and
s2.example.com, but which both have a *.example.com cert and share
ticket keys:

An attacker could redirect a 0-RTT handshake that was destined to S1
and feed it to S2. If S2 ignores the SNI value (common) it could
accept and process the 0-RTT data even though it was destined for S1.

However, in that case TLS 1.2 is probably also affected because S2
would likely process a 1.2 handshake that was destined to S1 as well.
(Even without a shared ticket key or session cache.) See
http://antoine.delignat-lavaud.fr/doc/www15.pdf for more.


Cheers

AGL

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

Re: [TLS] Requiring that (EC)DHE public values be fresh

[Adam Langley]

On Thu, Dec 29, 2016 at 11:28 AM, Martin Rex  wrote:
> First of all, forward secrecy is equally defeated by TLS session caching
> (traditional as well as session tickets), and the effect of rfc5077
> TLS session tickets is likely at least a magnitude worse--and cannot
> be "fixed" by clients purging the tickets earlier.

That is true in TLS 1.2, but one of the things that have been addressed in 1.3.

> Reuse of DHE values should not come as a surprise, PFS with DHE is
> prohibitively expensive with 2048+ bit ephemeral keys.  DHE in TLS has
> been well known to be fatally flawed (publicly known since the issue
> was raised by Yngve on the TLS ietf mailing list in 2007).
>   https://www.ietf.org/mail-archive/web/tls/current/msg01647.html
>
> Since Sun/Oracle hardwired DHE to at most 1024 bits up to JavaSE 7,
> i.e. on Billions on devices out there, DHE in TLS is a very dead horse.

Again, true in 1.2 but 1.3 has fixed the groups to stronger values.
Also, the key-generation of DHE is significantly cheaper than the
key-agreement so ephemeral values might be more reasonable then
benchmarks suggest.

As noted, I think specifying a maximum caching duration is plausible.
(Google servers cache QUIC X25519 values for 60-seconds, for example.)
But I'm worried about an endless discussion about how long is too long
(or long enough).

> Now what does it mean when a _client_ that happens to connect to one
> of these 14.4% Alexa top 1M sites that reuse ECDHE values, notices a
> reuse of ECDHE on a repeated full handshake (which will not happen
> immediately due to session caching).  This would result
> is random handshake failures (client aborting the TLS handshake).
> The server doesn't know why the client chokes, only the client can
> decided to retry, but this is unlikely to affect the servers approach
> to reusing the (EC)DHE value at all.

The idea is to establish this in clients early in the life of 1.3 so
that the pressure is enough to keep the ecosystem clean. I don't think
that enforcing it in versions prior to 1.3 is viable.


Cheers

AGL

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

Re: [TLS] Requiring that (EC)DHE public values be fresh

[Martin Rex]

Adam Langley wrote:
>
> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that
> specifies that (EC)DH values must be fresh for both parties in TLS
> 1.3.
> 
> For clients, this is standard practice (as far as I'm aware) so should
> make no difference. For servers, this is not always the case:
> 
> Springall, Durumeric & Halderman note[1] that with TLS 1.2:
>   ? 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more
> than a day.
>   ? 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.
> 
> Since this defeats forward security, and is clearly something that
> implementations of previous versions have done, this change
> specifically calls it out as a MUST NOT. Implementations would then be
> free to detect and reject violations of this.

While you may have good intentions, the idea "and reject violations of this"
sounds like a bad idea to me.

First of all, forward secrecy is equally defeated by TLS session caching
(traditional as well as session tickets), and the effect of rfc5077
TLS session tickets is likely at least a magnitude worse--and cannot
be "fixed" by clients purging the tickets earlier.

Reuse of DHE values should not come as a surprise, PFS with DHE is
prohibitively expensive with 2048+ bit ephemeral keys.  DHE in TLS has
been well known to be fatally flawed (publicly known since the issue
was raised by Yngve on the TLS ietf mailing list in 2007).
  https://www.ietf.org/mail-archive/web/tls/current/msg01647.html

Since Sun/Oracle hardwired DHE to at most 1024 bits up to JavaSE 7,
i.e. on Billions on devices out there, DHE in TLS is a very dead horse.


Ephemeral ECDHE values should be much less painful performance-wise,
but may happen to accidentally share the same properties as DHE values.
Potentially, the (EC)DHE keypairs are (mis-)managed above the TLS stack,
instead of entirely within--in which case this would not be the fault of the
TLS implementation code, but of the TLS implementation API (design).


Now what does it mean when a _client_ that happens to connect to one
of these 14.4% Alexa top 1M sites that reuse ECDHE values, notices a
reuse of ECDHE on a repeated full handshake (which will not happen
immediately due to session caching).  This would result
is random handshake failures (client aborting the TLS handshake).
The server doesn't know why the client chokes, only the client can
decided to retry, but this is unlikely to affect the servers approach
to reusing the (EC)DHE value at all.


So the only thing this will cause is headaches to users and support
folks.  It will *NOT* improve the security by one iota.
 

If you want to improve something, then specify how to obtain the
desired behaviour, not how to panic and choke.



-Martin

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

Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh)

[Eric Rescorla]

On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell  wrote:

>
>
> On 29/12/16 18:38, Eric Rescorla wrote:
> > On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie
> >> wrote:
> >
> >>
> >> Hiya,
> >>
> >> On 29/12/16 17:37, Adam Langley wrote:
> >>> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that
> >>> specifies that (EC)DH values must be fresh for both parties in TLS
> >>> 1.3.
> >>>
> >>> For clients, this is standard practice (as far as I'm aware) so should
> >>> make no difference. For servers, this is not always the case:
> >>>
> >>> Springall, Durumeric & Halderman note[1] that with TLS 1.2:
> >>>   ∙ 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more
> >>> than a day.
> >>>   ∙ 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.
> >> ...
> >>
> >> As an individual, I'd be in favour of this change but reading
> >> over [1], section 5, I wondered if we'd analysed the effects of
> >> 0rtt/replayable-data with that kind of cross-domain re-use in mind?
> >> The situation being where session ID based caches or session ticket
> >> equivalents in tls1.3 are shared over multiple domains.
> >>
> >> I don't recall this being explicitly considered, but maybe that's
> >> just me forgetting. And hopefully the analysis is that such re-use
> >> doesn't enable broader replay of early data, but there may be
> >> something worth a mention in the tls1.3 spec, e.g. that there may
> >> be linkages between the duration for which entries are maintained
> >> in resumption and replay detection caches.
> >>
> >
> > This question seems essentially orthogonal to the question of ECDHE key
> > reuse
> > because even if you use the same ECDHE key in perpetuity you get unique
> > traffic keying material for each connection.
>
> Fair enough, I probably should've started a new thread so have
> done that now.
>

Currently TLS 1.3 forbids *both* 0-RTT and resumption if the SNI changes:
https://tlswg.github.io/tls13-spec/#NewSessionTicket

"Any ticket MUST only be resumed with a cipher suite that has the same KDF
hash as that used to establish the original connection, and only if the
client provides the same SNI value as in the original connection, as
described in Section 3 of [RFC6066]
."

We have discussed relaxing that restriction, specifically to allow the
following case:

- Client connects to server with SNI=A and the server supplies a cert with
SNI=A, B
- Client reconnects to server and tries to resume with SNI=B

See PR: https://github.com/tlswg/tls13-spec/pull/777.

However, the general consensus was to leave this out of the base spec,
though we
might supply an enhancement for that later (and potentially slightly soften
the above
language to foreshadow such an enhancement).

-Ekr



> S
>
> >
> > -Ekr
> >
> >
> >> Cheers,
> >> S.
> >>
> >>>
> >>> [1] “Measuring the Security Harm of TLS Crypto Shortcuts”, IMC 2016,
> >>> pages 33–47, section 4.4. https://dl.acm.org/citation.cfm?id=2987480
> >>> [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh-
> in-tls13/
> >>>
> >>>
> >>> Cheers
> >>>
> >>> AGL
> >>>
> >>
> >>
> >> ___
> >> 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

[TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh)

[Stephen Farrell]

On 29/12/16 18:38, Eric Rescorla wrote:
> On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell > wrote:
> 
>>
>> Hiya,
>>
>> On 29/12/16 17:37, Adam Langley wrote:
>>> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that
>>> specifies that (EC)DH values must be fresh for both parties in TLS
>>> 1.3.
>>>
>>> For clients, this is standard practice (as far as I'm aware) so should
>>> make no difference. For servers, this is not always the case:
>>>
>>> Springall, Durumeric & Halderman note[1] that with TLS 1.2:
>>>   ∙ 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more
>>> than a day.
>>>   ∙ 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.
>> ...
>>
>> As an individual, I'd be in favour of this change but reading
>> over [1], section 5, I wondered if we'd analysed the effects of
>> 0rtt/replayable-data with that kind of cross-domain re-use in mind?
>> The situation being where session ID based caches or session ticket
>> equivalents in tls1.3 are shared over multiple domains.
>>
>> I don't recall this being explicitly considered, but maybe that's
>> just me forgetting. And hopefully the analysis is that such re-use
>> doesn't enable broader replay of early data, but there may be
>> something worth a mention in the tls1.3 spec, e.g. that there may
>> be linkages between the duration for which entries are maintained
>> in resumption and replay detection caches.
>>
> 
> This question seems essentially orthogonal to the question of ECDHE key
> reuse
> because even if you use the same ECDHE key in perpetuity you get unique
> traffic keying material for each connection.

Fair enough, I probably should've started a new thread so have
done that now.

S

> 
> -Ekr
> 
> 
>> Cheers,
>> S.
>>
>>>
>>> [1] “Measuring the Security Harm of TLS Crypto Shortcuts”, IMC 2016,
>>> pages 33–47, section 4.4. https://dl.acm.org/citation.cfm?id=2987480
>>> [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/
>>>
>>>
>>> Cheers
>>>
>>> AGL
>>>
>>
>>
>> ___
>> 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] Requiring that (EC)DHE public values be fresh

[Eric Rescorla]

On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell  wrote:

>
> Hiya,
>
> On 29/12/16 17:37, Adam Langley wrote:
> > https://github.com/tlswg/tls13-spec/pull/840 is a pull request that
> > specifies that (EC)DH values must be fresh for both parties in TLS
> > 1.3.
> >
> > For clients, this is standard practice (as far as I'm aware) so should
> > make no difference. For servers, this is not always the case:
> >
> > Springall, Durumeric & Halderman note[1] that with TLS 1.2:
> >   ∙ 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more
> > than a day.
> >   ∙ 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.
> ...
>
> As an individual, I'd be in favour of this change but reading
> over [1], section 5, I wondered if we'd analysed the effects of
> 0rtt/replayable-data with that kind of cross-domain re-use in mind?
> The situation being where session ID based caches or session ticket
> equivalents in tls1.3 are shared over multiple domains.
>
> I don't recall this being explicitly considered, but maybe that's
> just me forgetting. And hopefully the analysis is that such re-use
> doesn't enable broader replay of early data, but there may be
> something worth a mention in the tls1.3 spec, e.g. that there may
> be linkages between the duration for which entries are maintained
> in resumption and replay detection caches.
>

This question seems essentially orthogonal to the question of ECDHE key
reuse
because even if you use the same ECDHE key in perpetuity you get unique
traffic keying material for each connection.

-Ekr


> Cheers,
> S.
>
> >
> > [1] “Measuring the Security Harm of TLS Crypto Shortcuts”, IMC 2016,
> > pages 33–47, section 4.4. https://dl.acm.org/citation.cfm?id=2987480
> > [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/
> >
> >
> > Cheers
> >
> > AGL
> >
>
>
> ___
> 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

[TLS] Requiring that (EC)DHE public values be fresh

[Adam Langley]

https://github.com/tlswg/tls13-spec/pull/840 is a pull request that
specifies that (EC)DH values must be fresh for both parties in TLS
1.3.

For clients, this is standard practice (as far as I'm aware) so should
make no difference. For servers, this is not always the case:

Springall, Durumeric & Halderman note[1] that with TLS 1.2:
  ∙ 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more
than a day.
  ∙ 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.

Since this defeats forward security, and is clearly something that
implementations of previous versions have done, this change
specifically calls it out as a MUST NOT. Implementations would then be
free to detect and reject violations of this.

This does have a cost because it also excludes the reasonable practice
of amortising public value generation over all connections for a few
seconds. The draft could attempt to specify a precise, maximum
duration for reuse but that is more complex and no value is clearly
optimal.

Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse
values and manage fine today. The generation of (EC)DH public values
is also a fixed-based operation and thus can be much faster than DH
key-agreement.

Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling
TLS connections to be decrypted and monitored by a middlebox. TLS is
not designed to be decrypted by third-parties—that's kind of the
point. Thus anyone doing this should not be surprised to hit a few
MUST NOTs and, potentially, to have to configure implementations to
allow such a deployment.

[1] “Measuring the Security Harm of TLS Crypto Shortcuts”, IMC 2016,
pages 33–47, section 4.4. https://dl.acm.org/citation.cfm?id=2987480
[2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] PR#837: Forward and backward secrecy

[Guballa Jens (ETAS-PSC/ECS)]

> 
> > My understanding:
> > A compromised long term key does not compromise captured future traffic
> => forward secrecy (provided by (EC)DHE)
> 
> This is not correct.  Forward-secrecy is the below, not the above.

[JG] I did not say clearly what I meant. :-) 
For my statement I set the presence implicitly to the end of the handshake, 
sorry for the confusion.

Anyway, in principle I am in line with the definition of "Forward secret" 
in section E.1, but still I have two comments:

1.
"Forward secret
If the long-term keying material (in this case the signature keys in
certificate-based authentication modes or the external/resumption PSK in PSK
with (EC)DHE modes) are compromised after the handshake is complete, this
does not compromise the security of the session key (See [DOW92]).[...]"

- I think that "session key" is a synonym for "master secret". 
- My understanding: The master secret is a short-term secret, I think an 
implementation can delete it after the working keys have been derived,
right?

If these assumptions are correct, then I prefer something like
"..., this does not compromise the security of the master secret (see
[DOW92]) and
the derived working keys."

2.
If the term "backward secrecy" will remain in the draft, then I propose to 
either add a definition or refer to a definition of this term outside of
the draft.

> 
> > A compromised long term key does not compromise captured traffic from
> the past => backward secrecy (provided by HKDF-hash)
> 
> --
>   Viktor.
> 
> ___
> 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