Re: [TLS] Remove DH-based 0-RTT

[Karthikeyan Bhargavan]

> 
> The server signature is essentially over raw handshake messages, up
> to and including ServerCertificate. The first message that would
> depend on actual value of SS is ServerFinished, which comes after
> that point…

Yes Ilari, you’re right.

In my TRON talk, I described an attack on PSK+Signature server auth
which showed that the natural way of composing PSK + Sigs won’t work.
(And no it doesn’t work for PSK-ECDHE either.)

I think the proper way to do it is that the pre_shared_key extension
should include a ps_context value derived from the PSK. E.g for resumption,
it could include the session hash of the previous connection.
For pure PSK, it could include a MAC computed using the PSK.

It is worth noting that having such a psk_context in the client hello
would’ve prevented the attack that Cremers et al found in Tamarin as well.

Best,
Karthik


> 
> 
> -Ilari
> 
> ___
> 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] SRP ?

[Aaron Zauner]

> On 23 Feb 2016, at 16:34, Salz, Rich  wrote:
> 
> Is anyone using SRP with TLS?  The OpenSSL implementation in particular?
> 

I have been in the past and know of some installations and customers that 
actually use it.
Although the lack of modern cipher-suites for SRP makes it not very attractive 
these days.

Aaron


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SRP ?

[Rick van Rein]

Hi,

> Although the lack of modern cipher-suites for SRP makes it not very
> attractive these days.
>
Does anyone know if work on something like "ECSRP" is going on, anywhere?

We've recently worked on getting it working with PKCS #11,

https://github.com/arpa2/srp-pkcs11
https://github.com/arpa2/srp-pkcs11/blob/rfc5054_compat/doc/design/srp-pkcs11.pdf

It could be interesting to see if this translates to the Elliptic Curve
arena.

I heard rumours of alternatives being weighed against one another, but
failed to find anything concrete.  Links are quite welcome!

-Rick

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

Re: [TLS] SRP ?

[Salz, Rich]

Thanks for the feedback, everyone.  The OpenSSL SRP code is staying.

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz

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

Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-01.txt

[Benjamin Kaduk]

On 02/06/2016 02:36 PM, Yaron Sheffer wrote:
> The draft describes using an opaque ticket (similar to a session
> resumption ticket) to pin the identity of a TLS server. The new
> version addresses several comments on this list, in particular
> regarding the message syntax, and requesting a comparison with TACK -
> thanks Dave and Daniel.

I only skimmed, but a couple things stood out:

"bricking" is kind of an informal term

I usually think of "identity" as being some concrete thing that can be
named, so that when it says "identity pinning", I expected there to be
some name or similar concrete identifier.  It seems to me that what is
going on is really that this is a scheme to ensure that subsequent
communications are talking to the same entity by proof-of-possession of
a token/key exchanged on the first communication, but that token does
not contain any particular nameable entity.  It seems that rewording the
entire document in such a fashion would be pretty tedious and result in
somewhat more stilted language, though, so I'm hesitant to recommend
that course of action.

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

Re: [TLS] Remove DH-based 0-RTT

[Ilari Liusvaara]

On Wed, Feb 24, 2016 at 10:08:02AM -0800, Martin Thomson wrote:
> On 24 February 2016 at 10:00, Ilari Liusvaara  
> wrote:
> > Be careful with that: One can get server impersonation attacks unless
> > one somehow binds the SS into signature (and unlike with client sigs,
> > there is no straightforward way).
> 
> The key schedule, in every variation I've seen proposed, does that.

The server signature is essentially over raw handshake messages, up
to and including ServerCertificate. The first message that would
depend on actual value of SS is ServerFinished, which comes after
that point...


-Ilari

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

Re: [TLS] Remove DH-based 0-RTT

[Martin Thomson]

On 24 February 2016 at 10:00, Ilari Liusvaara  wrote:
> Be careful with that: One can get server impersonation attacks unless
> one somehow binds the SS into signature (and unlike with client sigs,
> there is no straightforward way).

The key schedule, in every variation I've seen proposed, does that.

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

Re: [TLS] Remove DH-based 0-RTT

[Ilari Liusvaara]

On Wed, Feb 24, 2016 at 07:54:27AM -0800, Martin Thomson wrote:

> PSK + DHE + signing

Be careful with that: One can get server impersonation attacks unless
one somehow binds the SS into signature (and unlike with client sigs,
there is no straightforward way).


-Ilari

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

Re: [TLS] Remove DH-based 0-RTT

[Watson Ladd]

On Wed, Feb 24, 2016 at 7:54 AM, Martin Thomson
 wrote:
> On 24 February 2016 at 07:44, Subodh Iyengar  wrote:
>> Unless we add a way for the client to require a server authentication during
>> PSK resumption.
>
> I have been arguing for this now for a while.  If there is an
> incentive to do "PSK resumption" (there is), and that does not provide
> the client a way to verify server certificates, then clients are
> forced to make a choice between performance and checking that the
> server holds the private key for the certificate.  I'd like to see a
> mode where 0-RTT is grafted on to a full handshake with DHE and
> signing.  Unfortunately, that gives us an almost full matrix of
> options:

Part of the motivation for session tickets in the first place was the
cost of signing and DH. So long as servers can negotiate a resumption
mode without these, and clients offer it, there is no liveness check.
And if we require a DH+sign every resumption, we don't gain anything
over the full exchange except 0-RTT. Why is this server liveness issue
not considered a problem for TLS 1.2 resumption?

>
> PSK only
> PSK + DHE
> PSK + DHE + signing
> DHE + signing
>
> But at least we can remove "DH0RTT + DHE + signing" and maybe other
> combinations (though which ones we have currently isn't 100% clear to
> me).

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

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

Re: [TLS] Remove DH-based 0-RTT

[Martin Thomson]

On 24 February 2016 at 07:44, Subodh Iyengar  wrote:
> Unless we add a way for the client to require a server authentication during
> PSK resumption.

I have been arguing for this now for a while.  If there is an
incentive to do "PSK resumption" (there is), and that does not provide
the client a way to verify server certificates, then clients are
forced to make a choice between performance and checking that the
server holds the private key for the certificate.  I'd like to see a
mode where 0-RTT is grafted on to a full handshake with DHE and
signing.  Unfortunately, that gives us an almost full matrix of
options:

PSK only
PSK + DHE
PSK + DHE + signing
DHE + signing

But at least we can remove "DH0RTT + DHE + signing" and maybe other
combinations (though which ones we have currently isn't 100% clear to
me).

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

Re: [TLS] Remove DH-based 0-RTT

[Subodh Iyengar]

Removing DH based 0-RTT would make it more important to make the lifetime of 
the ticket enforced.

One interesting difference is that DH based 0-RTT requires proof of possession 
of the private key for the client to accept the connection, however PSK based 
0-RTT might not be associated with a certificate at all. Thus the only way to 
prove that the key is still fresh is to limit the time that the PSK is valid 
and strictly bound that time. Unless we add a way for the client to require a 
server authentication during PSK resumption.

This is relevant in situations where compromise of the ephemeral key does not 
mean that the long term private key has been compromised like in ssl offloading 
type scenarios.

Subodh Iyengar

From: TLS [tls-boun...@ietf.org] on behalf of Eric Rescorla [e...@rtfm.com]
Sent: Tuesday, February 23, 2016 11:42 PM
To: Watson Ladd
Cc: tls@ietf.org
Subject: Re: [TLS] Remove DH-based 0-RTT



On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd 
> wrote:
On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk 
> wrote:
>
>
> On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett 
> >
> wrote:
>>
>> On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote:
>> > I propose that we remove DH-based 0-RTT from TLS 1.3.
>> >
>> > As ekr's previous mail noted, the security properties of PSK-based
>> > 0-RTT and DH-based 0-RTT are almost identical.  And DH-based 0-RTT is
>> > much more complex.
>> >
>> > For those who love DH-based 0-RTT, and I know that some people are
>> > fans, here's something that might make you less sad about removing it
>> > from the core spec.  You can use DH out of band to negotiate a PSK.
>> > You might even do this as an extension to TLS, but that's of less
>> > value.
>>
>> I think there is a good argument for moving DH 0RTT into a TLS extension.
>> Implementations that are explicitly not going to use it should not be
>> expected to implement it and risk screwing it up. If we accept that premise
>> that online DH 0RTT will be unlikely in practice, then we would be
>> specifying it at least primarily for out-of-band use, and doing it via an
>> extension will probably be cleaner and safer.
>
>
> Combining this comment (which I agree with) with the following comment from
> Watson in another thread:
>
>>
>  If they rely on extensions then either those
>>
> extensions need to be included in the security proofs, or we need to
>>
> make clear that they are not as secure as TLS 1.3, and that
>>
> implementations which enable both of them can get completely wrecked
>>in new and exciting ways.
>
> We get that even if it is decided not to include the DH-based 0-RTT as part
> of mandatory-to-implement TLS 1.3, it should be defined as an extension and
> as part of the TLS 1.3 document. Leaving the reduction from this case to PSK
> (as Martin suggested) to popular imagination is too dangerous. By including
> it as part of TLS 1.3 official text we also encourage the groups that are
> currently analyzing the protocol to include this specific mechanism in their
> analysis. If they find something wrong with it then even more reason to do
> the analysis.
>
>
>>
>> I would still prefer it be defined in the TLS 1.3 specification document,
>> though optional.
>
>
> I suggest to also define TLS 1.3-EZ.
> A subset of core safe functionality that should address the majority of the
> usage cases.

I strongly encourage this proposal, and will even massacre the
markdown to attempt it.

Great. Let's sync up as we get a little closer to done.


I also commit to implementing TLS 1.3-EZ in
Go, and possibly in C based on Amazon's s2n. (A trustable X509 library
in C is still beyond my reach, so that C might be server-only).

I believe Richard Barnes has already started something along these lines,
so maybe you guys could join forces (not sure how confident he is in
it).

https://github.com/bifurcation/mint

This library currently interoperates with my experimental implementation
in NSS.

-Ekr


>
> Hugo
>
>
>>
>>
>>
>> Dave
>>
>> ___
>> 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
>



--
"Man is born free, but everywhere he is