Minutes IETF101: tls: Wed 09:30
minutes-101-tls-201803210930-00

Session II

TLS - ekr - 5min
  https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

The crowd rejoices when it is announced that the TLS draft has been approved. 
They were entertained!

DTLS - ekr - 25min
  https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

Connection ID - ekr - 25min
  https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/

ekr: The two presentations were merged.
ekr: Do we want a bit for CID?

Hannes: No more in favor of explicit proposal.  Like new header design.  Don't
care if we put it in the content type or the length field.  Do something for
1.2 and then focus on better for 1.3 later.

BenK: Any privacy implications of having a bit?
ekr: We should probably say something, but it's not a big deal.

Thomas: I prefer explicit.  Fantastic design.

Tobias: Prefer explicit version as Hannes mentioned.  Don't like magic #s.  Can
we do this for soonish that would be good because TLS1.2 deployments need this
now.

ekr: propose that we'll split the draft into one for 1.2 and 1.3.

mt: Been in favor of the Implicit case before, but going explicit helps
middleboxes, tools, etc.  So this seems like the way to go.  Not sure we can
steal QUIC's design.

ekr: Would like to steal the encrypted sequence #s.  That discussion will be
fun.

Chair: Any opposition to explicit? None noted.

mt: The skipping trick from QUIC is kind of annoying.

ekr: agree.

mt: we should probably just move to ROT13 for the additive factor.

ekr: Instead of skip you use a random add and then you add it modulo 2^48.

mt: The advantage is that you don't need to worry about the fix seq of CIDs as
they come out.  Current QUIC requires you do them in strict sequence.
Christian: We don't like the CID-based skipping because if you have any kind of
overlap between the old and new CID you can easily deduce so there's no privacy.

ekr: mt convinced me so I'll write up the add trick.  For 1.3, we should
encrypt the sequence #.

Subodh: Re-read draft and the TLS conn-ID isn't under the authentication?

ekr: Need to write it down in 1.2.

Tobias: From a minimalistic approach, we just need a way to update CID.  If you
do update, then you've solved privacy problem.

ekr: Next slide on this, but unfortunately update doesn't just solve the
privacy problem.

mt: In QUIC looking at different numbering spaces.

chair (CID Update): back porting 1.3 features to 1.2 has been shot down.

mt: We can say you can renegotiate but if you're trying to break likability
then it's not useful.

Tobias: We need to update CID for privacy reasons.  Could live with a
rehandshake.

ekr: We change the minimal offer/answer extension to allow more than one CID. 
Then, in the re-handshake you offer multiple.

VictorV: I'm confused about privacy reasons for backing this to 1.2.  I thought
it was just about nat rebinding and there they stay the same.

??: Rehandshake is not great because it's not energy efficient.

ekr: We're basically not designing 1.2, if we're looking for something elegant
do 1.3.

Hannes: Agree with Victor, but we should aim at something that gets something
done quickly.

Thomas: Every time the node goes upstream the path is changing.

ekr: None of these mechanisms are designed to support that.  Hours spent on
rotating CID mechanism.

chair: We're looking for a sweet, quick win.

Hannes: If you back port that into 1.2 it's not that easy to do.

Tobias: Require rehandshake is better than do nothing.

mt: It fixes the NAT-rebinding case, which was the primary driver.  If we do
nothing it also might move folks to 1.3 faster.

chair: Understanding that this is not great, is there anybody who is violently
against just saying do a rehandshake?  none.

DNSSEC Chain Extension - Shumon/Willem - 25min
  https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/

ekr (as AD): Don't which one it is, but the WG needs to pick.

mt: This is not an interop requirement, so you could just say "can".

rlb: Use it if you want and don't if you don't.

dkg: Use SHOULD in both places because that's what you'd do if you implemented
the drat.

shumon: We'll reword it to drop the 2119-langauge.

PaulW: Paul's convinced full message isn't needed.

?? (cz.nic): Also agree.

PaulW: I think if the server removes the DANE record it should put the denial
of existence in the extension.  If the server properly, it should run for a bit
without the record.  Client can then run local policy.  When the client
connects and the record has disappeared it ought to do something; could live
with it going to the DNS to get the detail of existence.

PaulW (channeling Victor): Really want a time bound in the extension ...

VictorD: This extension is only going to be useful if useful.  If it can be
stripped then it offers no security advantage.  I'd like to see some purpose,
so the client has to have some kind of sticky mechanism.  Not convinced that it
should be only a client decision for the length of commitment.  Need to make
sure the extension supports denial of existence records.

ekr: I agree with VictorD's security analysis.  But, this goes exactly at the
purpose for this extension: Some people didn't want to get PKI certs and that
they'd rather get their keys from DANE.  If the rationale for the feature is
now that it is to stop the use of compromised PKI certificates.

rlb: We erred when we put two things under one label.  DANE can restrict or add
the set of certificate for a site.  It works just fine for the additive case. 
There's still incremental deployment it works just fine.  It's only when you go
into the restrictive cases.  One way to fix this problem is to scope the draft
to just the additive cases.

shumon: The tack we were taking is that PKIX and DANE co-exist.

dkg: I think it would be a mistake to tack client policy onto this draft.  It's
useful in other cases, e.g., dprive.

shumon: Some of the dprive implementations are already deploying some of this.

VictorD: To ekr's point, the reason I want the timer is precisely to address
the partial deployment case.  To rlb's, I think it's completely orthogonal.

?? (cz.nic): VictorD summarized what I wanted to say nicely.  So, I support
adding in the byte.

sherif (sp?): Is there an ability to turn it on in passive mode or logging?

shumon: The server will know what the client supports from the handshake and
will know it worked if the handshake completed.   But, we'll need to think
about if there's more that could be done.

PaulW: There's information already in the DNS and the pinning isn't needed
because the authoritative information is the DNS.  If this optimization can't
use, then your fall back is to not use the extension it's to go to the
authoritative source the DNS.  We don't need pinning in this draft; we only
need to say if the information is removed from the DNS then the authoritative
server needs to be updated.

Shumon: I get that but the problem with including full authenticated denial is
a barrier to partial deployment.

rlb: We have experience with incremental deployment in the WebPKI of extensions
to restrict authentication, CT has much more momentum than DANE.  But, we're
still very cautious.

dkg: +1 to what rlb said.  The one byte doesn't seem painful, but what we'd
argue about would be (i.e., client policy).

ekr: Any mechanism that requires you to ensure that the client has the same
experience across all servers is a non-starter.

ErikN: The key pinning stuff is a good thing to look at about how bad it
failed.  You can seriously brick yourself, but now it's being used for
ransomware attacks.  State of DNSSEC is also just not that great.

Shumon: We're talking about pinning about the existence of the keys not the
keys themselves.

VictorD: Erik's kind of missing the boat here, there's no bricking involved
here.  Bricking is more likely if you don't assert a time.  As to PaulW's
statement about falling back to DNS is just wrong too - it's just too slow. 
We're only asking for the server to keep offering the extension for a time of
it's choosing.

BenK: If the speculative thing wants to happen later it can because we have
lots of code points.

chair: Get a sense of the room to see if there is having just an additive
authentication case or whether we'd ?

PaulW: I don't really like the way you phrased the question because if I like
the extension but don't just want the additive use case you're telling me to
vote no.

chair: We're not saying the restrictive case can't be done it's just done in
another draft.

dkg: Asks more clarifying questions.

ekr: suggests another slant: Do we want pinning or not?

chair: If you think pinning is required to make this useful?  If you think this
draft is useful without pinning?  The latter was the sense of the room, and
this will be taken to the list.

KathleenM: There's been no changes to this draft - so can this draft be
approved today?

dkg: This additional detail doesn't even have to happen in this draft.

PaulW: If you added text about denial of existence it would really help those
that want to do more in the future.

KathleenM: Please post a new version without the 2119-language.

Exported Authenticators - Jonathan - 15min
  https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/

ChrisW: IS the source available for the Tamarin.

Jonathan: Yes - I can make it just email me for it.

ekr: Thanks for this.

mt: The difficult question for the room is whether we can about this threat
model?  There is a fix for this - we simply have to change the protocol.

Jonathan: There's two version of my fix - 1) no changes on the wire protocol,
and 2) or as a TLS extension.

mt: It would be a reasonable tweak to add it, but let's do it as a different
draft.

BenK: So yes I think we do care about it.

MikeB: Question about the proof that they are not bound together across master
secrets.

Jonathan: You could do something weird, but maybe not worth it.

Nick: Thanks for this.  I'm not entirely convinced that the compound
authentication adds a lot in the context of more certificates.  Threat model is
a little bizarre.

ekr: Not opposed to the changes here, but I have seen a lot work on partial
compromise and it turns out badly.  This wouldn't be seen as a huge
vulnerability if it was.

mt: We can probably progress the draft as is.

chair: To summarize, we'll move the draft forward as is and in another draft we
can do a stronger mechanism.

Certificate Compression - Alessandro/Victor - 10min
  https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/

Alessandro: We like an early code point assignment.

chair: Are there others that are planning to experiment with this extension?

WG: FF/NSS, Google, Fastly, Apple, FB, and Ericsson all interested in
experimenting.

ekr: We'll probably need to tweak this later, but yeah it's fine get one.

phb: Code point assignment should not be a barrier to experiment.

KyleE: Can we make the code points for the compression two bytes?

Alessandro: Not sure we need two, but when we will need more.

ekr: We should do two octets to support the various compression dictionaries.

Encrypted SNI - Christian - 10min
  https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

Kathleen: The draft is not balanced because it only lists the attacks and not
what it can be used for.

Christian: We can add some text in the draft to explain how SNI is used today.

chair: Are we okay splitting the introduction/list of
attacks/requirements/existing solution and then other drafts for solutions.

mt: This is a little different because nobody is really happy with any of the
solutions.  Seems reasonable to split.

chair: any violent objections?

Semi-Static DH in TLS1.3 - ekr&co - 10min
  https://datatracker.ietf.org/doc/draft-rescorla-tls13-semistatic-dh/

mt: Clarification Question: Are you looking to restore ss in 0-RTT?

Nick: Draft currently only discussed 1-RTT, but could support 0-RTT.

ekr: The current draft is just 1-RTT: ECDH with MAC replacing the signature. 
Removed the 0-RTT because we had a lot of problems rationalizing.  0-RTT might
be the source of some security problems.

Kenny: Isn't it suspectable to KCI attack?

ekr: No I don't think that is correct.  If you learn the client ephemeral you
can allow the connection to go through.  The ephemeral has no authentication
value.

Kenny: This is definitely going to need some security analysis.

ekr: There is some hand waiving the draft as well.

ChrisW: Changed the PR to get rid of the non-sense in the middle.  Proofs just
fall out.

Karthik: Loves the idea, glad to bring it back.  Had a bit longer than Kenny to
review the draft.  From the stand-point of the proofs already done: using the
SS to generate PSK for 0-RTT even in the first message is fine, using it as MAC
key in the certificate verify is fine, you can even use it for client
authentication, there is a KCI there but it almost inevitable.  But, the moment
you mix the key into the key schedule you'll need to redo all the proofs.

Nick: the major advantage is a linear key schedule.

ekr: It's really about requiring compromise of both the server ephemeral and
static to compromise the connection.  Mixing it in helps avoid a crummy PRNG.

Thyla: Could you quickly explain why we explained abandoned SS 0-RTT?

Nick: It was a matter of it being duplicative and it was more difficult to
reason.

Karthik: There might be a forwarding attack, but the binders might help here. 
BUT, analysis needs to be done.

Russ: Likes it.  Concerned about re-using the PSK slot.  Wanted to use it.  Can
we come up with a way to allow both to live in the same space?

PHB: Likes it.  Seems wrong to me that we use signatures in TLS.

ChrisW: Trying to look at modifying Kaas Tamarin model to get a better feeling
about the properties.

ekr: To Russ' point, we could easily support that with some kind of "V" to the
left.

Subodh: It would be nice if we could get rid of the if MAC check.

PSK+Cert Authentication - Russ - 10min
  https://datatracker.ietf.org/doc/draft-housley-tls-tls13-cert-with-extern-psk/

This presentation was bumped due to time.