Re: [TLS] Draft status and updates

[Eric Rescorla]

On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara 
wrote:

> On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote:
> >
> > 3. The server provides g^y in his ServerHello and then g^xy and g^xs
> > are jointly used to produce the traffic keys and also to form a MAC over
> > the handshake. As Hugo pointed out originally, this alone should
> > be sufficient to authenticate the server's side of the connection and
> > you could omit the server CertificateVerify (Hugo, please correct
> > me if I have misunderstood).
>
> Is it guaranteed that the groups are the same?
>

Yes, it's a requirement that the groups be the same. If the text doesn't
say that, it should.



> Even if it is, due to implementation bugs, bad idea to rely upon that.


Can you expand on this point? Is there a specific easy-to-make
implementation
error you are concerned with?



>
> > Trying to read between the lines, is your concern that the server is
> > now no longer explicitly signing over the ServerConfiguration in
> > its CertificateVerify [Note that the client continues to do so]? The idea
> > behind removing that was to make the 1-RTT part of the handshake
> > more uniform regardless of whether 0-RTT data was used.
> > I'm certainly open to putting that back in if it's needed, but can you
> > explain your concern in more detail?
>
> The concern is that attacker that has managed to inject g^s for
> known s is able to impersonate the server even through server certificate
> validation on subsequent connections (under some conditions).
>

I'm sorry, I'm still not following. All the data that the server sends is
tied to
g^y which is signed with the server's certificate, so even if s were
published,
the attacker should not be able to inject data which the client would
accept.

With that said, it's certainly true that if the attacker is able to
convince the
client that the server has a certain g^a where a is known to the attacker,
then the client has a problem because he will encrypt data *to* the
attacker in 0-RTT, so obviously we are assuming that the attacker does
not know s and cannot convince the client to accept a g^s of his
choice.


(Indirectly) signing g^s would prevent this.
>
> ... Funkily enough, this attack doesn't work against either tls-unique
> nor tls-extractor (however, those still fail nonce check with respect
> to SS)...


Do you think you could draw a ladder diagram that shows the attack you
are concerned about?

-Ekr






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

Re: [TLS] Draft status and updates

[Ilari Liusvaara]

On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote:
> 
> 3. The server provides g^y in his ServerHello and then g^xy and g^xs
> are jointly used to produce the traffic keys and also to form a MAC over
> the handshake. As Hugo pointed out originally, this alone should
> be sufficient to authenticate the server's side of the connection and
> you could omit the server CertificateVerify (Hugo, please correct
> me if I have misunderstood).

Is it guaranteed that the groups are the same?

Even if it is, due to implementation bugs, bad idea to rely upon that.
 
> Trying to read between the lines, is your concern that the server is
> now no longer explicitly signing over the ServerConfiguration in
> its CertificateVerify [Note that the client continues to do so]? The idea
> behind removing that was to make the 1-RTT part of the handshake
> more uniform regardless of whether 0-RTT data was used.
> I'm certainly open to putting that back in if it's needed, but can you
> explain your concern in more detail?

The concern is that attacker that has managed to inject g^s for
known s is able to impersonate the server even through server certificate
validation on subsequent connections (under some conditions).

(Indirectly) signing g^s would prevent this.

... Funkily enough, this attack doesn't work against either tls-unique
nor tls-extractor (however, those still fail nonce check with respect
to SS)...



-Ilari

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

Re: [TLS] Draft status and updates

[Ilari Liusvaara]

On Wed, Dec 02, 2015 at 09:29:23AM -0800, Eric Rescorla wrote:
> On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara 
> wrote:
> 
> > On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote:
> > >
> > > 3. The server provides g^y in his ServerHello and then g^xy and g^xs
> > > are jointly used to produce the traffic keys and also to form a MAC over
> > > the handshake. As Hugo pointed out originally, this alone should
> > > be sufficient to authenticate the server's side of the connection and
> > > you could omit the server CertificateVerify (Hugo, please correct
> > > me if I have misunderstood).
> >
> > Is it guaranteed that the groups are the same?
> 
> Yes, it's a requirement that the groups be the same. If the text doesn't
> say that, it should.

If the document says that, it is so unclear that I didn't even find the
requirement.
 
> > Even if it is, due to implementation bugs, bad idea to rely upon that.
> 
> Can you expand on this point? Is there a specific easy-to-make
> implementation error you are concerned with?

There is long history of TLS implementations omitting all kinds of checks,
even ones explicitly called as MUST.

E.g. It would surprise me more not to see any TLS 1.3 implementations that
decrypt 0-RTT data with ciphersuite different from negotiated (despite the
spec clearly forbidding this) than seeing those.
 
> > > Trying to read between the lines, is your concern that the server is
> > > now no longer explicitly signing over the ServerConfiguration in
> > > its CertificateVerify [Note that the client continues to do so]? The idea
> > > behind removing that was to make the 1-RTT part of the handshake
> > > more uniform regardless of whether 0-RTT data was used.
> > > I'm certainly open to putting that back in if it's needed, but can you
> > > explain your concern in more detail?
> >
> > The concern is that attacker that has managed to inject g^s for
> > known s is able to impersonate the server even through server certificate
> > validation on subsequent connections (under some conditions).
> >
> 
> I'm sorry, I'm still not following. All the data that the server sends is
> tied to
> g^y which is signed with the server's certificate, so even if s were
> published,
> the attacker should not be able to inject data which the client would
> accept.

I would certainly expect the signature check, if it is there at all, to
be proper nonce over SS.

IIRC, the key exchange is explicitly intended to be secure (but forward
security is lost) if ES is revealed.

Config-authenticated ciphersuites are different matter (the main
challenge there seems to be deciding when those are to be enabled[1],
not so much designing the key exchange[2]).

> With that said, it's certainly true that if the attacker is able to
> convince the
> client that the server has a certain g^a where a is known to the attacker,
> then the client has a problem because he will encrypt data *to* the
> attacker in 0-RTT, so obviously we are assuming that the attacker does
> not know s and cannot convince the client to accept a g^s of his
> choice.

Oh yeah, that too... I don't work with 0-RTT that much, as it is way
harder to analyze than 1-RTT (bad thing, I know).



[1] Persistent inpersonation and all that...

[2] Require server to send EarlyData if one is used, then just omit
server Certificate and CertificateVerify.


-Ilari

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

Re: [TLS] Draft status and updates

[Ilari Liusvaara]

On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote:
> 
> This clears out the big pipeline stall from PR#316, but probably has
> created some bustage. Expect a series of cleanup commits and some
> other things that were head-of-line blocked this week and then
> draft-11 in the next week or so. Please file PRs and/or github
> issues for any issues you see.

Looks like the note about the PSK+ClientCert "attack" got lost
somewhere. While I don't think that is important as the underlying
issue is fixed, I think there might be a note about dangers of using
server certificates in any mode where transcript and configuration
do not jointly imply SS.

Actually, scanning the editor's copy, it looks VERY broken to me:
I don't see how server certificate verify (indirectly) signs on the old
configuration. Such signing is required for security, as otherwise
SS is not impiled by signature, breaking authentication.

Previously, the document was clear about this...
 
> In addition, PR#354 (https://github.com/tlswg/tls13-spec/pull/354)
> implements the rekey mechanism that we discussed in Yokohama.  There
> was broad agreement to adopt something like this.  I would appreciate
> it if a few people could give it a sanity check, but absent strong
> objections, I intend to merge this PR on Friday.

The restrictions on when the rekey message can be sent: Do those
essentially boil down to "any time after sending Finished"?

Also, I think the requirement to immediately send the KeyUpdate
is problematic. I think it should be requirement to send it as
next record(s).

The two aren't the same: The first seemingly requires scheduling
extra flights, which can be problematic. The second can piggyback
on existing flights. 
 


-Ilari

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