Skip to main content

Minutes for TLS at IETF-89
minutes-89-tls-3

Meeting Minutes Transport Layer Security (tls) WG
Date and time 2014-03-04 16:10
Title Minutes for TLS at IETF-89
State Active
Other versions plain text
Last updated 2014-03-14

minutes-89-tls-3
TLS Working Group Meeting 
IETF-89, London
Tuesday, March 4th, 2014, 1610-1840
Chairs: Eric Rescorla, Joe Salowey
Notes: Matt Miller
Version: 1.1
--------------------------------------------------

BL == Ben Laurie
JS == Joe Saloway
EKR == Eric Rescorla
SK == Stephen Ken
DM == Daniel (Migault?)
YN == Yoav Nir
KP == Kenny Paterson
MSJ == Mike St. Johns
TK == Tero Kivinen
RH == Russ Housley
MT == Martin Thomson
PH == Paul Hoffman
DMcG == David McGrew
ST == Sean Turner
CJ == Cullen Jennings
DA == Derek Atkins
MNOT == Mark Nottingham
DKG == Daniel Kahn Gilmore
MP == Max Pritikin
MJ == Mike Jones
PMcM == Patrick McManus

1. Administrivia (5 Min)
- Note Taker, Jabber, Blue Sheets

2. MAC Ordering (15min) Presented by Eric Rescorla
- draft-ietf-tls-encrypt-then-mac

No comments in room.

Next Steps: Draft to be submitted as working group item, review then WGLC

3. Downgrade Protection (20 Min) Presented by Ben Laurie
- draft-moeller-tls-downgrade-scsv

BL: reports approach has been deployed in chrome 33 without problem.  

ACTIONS:
* The Chairs believe this is something the WG wants, so will approach
the ADs about adding it to the charter.

DKG: It was not clear if there was a resolution to if an extension
caused an extension to fail or otherwise.
BL: I think if it something systematic then you'd find a way to fix
the software.

4. ChaCha Ciphers (10 Min)
- draft-mavrogiannopoulos-chacha-tls

KP: Both of these algorithms (chacha and poly1305) have had
significant review, but not enough that you would probably be
comfortable with for TLS.
EKR:
YN: Google's servers are using it in their software (Chrome to Google
servers, about 2%).  It's treated as a stream cipher but it's more
like a ctr-block cipher.
JS: We need to discuss if we are taking the correct approach; it's
being used as a stream cipher where maybe it should be used as a AEAD.
JS: We need more review before we can ask for adoption.

5. IVs, DTLS, ChaCHa (10 min) Presented by Kent

EKR: The two arguments for not using the IV like this is because you
save 8 octets each packet, and it's not known what the security
guarantees are while we do with explicit IVs.  Rather, do you know
what the warning labels are for this?
SK: I need to go back and look.  I know NIST has something about how
to use counter mode safely, but I don't remember off-hand.
EKR: This is something that we could use guidance for.
DM: Can we also define an IV generator function, that could take into
account a counter?
SK: No (-:  The idea from an eval perspective, you can submit the
stamp that says "I have used these algs in these modes".
MSJ: That's for the encrypt side, but you decrypt with what you're
given (before we got fancier with AEAD).
EKR: Note this is about helping you not screw up.
TK: Make it so you can get the seq num form the IV as output from the cipher. 
SK: You should definitely take that to the list!


6. CFRG Update (15 Min) Presented by McGrew
PH: I did not hear only one new curve family, but a limited number.  I
don't know if one is a good way of going forward.
DmG: I do think we need to limit the scope.
PH: I don't think the room felt one was the right number, but we
definitely don't want a lot of others.
McG: Its particularly true if some of these can't be used for some
things like signatures.
PH: I don't want us to focus on one, but we don't need to be really
generic.
EKR: As a consumer, the primary motivations are performance and the
security over the NIST curves.  So what I think we want is one extra
set of curves (ECDH and ECDSA) at the necessary security levels (e.g.
256, 384, 512).  Unless there's very strong evidence for radically
better properties, we should not have more than one family.
McG: So, something like Brainpool that doesn't require a code change,
or would it be ok for something that is better but requires different
code.
EKR: If brain pool is acceptable that is something we have a standard for
DMcG: and there's a category where it needs to be interoperable with
existing code.
RH: That is one of the points I stood up to make.  We really ought to
consider that the interoperability point is important for the
consideration.
RH: Note that it is early April, and there's certain requirements for
notice on interim meetings, so you should post something to the list
very soon.
ST: avoid crypto sport, limit to one or a small number
ACTIONS:
* Chairs agree that having a cross-WG teleconference is worthwhile; to
announce on TLS mailing list to meet IETF virtual interim requirements

7. Session Resumption Issues (15 Min) Presented by Karthik Bhargavan

ACTIONS:
* Recommend others read these drafts and comment on lists

Stephan S: One of the problems that I run into, it needs to be unique
and it needs to be available to the auth layer.  If it's not
integrated into the TLS stack then I can't use it.  Why do we have to
go through all of this if we already have good data for the session
identifier.
KB: The only problem we have to deal with is what happens if the
server certificate changes.
SS: If both the 'm' server and the real server have the same
certificate then the CA system is broken.
KB: Sure, but if you have another handshake that uses the different
certificate than the initial handshake.
SS: I'm not sure what you're trying to solve, but you need to verify
the certificates.
DG:There is another approach is if you want to hide your SNI, which
you do by negotiating without SNI then re-negotiate with SNI (and
changing your cert).
DB: Also, if the server is using a known good list then you avoid a
class of problems.
PSA (MRex): I'm not aware of implementations that can get their hands
on the master secret.
KB: There are APIs for you to get the master secret within the TLS,
but don't necessarily let you get it outside.
Kenny Paterson: And someone could go into the software and parse out
the master secret.
KB: We should not that we're not saying you pass up the master secret,
but by chaining together the final messages you get the best security.


8. TLS 1.3 (60min)
- New protocol flows
- Requirements: do we need
    - Encrypted SNI?
    - Static RSA?
    - Resumption?
- Record layer issues
    - Cipher suites
    - Version number
    - MAC/Encrypt order



BL: Why is the ServerKeyExchange not encrypted?
EKR: You could do that
BL: I think you should
RH: If I understand this right, you are doing two DH (EKR: Correct).
Is the cost for the additional DH is less than the first half.
EKR: The speed of light is not getting any faster
RH: Note the cost is pretty significant.
EKR: I'm trying to say, not you must do this, but rather you can do
this if you want encrypted SNI, but you have to pay the cost.  We need
to decide whether this benefit is worth paying that cost.
MT: If the server is sending the message, it has to be evaluated by
the client, which means the client needs to wipe the message before
doing anything else, which means we have two round-trips.
PH: If the server's key is ephemeral, there could be two or more of
them?  How does the client tell the server which key it's using?
EKR: There is a label, in the PredictedParameters
PH: So how is this managed?  Because we don't have a slot for this in DANE.
Daniel Kahn Gilmore: If we make this too long, it can be fingerprinted.
EKR: I think we deliver this encrypted, so it's possible for the
server to deliver a new one each time.
DG: There are two ways to do fingerprinting: fingerprinting the
client, and fingerprinting the server.
EKR: I'm concerned about the second one.
DG: an option is to limit the server to a small set. 


:: Discussion on Protecting SNI ::

???: In the case where SNI is useful is where you can't have shared
keying material.
TH: We should have a mode for encrypted SNI, and I would prefer this
be the only mode (and use TLSv1.2 if you don't want it).
DKG: I do think it's worth doing, and it should be the only mode.  I
wanted to push back against the problem that this causes problems in
multiplexed environments.  You just need a label for this key, and the
SNI-based multiplexer just needs to manage it.
MSJ: My concern is the need to cache for a very large set of servers.
If you're going to handle a five-message fallback, you are going to
have a lot of keys cached.
EKR: Are you concerned about the server managing a lot of keys?
MSJ: No, it's the client needs to manage a large number of keys.
TH: The client will need to cache the keys for as long as they're
valid, but it's a tradeoff.
PH: If there's multiple servers behind this, it could require multiple
round-trips as you fail through the keys.  You might need multiple
flows, in order to deal with the various failure modes.  So we need to
measure things carefully.
CJ: In the environment where SNI is most used, it could require the
owners to provide the private keys to each of the servers.
EKR: So how do you want to deal with this?
CJ: I think we'll need to have an option that you not protect SNI.  I
think you're trying to solve a problem you can't really solve.
DA: You solve that by having the label contain a random address.
CJ: I happen to think sharing extra info with a load balancer is bad.
DKG: What you're effectively asking for is to have a unique host/port
for each TLS termination point -- effectively leaking information.
TH: I think it's a bummer to have that proxy architecture, but it's
not the only one.  You might not get a single RTT up front, but it can
get you to 0 RTT later.  What we are trying to optimize for is growing.
MT: I think putting stuff in the label, or sharing some of this other
stuff is possible.  I also want to point out that enumerating the
sites that are on a particular site is not that easy.  There's a large
space in which you can guess.
MNOT: Nottingham: I think this is a very interesting issue that is
balancing a number of different things, and we need to by very careful
about it.

Hum On protecting SNI:

    #1 Hum for protect SNI (slightly more than #2)
    #2 Hum for don't protect SNI (slightly less than #1)
    #3 Hum for don't know/care (very few)

<zero round trip discussion>

RH: I'm confused.  On one hand you're saying you want PFS so ditch
(static) RSA, but this is saying "screw PFS" and use RSA.
EKR: Its a trade off. removing static RSA is not just about PFS, but for Protocol simplicity. 
Bryan Dixon: You're talking about having to send something to fall
back?  Would it make sense to send more to do both things?
EKR: You are sending the reply assuming it'll work, but you're also
sending the initial again.
MNOT: I thought sending a anti-replay token exposed you to passive attacks
EKR: Active attacks (on PFS), but not passive.  We are assuming that an
attacker that has access to the server within an hour, we can't
protect that.
MNOT: You're making me feel better about.
Eric Nygren: Another thing we should pay extra attention to here is that it
works for distributed servers.  if it's done wrong the anti-replay is
going to make things a lot worse than no retry.  Also how the key for
the first exchange might be less secure than the others.
PH: I'm going to suggest that "close-to-perfect" is perfect, and not
put in bogus data.  Since it's a short-lived key, this is PFS to the
degree that Mark should not be worried.




:: DISCUSSION ON STATIC RSA ::

Jeff Hodges:  Perhaps you should define static RSA
EKR: There is an RSA key that is used for the diffie-hellman
??: So this means TLSv1.2 still has RSA static but that TLSv1.3 won't?
EKR: Correct.  So we want to put in a condition that you can offer
v1.2 if you're willing to roll back
CJ: This will mean people that want to do really small implementations
can't do this.
Chris Newman: This is about server certs, or both client and server
certs (just server).  So this is to deprecate the RSAwith*.

On removing Static RSA
	#1 Hum for removing Static RSA (large amount)
	#2 Hum for keep static RSA (none)

:: DISCUSSION ON REMOVING COMPRESSION ::


On removing compression in TLS 1.3:
    #1 Hum for removing compression? (large amount)
    #2 Hum for keeping compression? (none)


:: Discussion on Stream (none) vs Block (basically CBC) vs AEAD ::

Mike Jones: To clarify, would mcgrew-cbc+hmac in the list?
EKR: It is not in the list, but we can add it.  It does not preclude
CBC algorithms, but precludes CBC stand-alone.
Chris Newman: There is some hardware-based support for AEAD, but not a
lot.  How does this impact those hardware accelerators?
EKR: I don't know what the impact is.  We should ask.
Hannes: The work went into public ciphers.
DA: I think it might complicate us if we have to have different
ciphers for different modes, especially if they have different
ciphersuite id's.  What would be hard is if I have to flip it.


On cipher suites:

    #1 Hum for only AEAD? (large)
    #2 Hum for allowing block + stream + AEAD? (none)
    #3 Hum for need more info? (some)


:: DISCUSSION ON REMOVING RENEGOTIATION ::

JS: With authentication server type stuff, we use re-negotiation for
client privacy, but we're solving that in a different way.
YN: There is the case where you *may* log into a web server with a
cert (or without), and we want to support re-nego for that.
EKR: Do people actually do that in the browser?
YN: People do.  Not the cloud providers, but banks and others do use it.
DKG: Cliet auth is atrocious UI, but there are cases where you need
re-nego for it to work.
MT: Where this starts to get interesting is if you have multiple
connections folded into the same connections, but a site wants client
auth.  Today that's re-nego, but maybe we need to have a different way
to do this, like new status codes in HTTP.  Or make a new connection.
DA: I dont think people in here can really answer this question about
"will it break?"  I provide a toolkit, so we can't rip it out if
people are using it.  I can try floating its removal past our team.
PMcM: HTTP/2 will multiplex a bunch of URIs together, and we can't
necessarily know what is where in preflight.  So using a landing page
means you're probably broken.
Orit Levin: Maybe you put this question onto uta@ietf.org.
MP: There are some that are muxing things altogether breaks the
client, but maybe it's doing this muxing different security contexts
is what's really breaking it.
Erik Nygren: Maybe we just need a new extension for this.
YN: I agree that this is a terrible thing.  Having this in HTTP fixes
this.
EKR: Maybe we need to ask if this is only an HTTP problem, or it
happens more generically.
CN: In email clients, client auth is sometimes used but it's a pain.
Email protocols don't use re-negotiation.  You can also remove client
auth.
EKR: I know of one case where we need client auth.
Hannes: There are people that have chosen DTLS because it has client auth.
DKG: I don't know who needs re-nego for PFS refresh/cipher exhaustion
PSA: XMPP server-to-server, there are cases where a TLS connection has
lasted for over a year.