Re: [TLS] Draft status and updates

[Ilari Liusvaara <[e-mail]>]

On Wed, Dec 02, 2015 at 09:29:23AM -0800, Eric Rescorla wrote:
> On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara <[e-mail]>
> 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