Subject: [Uta] reminder: call for agenda items

From: Leif Johansson <[email-masked]>
Date: Mon, 03 Nov 2014 22:16:09 +0100

We are currently looking at a pretty thin agenda for Honolulu.

Agenda requests are not like wine: they don't improve with age.

	Cheers Leif

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 3 Nov 2014 22:16:02 +0000

Hi Leif,

> On 3 Nov 2014, at 21:16, Leif Johansson <[email-masked]> wrote:
> 

We should talk about Keith/Chris's document about use of TLS in email and latching, if either of them is going to be in Honolulu.

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 3 Nov 2014 23:22:26 +0100

> Agenda requests are not like wine: they don't improve with age.

(Not going to be at IETF91 - will try to participate remotely)

Viktor brought up OE several times - others did as well. Discussion
on how OE should be approached in this WG might be a good idea.

Most important is still to get the BCP documents out of the door.

No further ideas for now.
Aaron

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Wed, 5 Nov 2014 01:38:20 +0000

We posted the agenda earlier today. This is how it looks:

Meeting Agenda
UTA WG @IETF 91, Honolulu
Tuesday, Nov 11, 2014
0900-1130 Morning Session I, Coral 2

 9:00 -  9:20 Note Well and status update by the chairs
 9:20 - 10:00 "Deployable Enhanced Email Privacy (DEEP)"
	         Presented by Chris Newman
	         https://datatracker.ietf.org/doc/draft-newman-email-deep/
10:00 - 10:40 "The Token Binding Protocol Version 1.0"
	         Presented by Andrei Popov
	         https://datatracker.ietf.org/doc/draft-popov-token-binding/
10:40 - 11:10 Open discussion

We plan to resolve all comments on the BCP  before the meeting. We should have enough time to discuss the topics on the agenda and additional topics. It would be helpful if the parties interested in specific topics, which are in the charter of the WG (e.g., unauthenticated TLS, additional applications), consider specific proposals to discuss at the meeting and to keep the WG momentum going after Honolulu.

Thanks,
Leif and Orit.

> -----Original Message-----
> From: Uta [mailto:[email-masked]] On Behalf Of Leif Johansson
> Sent: Monday, November 03, 2014 1:16 PM
> To: [email-masked]
> Subject: [Uta] reminder: call for agenda items
> 
> 
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 05 Nov 2014 11:35:26 -0500

> Agenda requests are not like wine: they don't improve with age.

The TLS WG has been struggling with the "fallback dance" done by major
browsers (and possibly some other TLS clients.

The fallback dance represents an attempt to establish a TLS connection
to a peer that fails to implement the version-negotiated handshake
properly the first time.  As such, it's not part of the TLS protocol
itself, but more than one vendor appears to think it's necessary to
improve connectivity.

I wonder if that puts the fallback dance in the purview of UTA.  I am
unaware of any documents that explicitly describe the best practice for
doing such a thing, or if there are different kinds of fallback
approaches that different clients might pursue.

The recent https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
describes a mechanism for use by implementations that perform some sort
of fallback, without having any document to reference for fallback best
practices.

Some questions that come up around fallback:

 * should fallback address only choice of TLS versions (min and max), or
should it address other features like extensions and ciphersuites?  some
ciphersuites are not available in some versions, and very old versions
are extension intolerant

 * should fallback happen one level at a time, or are there arguments
for falling back all the way to weakest/most-compatible handshakes?

 * how should stateful TLS clients store state about what versions of
fallback were required to reach any given TLS server?

	--dkg

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Nov 2014 10:37:21 -0800

> fallback were required to reach any given TLS server?

I think that this would be a valuable discussion, and I'd help
contribute to a draft documenting the practice.

I can give details on what Firefox is currently doing and planning to do.

In release versions, we walk back based on a range of reasons.  This
includes TCP RST, which makes us trivially vulnerable to downgrade
attack.  So there you go, have it it folks.

The ratio of fallbacks for spurious reasons to fallbacks for genuine
reasons is huge, but we have not been prepared to make those version
intolerant sites inaccessible just yet.

In upcoming versions, we are being a lot less lenient in this regard.
In addition to lifting the floor by disabling SSL 3.0, we have the
downgrade SCSV.  We are also currently experimenting with lifting the
fallback floor to TLS 1.2, which is showing positive signs in
pre-release channels (though we may hold that experiment back for a
few cycles, we'll see).

The other thing we have is an initial handshake with RC4 suites (i.e.,
our weakest cipher suites) disabled.  If that fails for a narrower set
of reasons, we re-enable those suites, though we keep the version the
same.  This reduces the likelihood that we'll negotiate RC4 and
punishes sites for insisting on using it by adding latency.  I believe
that this is similar to how Internet Explorer has been operating since
version 10.

We don't fallback if we have previously been able to connect
successfully at a given version.  And we don't offer weak suites if we
have used the stronger ones.

We don't persist this state over browser restarts though.

I don't recall if we offer GCM in TLS 1.0 or 1.1, but that's the only
version-suite interaction I'm aware of that is currently relevant.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 6 Nov 2014 19:35:24 +0100

You volunteering to talk about this at UTA?

> 5 nov 2014 kl. 17:35 skrev Daniel Kahn Gillmor <[email-masked]>:
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 06 Nov 2014 13:47:13 -0500

On 11/06/2014 01:35 PM, Leif Johansson wrote:
> You volunteering to talk about [the TLS fallback dance] at UTA?

I don't have any draft written, but i am certainly willing to float the
topic and see if there is interest in the room in documenting something
like this.  Maybe 10 minutes at the meeting?

I should mention that i'm not a big fan of the fallback dance -- i'd
hope anything we wrote would advise against doing a fallback dance at
all, but "if you're going to go ahead and do it anyway, we hope you'll
do it like so..."

	--dkg

---

From: Leif Johansson <[email-masked]>
Date: Thu, 06 Nov 2014 20:27:14 +0100

On 2014-11-06 19:47, Daniel Kahn Gillmor wrote:
> I don't have any draft written, but i am certainly willing to
> float the topic and see if there is interest in the room in
> documenting something like this.  Maybe 10 minutes at the meeting?
> 
> I should mention that i'm not a big fan of the fallback dance -- 
> i'd hope anything we wrote would advise against doing a fallback 
> dance at all, but "if you're going to go ahead and do it anyway,
> we hope you'll do it like so..."

Sounds like a plan - we'll just put you in front of the room. Do you
plan to do slides?

	Cheers Leif

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 08 Nov 2014 14:33:19 -0800

> Sounds like a plan - we'll just put you in front of the room. Do you

Attached is a short html slide deck that i think will help get the
discussion going.

Thanks,

        --dkg