Minutes for TLS at interim-2014-tls-4
minutes-interim-2014-tls-4-1
| Meeting Minutes | Transport Layer Security (tls) WG | |
|---|---|---|
| Title | Minutes for TLS at interim-2014-tls-4 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2014-11-10 |
minutes-interim-2014-tls-4-1
TLS WG Interim
Honolulu, HI
Sunday, Nov 9 - 2014
0930 - 1530
Chairs: Sean Turner, Joe Salowey
Notes: Paul Hoffman
----------------------------------------------
General agenda:
Session resumption
Key refresh / client autho
0-RTT
OPTLS signature-less stuff from Hugo
Blue sheet equivalent was passed around
Resumption
------------------
Two kinds of resumption:
Classic: session IDs, same in 1.3 as in 1.2
Tickets: RFC 5077 style
In Paris, suggestion was session IDs, cookies, and PSK can be combined
Can be arbitrarily large
Treat session resumption as PSK, or treat PSK as session
resumption?
Some PSK modes offer PFS, but some do not
PSK modes are currently broken in TLS 1.3
Questions about modes that use PSK for authentication and also to mix
into the keying material Maybe we can throw away the public key PSK
modes PSK mode would be a separate ciphersuite(s) For now, only repair
the non-public-key PSK ciphersuite Questions:
What's the format of the ticket?
Which PSK modes do we want to get back?
Is it OK for us to have a master secret used on different
ciphersuites? Do we need to know ahead of time if we are doing
a resumption or a new PSK session?
Conclusions:
* We probably want to retain the DHE modes
* Want tickets to work
* Want tickets and session IDs to be the same
* People want to see a design of the unification
* Want session resumption is essentially a PSK ciphersuite
OPTLS discussion
--------------------------
performance win with long-term RSA certs
Use cert to sign ECDH ephemeral key
Slightly more effort for the client
0RTT requires a semi-static key anyway, so this seems similar
Need to have a signed parameter for every set of parameters I'm willing
to use Offline signing has some benefits Can be used for delegation
But we could just design delegation separately anyway
We need to be upfront about the problems with delegation
Probably no HSM today will support this
You can use your current RSA certificate without signing to gain
performance increase Question: if an attacker can replicate the
client's PNRG state, can they now impersonate? If you're doing this on
the client side, things are marginally worse
Let's decide first if we're doing it on the server
This is to replace all the signature modes, not adding new ones
The format of blob will be hard
Might include the server identifier
Could all be fixed with just getting ECDH or ECDSA certs
Lunch was had
* Performance benefit only helps with RSA signing, if you use ECDH or ECDSA
certs then it is less improvement * Delegation needs to be designed for *
Complication to the key schedule also causes some worry * Almost no support in
the room for OPTLS today; consensus of room against
Back to session hash
----------------------------
How to decide when to compute the server finished
Would be nice for the server know if there will be client
authentication early on Question of whether CertificateVerify appears
in the master key Because you want the client certs hashed in for
resumption, you have to synthesize another last key Update updates the
binding identity/ticket to the session The server being able to send a
first message in HTTP/2 before it gets a client cert is useful Perhaps
no need to provision tickets during handshake Possibly resurrect Ekr's
earlier proposal for Update
http://www.ietf.org/mail-archive/web/tls/current/msg13966.html
Add a restriction that the client can do so only once
Removed the gratuitous ChangeCipherSpec
Client auth
----------------
Server has to be able to say which signatures it can verify
Certificate Request is both badly messed up and also useful for client
UI
Difficulty of "an issuer" vs. "the issuer"
Do we want some additional OID matching?
Useful for servers to be able to control the client experience
This is really for HTTP because other TLS users don't have as
much UI issues Client cert caches exist
We can't nuke certs, but maybe leave this alone so that it goes into
HTTP/2
EAP-TLS uses some of this filtering
Microsoft folks will look into what kind of things they want in future
for client filtering
Single point format
--------------------------
Proposal: every new curve comes with a format
All current would use uncompressed points
No more point negotiation
Proposal:
- Each curve code point has one representation
- The existing NIST curves will have an uncompressed
representation - We will remove point representation
negotiation - If we want to add a compressed format for the
existing curves we will define a new code point
Feeling of the room was to support this
Maybe remove some of the weak and the less-used curves
Set the minimum strength to 128 bits
-------------------------
OK to remove Tim’s name from the author list and add to contributor section?
No objection in the room