Subject: [TLS] '15 TLS Fall Interim Minutes

From: Sean Turner <[email-masked]>
Date: Tue, 22 Sep 2015 16:27:35 -0700

I’ve gone ahead and posted the minutes/list of decisions to:

https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3

spt

---

From: Dave Garrett <[email-masked]>
Date: Tue, 22 Sep 2015 19:45:12 -0400

That has this:

> For padding, we reached a very rough consensus to start with the content type followed by all zeros (insert reasons why) over the explicit length option (insert reasons why).  DKG to propose a PR that we'll then fight out on the list.  See PR #253.

The "reasons why" that were discussed were not inserted. ;)

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Sep 2015 18:18:53 -0700

"Versions of TLS prior to 1.3 had limited support for padding. This padding
scheme was selected because it allows padding of any encrypted TLS record
by an arbitrary size (from zero up to TLS record size limits) without
introducing new content types. The design also enforces all-zero padding
octets, which allows for quick detection of padding errors.
"

On Tue, Sep 22, 2015 at 4:45 PM, Dave Garrett <[email-masked]>
wrote:

> > For padding, we reached a very rough consensus to start with the content
> type followed by all zeros (insert reasons why) over the explicit length
> option (insert reasons why).  DKG to propose a PR that we'll then fight out
> on the list.  See PR #253.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Dave Garrett <[email-masked]>
Date: Tue, 22 Sep 2015 22:03:37 -0400

Thanks.

What sort of errors are we trying to avoid by making sure implementations have to check for zeroed padding? Are we really worried some sloppy implementation is going to leave it uninitialized in a memory-unsafe language and just encrypt an arbitrary block of memory? This was mentioned at some point, and sounds really stupid, but planning for the stupid is probably a good idea.

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 23 Sep 2015 13:54:40 +0300

Minutes:

> ## Issue 223 - absolute or relative time
> 
> Leave as-is because a) switching to relative time is painful and it's
> not standalone, b) it's not entirely clear what > benefit we get from
> this, and c) we're already using absolute time for other things like
> certificates & OCSP.

One thing to note: The time is 4 octets, and 32 bit time since unix
epoch runs out a good bit faster than what I would like.

> ## Client Authentication
>
> We agreed that we need to support this in TLS 1.3.
> 
> ### How
> 
> 2. We will modify the data that's signed to conform with what Andrei
> is proposing provided we also terminate the transcript for key
> derivation before the CC/CCV.

Oh yay, Server 0-RTT?

> investigate: using the same construct for server/client sigs.

Huh? Don't both currently use the same construct, except for the
context string? Are you proposing to remove the context string or
what?

> 4. We agreed to not allow unsolicited client auth.

What will browser using HTTP/2 do if it receives client reauth request
when it has stream blocking identity change open?

- Open new connection and ??? to elict certificate request.
- Reset all streams that block identity change and then change identity.
- Reset all streams, change identity and retry request.
- Kill connection (e.g. PROTOCOL_ERROR).

(Just changing the identity is known to be insecure.)
 
> 5. We agreed to take out the ClientCertificatType from CertificateRequest.

Yeah, that one is not needed for anything.

> 6. We want a consolidated certificate message and certificate verify.

Just be careful that certificate is still signed, as many signature
algorithms fail to even properly bind the key, and nothing binds the
certificate.

And results of lack of binding for the certificate are not easy
for me to analyze.

> ## Data transfer limitation per connection (issue 125/4)
> 
> After quibbling with the math a bit, we need to specify how good we
> think the current ciphers are numbers.

Parse error. Does this mean something like "how much data current
ciphers can safely encrypt"?

> ## Include randoms directly in digital signatures
> 
> Issue 224
> 
> Consensus at the interim was that this has straightforward to do by
> just having the authentication server supply the ServerRandom was
> enough since it can search through the handshake transcript.

This assumes that authentication server receives full handshake and
not just handshake To-Be-Signed.

> # PRF designation in server certificate verify
> 
> Issue 227
> 
> Consensus was to leave as-is. A hash identifier isn't the way to
> solve this.  What you really need is contributory behavior to solve
> this issue.

Huh? This is about collisions between different hash algorithms. I
don't see how contributory behavior would help there (which is severly
limited by 1RTT maximum there).

Now, the issue is probably entierely theoretical and thus would not
need solving.

-Ilari

---

From: "Dang, Quynh" <[email-masked]>
Date: Wed, 23 Sep 2015 13:43:29 +0000

I am just curious why we need the content type here?

Quynh. 

________________________________________
From: TLS <[email-masked]> on behalf of Dave Garrett <[email-masked]>
Sent: Tuesday, September 22, 2015 7:45 PM
To: Sean Turner
Cc: [email-masked]
Subject: Re: [TLS] '15 TLS Fall Interim Minutes

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 23 Sep 2015 18:35:51 +0300

> I am just curious why we need the content type here?
 
The "outer" content type is needed for backward compatiblity. The
"inner" content type is needed for stuff like handshake vs. alert or
appdata vs. alert.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Sep 2015 08:50:16 -0700

> epoch runs out a good bit faster than what I would like.

I will fix this.

> > derivation before the CC/CCV.

Yes, the server can send immediately after receiving the first flight.

> context string? Are you proposing to remove the context string or

The idea on the table was to use an exported value to match Token binding.
Input needed here.

> algorithms fail to even properly bind the key, and nothing binds the

Yes, there was consensus to include the certificate.

> # Include randoms directly in digital signatures
> >
> > Issue 224
> >

There was a lot of confusion at the interim about whether the concern here
was an auth server at the attesting party or the relying party.

> Now, the issue is probably entierely theoretical and thus would not

There was confusion about this too. Could you provide a (perhaps contrived)
example of the attack you are concerned about and a mechanism which would
defend against it?

Thanks,
-Ekr

---

From: Adam Langley <[email-masked]>
Date: Wed, 23 Sep 2015 08:54:53 -0700

> epoch runs out a good bit faster than what I would like.

It's an unsigned value so it stretches until 2106 rather than the
standard epoch rollover at least.

> context string? Are you proposing to remove the context string or

The on-the-fly client auth messages were envisioned to sign the
certificate and a TLS Exporter value. That point was reflecting a
desire to have the handshake signatures sign the same thing if that
makes sense.

> (Just changing the identity is known to be insecure.)

"Unsolicited" means that the TLS server never sent an on-the-fly
CertificateRequest.

So the HTTP/2 situation would involve the server sending a
CertificateRequest which includes an opaque identifier. The
application protocol is free to decide that that identifier means and
HTTP/2 can decide that it's the stream id of the request that
triggered the need for a certificate. The client returns a certificate
(empty or not) and, in the mean time, the connection can continue
flowing. (And other CertificateRequests can be sent while one is
outstanding.)

> algorithms fail to even properly bind the key, and nothing binds the

Yes, that's understood.

> ciphers can safely encrypt"?

Yes.

> limited by 1RTT maximum there).

I think we quite possibly didn't understand the concern here. Could
you spell it out at more length?

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 23 Sep 2015 19:40:51 +0300

> The idea on the table was to use an exported value to match Token binding.

One would then presumably also have to eject SC/SCV from ExMS
computation so the same ExMS is available for SCV? 

Also, bit of an issue here is that OCSP stapling (which is pretty much
regarded as the only sane way to actually use OCSP) is specified to
use its own message, which goes between SC and SCV (RFC6066). 

So it would at least need to be moved somewhere in order to merge SC
and SCV.

> was an auth server at the attesting party or the relying party.

Well, AFAICT if the privileges are different, on attesting party
signing code has higher privileges. On relying party, verification code
has lower privileges.

(The "lower privileges verify" can come up e.g. if performing pubkey
extraction is unacceptable risk in main TLS code. In that case, I don't
think you can do better than just trust output of that code).

But in case of higher privilege sign, I think there might be ways to
try to prevent higher privilege signing code from being abused.

> example of the attack you are concerned about and a mechanism which would

Suppose one has different hash functions G and H. Server signs handshake
hash G(handshake_attacker_server). Attacker manipulates the handshake so
that H(handshake_client_attacker) = G(handshake_attacker_server).

If client accepts hash function H, that results in inpersonation.

In theory, you can't prove security against this attack starting from
assumption that G and H are secure hash functions.

In practice, if G and H are even near secure and not closely related,
that attack should be infeasible.

In contrast, if Tag(F) is identifier for F, different for each hash,
then:

Tag(G)|G(x) = Tag(H)|H(y)

Impiles G=H and G(x)=G(y), which contradicts collision resistance of
G.

-Ilari

---

From: Sean Turner <[email-masked]>
Date: Thu, 24 Sep 2015 11:01:44 -0400

> ciphers can safely encrypt”?

It does.  I’ll update the minutes.

spt

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Sep 2015 10:26:50 -0700

>> epoch runs out a good bit faster than what I would like.

If your fix is to make it bigger, that's just wasteful.

If your fix is to make it modulo 2^32, that's probably OK.  Any time
period that is significantly longer than we thing a configuration is
good for will do.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 25 Sep 2015 21:13:43 -0400

> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3

Issue #185 has the "discuss-seattle" tag on it, but I don't see mention of it in the minutes. (it's a suggestion from Karthik to generate a new client random on retry)

Did this get discussed?

https://github.com/tlswg/tls13-spec/issues/185

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Sep 2015 18:49:24 -0700

On Fri, Sep 25, 2015 at 6:13 PM, Dave Garrett <[email-masked]>
wrote:

> Issue #185 has the "discuss-seattle" tag on it, but I don't see mention of
> it in the minutes. (it's a suggestion from Karthik to generate a new client
> random on retry)
>
> Did this get discussed?
>
No.

-Ekr