Minutes for TLS at IETF-94
minutes-94-tls-1

TLS Working Group
IETF 94 - Yokahama

Day 1:  Wednesday, November 4, 2015 09:00-11:30 (JST)

0900-0910   Chairs      Administrivia

0910-0920   Yoav        RFC 4492bis

Yoav presented the status of RFC 4492bis

Slides are at https://www.ietf.org/proceedings/94/slides/slides-94-tls-0.pdf

If no objects for pull request #10 then is going to be merged

EKR requested a PR for the TLS 1.3 draft that does the same thing as PR #11

For pull request #13 - Yoav believes that Expert Review might be better than
Specification required.

EKR trade off between too many algorithms showing up and hard to get the needed
algorithms.  Mor of an issue for algorithms than curves perhaps.

Russ suggests that a small section for experimentation should be done - EKR
does not object to this idea.

There are issues that need to be dealt with in that experiments that work will
not want to change numbers and will squat on experimental code points.

STF - Policy needs to be on all of the registries not just the curve

A policy is designed on the fly for dealing with 16-bit registries.  Partitions
the space into multiple spaces with a tag of good/perhaps/bad for things that
come out in the wild.  Policy is designed to slow down the consumption of the
space not to prevent registration.

Still need to write the guidence for the Expert review.  EKR suggesting a
superficial review at most.

0920-0950   EKR         TLS 1.3 Since Prague

Slides are https://www.ietf.org/proceedings/94/slides/slides-94-tls-5.pdf

Client certificate request discussion:

DKG: there are some questions about privacy leaking whendoing a certificate
request syntax as things like UI will provide timing information.

EKR: Yes this is an issues - if you have mitigation please help.  Text on the
issue for the document would also be nicee.

Post-Handshake Authentication:

YN: What data is needed to keep to have the context

EKR: Keep the hashes for the acceptable algorithms when it supports.

DKG: Whyis the server certificate in the 0-RTT - problem with making sure you
are talking to the right entity.

EKR: Might be possible to use SNI instead, but need to do more careful
analysis.  Need to deal with wild card certificates among other issues.

Server may not need to respect the SNI value, it is included in the hash from
the hello.

MT: Design was to ensure that SNI was validate by the server.

EKR:  Also need to digest in for key extensions of certificate.

Comments on data flow picture:

1.  Appliction data should be covered by 0-RTT

2.  Should have optional application data immediately following server finish

Framing for 0-RTT:

R Satz: please use alert for close..notify

HelloRetryRequest:

Doing the address token might make DTLS easier.

Need to try and avoid some trial decryption

Also, if cookie is re-usable then need to have some expiration markers or
algorithm.  This needs to look at the client correlation properties as well.

Re-Keying:

Need to figure out what the saftey margin needs to be, there needs to be a
discussion on this.

Then need to look at what the attack model is going to be.  This is different
for TLS and DTLS as a single decrypt alerts or TLS but not DTLS

MT: Rekeying is a trival things to implement an allows one to be as
conservative as one needs to be.

EKR: Second benefit is forward secrity as all data before the crank of keys is
not reachable.

AP: Like mechanism because it is easier.  Should there be a way to force the
opposite side or just drop the connection with an alert.

Brian Ford: Need to look at re-key loops.

Poll of room:  We should just do this and not worry about the step of getting a
response from CFRG.

Exporters:

People are asked to determine if the fact that the client certificate is not
included in the exporter secret is an issue.

Usages of exporters are 1) get secondary keys 2) channel binding type things.

BF:  Could it be a method of forcing export key to be updated is done.  EKR:
Yuck

AOB:

SPT: Requests for additional ciphers from others.  Listing in A.4

Suggest thinning it down to the SHOULD/MUST list only.

EKR: Need to encourage support for PSK variants

EKR: Looking at the difference between the "good" list and the "safe" list and
the "no opinion" list

EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is good.

SPT: Did we settle on the SHA-1?

MT: Way for client to signal that it did not want sha-1.  What is valid for the
cert chain.

PSS:

slides: https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf

Russ: Are you trying to encourage poeple to move to PSS or to ECC?

SPT:  Numbers of affected people are going to be in the double digits for
adopting PSS (old slide)

RS: Likes the question raised by Russ - has an obvious opinion.

EKR: Can deploy and then turn off v1.5 later based on numbers

Ian S: What can we do to compress the certificate.

Offer option of doing hash of certificate

EKR: Caching certificate extension should solve this

Keyless-SSL:

Slides: https://www.ietf.org/proceedings/94/slides/slides-94-tls-6.pdf

MT: Where do you see this being deployed?

RB: Don't believe that this is really the correct working group for it.  No
protocol mods for TLS. Suggest a BOF on this topic.

DM:  Asking for feedback at the moment.

DKG: There are places where remote key presence is high desired.  Not limited
to TLS.

DM: API can be very close to the HTM API.

RS: Want to make sure you don't become a signing oracle.   Might be some IPR on
a related version.

Day 2: Thursday, November 5, 2015 17:40-18:40

Solve the SHA-1 Question - Martin Thompson

slides: https://www.ietf.org/proceedings/94/slides/slides-94-tls-7.pdf

Rehashing some of the discussion from the mailings list.

Problems with root certificates, problems with re-use of same material

Root certificates/Trust anchors should not care about the algorithm as it is
just a key container.  Trust needs to be checked else where.

RH: need to know the name of a trust anchor as well.  Signature is not important

Room Poll - no objections to this approach - solid yes hum

YN: Should not make protocol statements on what the client should accept -
Feels to be wrong approach.

EKR: The behavior of signature_algorithms has been defined since the start.  We
are just talking about removing the restrictoin for one case.

1805-1830   DKG/EKR     SNI Encryption

slides: https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.pdf

YN: Question on why for example on page 5 the cover certificate is not enough

DKG: Want to generally have one mechanism -

EKR:  Might be able to make the co-tennanted flow accept 0-RTT data, but no the
other case

MT: Why are the encrypted extensions sent through?

There are two keys that are in play - a 0-RTT key fo the gateway and the hidden
server's separate keys

EKR: Mistake in the diagram on 7 - the hidden server should claim it does not
do 0-RR and fail

Hidden server must always send a 0-RTT data that corresponds to the gateway
state, not it's own state

EKR:  For the shared point, the only new thing is the one extension

For the gateway case there are more semantics that need to be dealt with

DB: Would it not be easier to do a tunnel protocol?

DKG:  That would require that the gateway actually do cyptographic work - there
is no additional decryption by the gateway in this case.  It is just packet
forwarded.

EKR: Somewhat convinced by Bev's case - we placing trust in the gateway for
somethings - additionally request of doing the decyption may not be that hard.

RS: Slides and presentation may not be helping understanding here.  Need to
look at things outside of protocol as well.  Think this is good to do.

Mike Bishop:  Requirement to do encryption by the gateway may indeed be an
issue base on feedback from http workshop.

MT: Can put in the encryption extenstion for RSNI - may be enough to bootstrap.

1830-1840   Jay         TLS/DTLS PSK Identity Extension

slides: https://www.ietf.org/proceedings/94/slides/slides-94-tls-1.pdf

Did not get presented.