Subject: [TLS] chairs - please shutdown wiretapping discussion...

From: Stephen Farrell <[email-masked]>
Date: Sat, 8 Jul 2017 10:17:20 +0100

Sean/Joe,

This is a request that you, as chairs, shut down the distracting
wiretapping discussion, at least until DTLS1.3 is done.

I have planned to spend time reading draft 21 and DTLS, but that
won't happen if we keep having to fight off the latest attempts
to break TLS. I'd not be surprised if I weren't the only one
finding that distraction an irritating waste of time. Finishing
TLS1.3 and getting DTLS1.3 on the way surely needs to not be
constantly de-railed by these attempts to break TLS.

Therefore I'd ask that you declare this discussion closed for at
least that long (i.e until DTLS1.3 is done).

I'd also ask that you not allocate agenda time for wiretapping
in Prague.

Thanks,
S.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 8 Jul 2017 17:27:14 +0300

Hi Stephen,

Like you, I am very unhappy with this draft, and would not support its 
adoption as a WG draft. However I think that open discussion is in 
general good, and that the best venue for discussion of this draft is 
this mailing list. Even if some of this discussion devolves into generic 
"are we pro or against wiretapping" questions.

I don't think this is a significant distraction that could derail 
(D)TLS, moreover, you will recall that in Chicago several new drafts 
were adopted to the working group. So the WG does feel that TLS is in 
good enough shape that we can spend some bandwidth on other things.

Thanks,

     Yaron

On 08/07/17 12:17, Stephen Farrell wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 8 Jul 2017 15:33:10 +0100

> "are we pro or against wiretapping" questions.

FWIW I believe that we have had that discussion about breaking
tls over and over on this and other lists. I see no value in
doing it yet again, even if the proximate cause is a new variation
of the "here's a way to break tls" class of drafts. (Someday we
should find someone who'd document all the broken break-tls ideas
that have been rightly rejected over the years.)

> good enough shape that we can spend some bandwidth on other things.

Maybe I'm more easily distracted, at least by this topic;-)

Anyway, I'm fine that it's for the chairs to figure that out.

S.

---

From: Paul Turner <[email-masked]>
Date: Sat, 8 Jul 2017 15:31:38 +0000

Stephen,

You have referenced RFC 2804, which states the following in section 3:

"For the purposes of this memo, the following definition of wiretapping is used: Wiretapping is what occurs when information passed across the Internet from one party to one or more other parties is delivered to a third party"

The Internet Draft describes the use of static (EC)DHE for traffic entirely inside enterprise networks and intends to clearly state that it should not be used for "information passed across the Internet". If we have not been clear enough on that in the document, please tell us how we can be more clear. Assuming that the document is clear on this point, it would not then apply to "wiretapping" as defined in RFC 2804 (as Russ mentioned in an earlier email).

It would appear then that your concern is that an organization (or person) will disregard these two documents and use static (EC)DHE keys for their Internet connections. Is that correct?

Assuming that is correct, here are two considerations:

1. Why would an organization that wants to deliberately share the content of TLS encrypted Internet communications with a third party go to the trouble of implementing static (EC)DHE keys? Since they are an end point in the communications, they have all of the information (decrypted) and can share it with the third party without any need for static (EC)DHE keys (as I believe Watson pointed out). 

2. There is nothing in the TLS 1.3 protocol today that would prevent someone from implementing static (EC)DHE keys, even if this document is not published as an RFC.  If published, this RFC would make it clear that must not be done with TLS 1.3.

You have stated that there are alternatives by using proxies but enterprise organizations have stated this is not viable due to the complexity and scale of their network environments. Our collective objective is to increase the security of the Internet at large. As such, we have proposed this RFC in order to ensure that TLS 1.3 is adopted as broadly as possible inside of enterprises, which is an important step in increasing security. 

Consequently, we would ask that this discussion not be shut down as you request.

Paul

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Saturday, July 8, 2017 10:33
To: Yaron Sheffer <[email-masked]>; tls chair <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...

On 08/07/17 15:27, Yaron Sheffer wrote:
> this mailing list. Even if some of this discussion devolves into 
> generic "are we pro or against wiretapping" questions.

FWIW I believe that we have had that discussion about breaking tls over and over on this and other lists. I see no value in doing it yet again, even if the proximate cause is a new variation of the "here's a way to break tls" class of drafts. (Someday we should find someone who'd document all the broken break-tls ideas that have been rightly rejected over the years.)

S.

>> won't happen if we keep having to fight off the latest attempts to 
>> break TLS. I'd not be surprised if I weren't the only one finding 
>> that distraction an irritating waste of time. Finishing
>> I'd also ask that you not allocate agenda time for wiretapping in 
>> Prague.
>>
>> Thanks,
>> S.
>>
>>
>>

---

From: Tony Arcieri <[email-masked]>
Date: Sat, 8 Jul 2017 08:39:55 -0700

I was one of the people arguing my hardest against the BITS Security
proposal to continue to (ab)use RSA static keys to allow passive MitM, even
though TLS 1.3 had already moved forward on what I would call a more modern
protocol design of the sort I believe payments companies should embrace to
improve their security.

That said, if people do want to MitM themselves, I would rather there be a
single, easily detectable and very explicit way of doing so, as opposed to
sketchy, incompatible, ad hoc mechanisms. Furthermore, it would be nice to
have a clear answer for these users, less they continue to make (bad)
arguments that there is something fundamentally wrong with the design of
TLS 1.3 that makes it incompatible with "industry requirements".

Clearly there are echoes of the scary protocols of yesteryear, i.e.
Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the
image header you will discover he is quite familiar with these things, and
my personal presumption would be he is not displaying this image to show
his undying love of the Clipper chip, although perhaps he's an especially
crafty and duplicitous NSA sleeper agent.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 8 Jul 2017 16:44:56 +0100

> crafty and duplicitous NSA sleeper agent.

Reputations are irrelevant to how we evaluate this, though
I guess can be affected by the drafts one co-authors.

The relevant draft is proposing a wiretapping API for TLS.

That's inconsistent with RFC2804 no matter who proposes it.

S.

---

From: Tony Arcieri <[email-masked]>
Date: Sat, 8 Jul 2017 08:46:13 -0700

> That's inconsistent with RFC2804 no matter who proposes it.

Perhaps you should respond to the other two paragraphs in my message?

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 8 Jul 2017 16:59:50 +0100

On 08/07/17 16:31, Paul Turner wrote:
> "For the purposes of this memo, the following definition of
> wiretapping is used: Wiretapping is what occurs when information
> passed across the Internet from one party to one or more other
> parties is delivered to a third party"

The draft matches 2804 for many uses of TLS. E.g. anyone with
a hosted web service without access to the underlying http server
config. That's millions of people I believe. I do not believe
that is fixable.

> 
> The Internet Draft describes the use of static (EC)DHE for traffic
> entirely inside enterprise networks 

No it doesn't. There is no definition of enterprise network
not any mechanism for constraining deployment to such. Nor
can there be, other than pretense and pixie-dust.

> and intends to clearly state that
> it should not be used for "information passed across the Internet".

Yes, you may intend to say something like that but it's nonsense.
TLS is used in far too many contexts for that to be a reasonable
approach.

> If we have not been clear enough on that in the document, please tell
> us how we can be more clear. 

Remove the "standards track" header and go elsewhere is IMO
the only sensible outcome. It is not possible, nor useful,
to attempt to fix the draft as-is.

> Assuming that the document is clear on
> this point, it would not then apply to "wiretapping" as defined in
> RFC 2804 (as Russ mentioned in an earlier email).

Yes, you are both incorrect there.

> 
> It would appear then that your concern is that an organization (or
> person) will disregard these two documents and use static (EC)DHE
> keys for their Internet connections. Is that correct?
> 
> 1. Why would an organization that wants to deliberately share the

Coercion. Eg. a NSL in the US.

The proposed method is nice and simple for the web site and
from the point of a wiretapper puts the packet capture burden
nicely where it's wanted in the middle of the network.

> content of TLS encrypted Internet communications with a third party
> go to the trouble of implementing static (EC)DHE keys? Since they are
> an end point in the communications, they have all of the information
> (decrypted) and can share it with the third party without any need
> for static (EC)DHE keys (as I believe Watson pointed out).
> 
> 2. There is nothing in the TLS 1.3 protocol today that would prevent
> someone from implementing static (EC)DHE keys, even if this document
> is not published as an RFC.  If published, this RFC would make it
> clear that must not be done with TLS 1.3.

I would prefer that we impose more strict requirements on
the use of non-static public DH values and forget about this
draft entirely.

I will strongly object to every attempt to do this on the
standards-track with the IETF.

> 
> You have stated that there are alternatives by using proxies but
> enterprise organizations have stated this is not viable due to the> complexity and scale of their network environments.

And others disagreed with that and don't find any problems
with dropping rsa key transport. Assertions that this is
necessary are therefore false. It clearly is not needed for
lots of deployments.

> Our collective
> objective is to increase the security of the Internet at large. 

If so, you are going about it wrong - there BITS-related efforts
all seem to me to be in the direction of weakening security.

S.

> As
> such, we have proposed this RFC in order to ensure that TLS 1.3 is
> adopted as broadly as possible inside of enterprises, which is an
> important step in increasing security.
> 
> -----Original Message----- From: TLS [mailto:[email-masked]] On
> Behalf Of Stephen Farrell Sent: Saturday, July 8, 2017 10:33 To:
> Yaron Sheffer <[email-masked]>; tls chair
> <[email-masked]> Cc: [email-masked] Subject: Re: [TLS]
> chairs - please shutdown wiretapping discussion...
> 
> 
> 
>> Like you, I am very unhappy with this draft, and would not support
>> its adoption as a WG draft. However I think that open discussion is
>> in general good, and that the best venue for discussion of this
>> draft is this mailing list. Even if some of this discussion
>> devolves into generic "are we pro or against wiretapping"
>> questions.
> 
> FWIW I believe that we have had that discussion about breaking tls
> over and over on this and other lists. I see no value in doing it yet
> again, even if the proximate cause is a new variation of the "here's
> a way to break tls" class of drafts. (Someday we should find someone
> who'd document all the broken break-tls ideas that have been rightly
> rejected over the years.)
> 
>> 
>> (D)TLS, moreover, you will recall that in Chicago several new
>> drafts were adopted to the working group. So the WG does feel that
>> TLS is in good enough shape that we can spend some bandwidth on
>> other things.
> 
>>> Thanks, S.
>>> _______________________________________________ TLS mailing list 
>>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>> 
>> 
>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 8 Jul 2017 19:31:00 +0300

> On 8 Jul 2017, at 18:39, Tony Arcieri <[email-masked]> wrote:
> 
> I was one of the people arguing my hardest against the BITS Security proposal to continue to (ab)use RSA static keys to allow passive MitM, even though TLS 1.3 had already moved forward on what I would call a more modern protocol design of the sort I believe payments companies should embrace to improve their security.
> 
> That said, if people do want to MitM themselves, I would rather there be a single, easily detectable and very explicit way of doing so, as opposed to sketchy, incompatible, ad hoc mechanisms.

But all the MITM solutions, whether proxies or static DH are not easily detectable. Client-side proxies - the kind deployed by enterprises - are visible to clients (by the CA signing the proxy certificates) but not to the servers. This is implemented on the server, but is invisible to the client.  Even if the client rapid-fires several handshakes to see if the public key does not change, this is indistinguishable from the optimization of using the same key-pair for several seconds (without saving the private key).

> Furthermore, it would be nice to have a clear answer for these users, less they continue to make (bad) arguments that there is something fundamentally wrong with the design of TLS 1.3 that makes it incompatible with "industry requirements".
> 
> Clearly there are echoes of the scary protocols of yesteryear, i.e. Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the image header you will discover he is quite familiar with these things, and my personal presumption would be he is not displaying this image to show his undying love of the Clipper chip, although perhaps he's an especially crafty and duplicitous NSA sleeper agent.

It’s not about the reputations or motivations of the impressive list of authors. It’s about having the capability built into widely used products and libraries.

Suppose you have an Internet-facing server with TLS 1.2 and an ECDSA certificate and all supported ciphersuites are ECDHE-ECDSA.Suppose further that your server is using the ever popular Apache/modssl/openssl stack.

If you want to disable forward secrecy you have to either replace the certificate with an RSA certificate and move to all static RSA ciphersuites, or you need to replace your stack with something that does what this draft describes.

With this draft widely implemented it’s just a matter of turning the capability on.

We can’t really stop people implementing it, It’s not detectable by the client and an implementation would seem to be fully compliant with TLS 1.3.  And I don’t know how to implement this in such a way that it would work for “good” purposes but not for “bad” purposes, however one defines good and bad here.

---

From: Russ Housley <[email-masked]>
Date: Sat, 8 Jul 2017 13:17:36 -0400

Tony:

I want to highlight that draft-green-tls-static-dh-in-tls13-01 does not enable MitM.  The server does not share the signing private key, so no other party can perform a valid handshake.  Further, the server is choosing to use a (EC)DH key that was generated by the key manager, so it is quite different than the mandatory key escrow used in the Clipper Chip.

Russ

> On Jul 8, 2017, at 11:39 AM, Tony Arcieri <[email-masked]> wrote:
> 
> That said, if people do want to MitM themselves, I would rather there be a single, easily detectable and very explicit way of doing so, as opposed to sketchy, incompatible, ad hoc mechanisms. Furthermore, it would be nice to have a clear answer for these users, less they continue to make (bad) arguments that there is something fundamentally wrong with the design of TLS 1.3 that makes it incompatible with "industry requirements".
>

---

From: Tony Arcieri <[email-masked]>
Date: Sat, 08 Jul 2017 17:34:00 +0000

On Sat, Jul 8, 2017 at 11:17 AM Russ Housley <[email-masked]> wrote:

> I want to highlight that draft-green-tls-static-dh-in-tls13-01 does not
> enable MitM.  The server does not share the signing private key, so no
> other party can perform a valid handshake.
>

This method allows a middlebox to recover the plaintext of a TLS session.
While I took issue with Stephen's attempts to shut down conversations this
line of inquiry, I have a much, much stronger objection to downplay the
fact that this is still a self-inflicted MitM attack.

Let me be very clear: full plaintext recovery by a passive middlebox
absolutely is "MitM". Just because it does not allow full impersonation of
the server does not make it MitM. It is MitM, and we should be very clear
it is MitM.

Further, the server is choosing to use a (EC)DH key that was generated by
> the key manager, so it is quite different than the mandatory key escrow used
> in the Clipper Chip.
>

It enables the same ends: recovery of session plaintexts, and as I stated
on other threads I would personally prefer a more explicit key escrow
mechanism implemented as a TLS extension, which to some degree would
actually look a bit more like LEAP.

> --
Tony Arcieri

---

From: Eric Mill <[email-masked]>
Date: Sat, 8 Jul 2017 21:04:38 -0400

On Sat, Jul 8, 2017 at 11:31 AM, Paul Turner <[email-masked]> wrote:
> entirely inside enterprise networks and intends to clearly state that it
> should not be used for "information passed across the Internet". If we have
> not been clear enough on that in the document, please tell us how we can be
> more clear. Assuming that the document is clear on this point, it would not
> then apply to "wiretapping" as defined in RFC 2804 (as Russ mentioned in an
> earlier email).
>

The IETF's position as expressed in 2804 is on technologies that
"facilitate" wiretapping. What the RFC says the protocol is "intended for"
in layer 8 isn't as relevant as how the technology could easily be used,
once standardized.

The burden on the proposers should be to demonstrate that the technology
can *only* be used in the manner of its stated intent, even if the humans
involved were all hostile, or compelled to be hostile.

You have stated that there are alternatives by using proxies but enterprise
> organizations have stated this is not viable due to the complexity and
> scale of their network environments.

Not all statements are created equal. Stating that proxies can technically
fulfill this function is objective, and can be backed up in clear technical
detail.

Stating that proxies are not viable for enterprise organizations due to the
scale and complexity of their network environments is subjective, generally
not well-detailed, and much more open to skepticism.

The burden on the proposers should be to address this skepticism, and to
justify to the working group why enterprises that are large enough and
well-funded enough to have such vast and complex networks cannot invest in
upgrading those networks to an approach that doesn't rely on directly
weakening their own connection security and potentially the security of
others' through the unintended consequences of formalizing this RFC.

> Our collective objective is to increase the security of the Internet at
> large. As such, we have proposed this RFC in order to ensure that TLS 1.3
> is adopted as broadly as possible inside of enterprises, which is an

So is increasing the use of forward secret connections within enterprise
network environments. Why should the TLS WG accept the argument that legacy
approaches to monitoring enterprise networks are worth risking the
weakening of the product of years of hard work?

-- Eric

-----Original Message-----
> FWIW I believe that we have had that discussion about breaking tls over
> and over on this and other lists. I see no value in doing it yet again,
> even if the proximate cause is a new variation of the "here's a way to
> break tls" class of drafts. (Someday we should find someone who'd document
> all the broken break-tls ideas that have been rightly rejected over the
> years.)
>
> >

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sat, 8 Jul 2017 23:23:38 -0700

On Sat, Jul 8, 2017 at 6:04 PM, Eric Mill <[email-masked]> wrote:

>
> Stating that proxies are not viable for enterprise organizations due to
> the scale and complexity of their network environments is subjective,
> generally not well-detailed, and much more open to skepticism.
>

TLS1.3 isn't a debate, or a legal argument. It's an actual thing in the
world that we'd like to see succeed and be as pervasive as possible. The
folks reporting saying it won't work are doing us a favor, they don't owe
us anything.

So when those users show up saying "This won't work for me", it is better
to have a very open mind and make every attempt to understand them. If
their explanations are not clear, then burrow further. Be charitable and
lean as heavily towards why they may be right, search for good reasoning in
/their/ favor, and state it as well as it can possibly be presented. Only
on those terms try to tackle it with alternatives.

If the presenters are wrong, and the skepticism is merited, that approach
will still work. But if they happen to be right, it makes the alternatives
or adaptations more clear, or the necessity for them more obvious.
Dismissing concerns with trivial and shallow analysis can serve to diminish
the success of TLS1.3, because the users don't need to adopt it, and can
end up blocking it and creating a failure of "TLS 1.3 doesn't work in XXX
environments".

-- 
Colm

---

From: Dan Brown <[email-masked]>
Date: Sun, 9 Jul 2017 14:22:44 +0000

I agree with Stephen: this ID and all its detailed discussion should move over to the Intranet ETF and/or the Internet Subverting TF (wherever such a TF may be).‎ TLS 1.3 is already a big change.

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message
From: Stephen Farrell
Sent: Saturday, July 8, 2017 5:17 AM
To: tls chair
Cc: [email-masked]
Subject: [TLS] chairs - please shutdown wiretapping discussion...

Sean/Joe,

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 9 Jul 2017 21:16:15 +0100

> end up blocking it and creating a failure of "TLS 1.3 doesn't work in XXX

Over the last ~ year and a half, since these folks have
started openly bemoaning the lack of rsa key transport
in tls1.3, I'd guess there've been a few hundred messages
on the list on that topic alone. That is not dismissal,
that's having had more than a fair hearing. As you note,
it is entirely ok that they do not get what they want at
the end of that IMO extremely over-extended process.

Again, I would ask that the chairs chime in as to whether
they would like to see this distraction/discussion be
continued or stopped.

S.

---

From: Sean Turner <[email-masked]>
Date: Mon, 10 Jul 2017 08:04:26 -0400

Message received.  Expect a response in a couple of hours.

spt

> On Jul 8, 2017, at 05:17, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Sean/Joe,
>

---

From: Sean Turner <[email-masked]>
Date: Mon, 10 Jul 2017 12:57:57 -0400

Stephen,

After some discussion amongst the chairs, we have decided to not shut down the discussion about draft-green-tls-static-dh-in-tls13.  We are not shutting down this discussion because this topic is relevant to the constituents on both sides of the issue in the working group and there is a concrete proposal to discuss.  Now that we know the authors are going to ask for WG adoption, the resulting working group's consensus or lack of consensus on this approach will be useful information for other discussions that will happen in the broader IETF community regardless of the outcome.  Further, we intend for consensus on the issue to be called quickly.

We also do not believe that this discussion is derailing the TLS1.3 draft, we are consistently surprised by the WG’s bandwidth and the draft is out for a 2nd targeted WGLC.  As far as DTLS1.3, the specification is coming along but is not at a critical point where we believe this discussion will greatly detract from its development.

J&S

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jul 2017 20:29:26 +0100

On 10/07/17 17:57, Sean Turner wrote:
> Stephen,
> 
> After some discussion amongst the chairs, we have decided to not shut
> down the discussion about draft-green-tls-static-dh-in-tls13.  

Ok, that's your call. But a bad call IMO.

This topic, if not the specific draft, was already the subject
of significant debate during which the use of static DH values
was raised. I think you are putting the WG participants through
repetitive calls here for no good reason. (The fact that a -01
was emitted and new authors added is not IMO a good reason.)

So I'd ask that you review the previous related threads and
consider again if the basic idea behind this hasn't already
been rejected by the WG in the recent past.

In text below I'll assume you do that but decide to have an
adoption call nonetheless (though I hope you review the mail
archive and decide to reconsider).

> We are
> not shutting down this discussion because this topic is relevant to
> the constituents on both sides of the issue in the working group and
> there is a concrete proposal to discuss. 

That seems to me to be a recipe for whack-a-mole - we have seen
these break-tls proposals over and over and handling it your way
seems like it'll encourage more of 'em.

> Now that we know the
> authors are going to ask for WG adoption, the resulting working
> group's consensus or lack of consensus on this approach will be
> useful information for other discussions that will happen in the
> broader IETF community regardless of the outcome.  

I have no idea of the process problems that that'll create if
the WG go crazy and decide to adopt this despite it conflicting
with 2804 and given all the inevitable follow up wiretapping
additions that'll be proposed for quic and pretty much everything
else, if the TLS wg are seen to "fold." Seems like a recipe for
lots of confused process lawyering to me, but hopefully that'll
not turn out to be an issue.

> Further, we intend
> for consensus on the issue to be called quickly.

I'm against it:-)

> 
> We also do not believe that this discussion is derailing the TLS1.3
> draft, we are consistently surprised by the WG’s bandwidth and the
> draft is out for a 2nd targeted WGLC.  As far as DTLS1.3, the
> specification is coming along but is not at a critical point where we
> believe this discussion will greatly detract from its development.
> 

You did not respond about the Prague agenda. I continue to ask that
you not give this bad idea more f2f time. If you do give it time,
then I'd ask for equal time to debunk this bad idea. But better to
have zero time.

S.

>> that distraction an irritating waste of time. Finishing TLS1.3 and
>> getting DTLS1.3 on the way surely needs to not be constantly
>> de-railed by these attempts to break TLS.
>>

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Jul 2017 15:06:12 -0500

> Ok, that's your call. But a bad call IMO.

IMO there's a trivial fix: make draft-green-tls-static-dh-in-tls13 an
individual submission targeting Informational, and allow discussion on
the TLS WG without making it a WG item (meaning, too, that no WG
milestone should refer to it).

Given that the entire text of draft-green-tls-static-dh-in-tls13 looks
like it's informational ("if you want key escrow with TLS 1.3, this is
how you might do it"), Informational looks right.

(BCP would not be appropriate, since on the cap-I Internet we would want
this deployed.  And as to intranets, we don't care.)

An I-D specifying a protocol for doing key auditing for escrow purposes
could be Standards-Track, since it could be a protocol that many need to
interop with.  But it wouldn't necessarily be a TLS WG item.  And we
might still want it to be Informational (since we can specify protocols
that way as well).

Nico
--

---

From: Sean Turner <[email-masked]>
Date: Mon, 10 Jul 2017 17:22:45 -0400

> On Jul 10, 2017, at 15:29, Stephen Farrell <[email-masked]> wrote:
> 

Thanks for point this out.  We have adjusted the agenda but only to make room for 
draft-ietf-tls-dnssec-chain-extension and to rearrange the topics:
https://www.ietf.org/proceedings/99/agenda/agenda-99-tls-01
Note that the time allocated for this topics includes discussion time, where I have no there will be a mad dash to get to the mic.

spt