Subject: [Uta] Alissa Cooper's Discuss on draft-ietf-uta-tls-bcp-09: (with DISCUSS and COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 17 Feb 2015 11:49:51 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-uta-tls-bcp-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for all your work on this.

I have a quick question about how we expect this document to be used
within the IETF. I note that the bulk of the requirements/recommendations
are directed at implementers, not protocol designers/specs. And Section
4.2.1 also says:

"This document does not change the mandatory-to-implement TLS cipher
   suite(s) prescribed by TLS or application protocols using TLS. ...
   Implementers should consider the interoperability gain against the
   loss in security when deploying that cipher suite.  Other application
   protocols specify other cipher suites as mandatory to implement
   (MTI)."

So my question is whether we should consider this document effectively
silent about the choice of cipher suites to be used when we standardize a
new application protocol in the IETF, or an update to an existing
protocol. That is the impression that I get from the text right now, and
it doesn't quite match the way we've been using/citing the document in
some recent discussions of other drafts. On the other hand, if we're
expecting new or updated application protocol specs to conform to or take
into account the recommendations in this document, I think that should be
made more clear.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Sec 4.1:
128-bit ciphers are expected to remain secure for at least several years,
and
      256-bit ciphers "until the next fundamental technology
      breakthrough".
    
Is the quoted text quoting something? If not, why is it in quotes?

-- Sec 5:
Although the list here is non-exhaustive, it seems odd to me that no DTLS
examples are listed.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 13:07:14 -0700

Hi Alissa, thanks for your feedback. Comments inline.

On 2/17/15 12:49 PM, Alissa Cooper wrote:
> protocol.

If an application protocol wishes to follow the recommendations here, 
someone needs to write a document that says so. As an example, 
draft-ietf-uta-xmpp (recently finished WGLC) updates RFC 6120:

https://datatracker.ietf.org/doc/draft-ietf-uta-xmpp/

> That is the impression that I get from the text right now, and
> some recent discussions of other drafts.

Do you have examples?

> On the other hand, if we're

Given that other folks have been confused on this point, I tend to agree.

To my knowledge, that is not a quote from another text, but I will 
double-check with my co-authors. Conceptually it could refer to 
something like a special-purpose "sieving machine" of the sort mentioned 
in RFC 3766.

> Although the list here is non-exhaustive, it seems odd to me that no DTLS

Good point. Mentioning, say, SRTP and SCTP seems like a good idea.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 13:07:14 -0700

Do you have examples?

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 17 Feb 2015 22:40:32 +0200

> something like a special-purpose "sieving machine" of the sort mentioned

This is from Bruce Schneier: "In fact, we cannot even imagine a world 
where 256-bit brute force searches are possible. It requires some 
fundamental breakthroughs in physics and our understanding of the 
universe." But personally, I would remove the quotes.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 17 Feb 2015 22:40:32 +0200

Thanks,
	Yaron

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 13:52:36 -0700

> Given that other folks have been confused on this point, I tend to agree.

I propose that we add the following text after the bullet points at the 
start of Section 5 ("Applicability Statement"):

    This document does not modify various details (e.g., cipher suites)
    prescribed by application protocols that use TLS or DTLS.  If the
    implementation and deployment community that uses such an application
    protocol wishes to modernize its usage of TLS or DTLS to be
    consistent with the best practices recommended here, it needs to
    publish a document that explicitly updates the existing application
    protocol definition.  One example of such a document is
    [I-D.ietf-uta-xmpp].

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 13:52:36 -0700

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Pete Resnick <[email-masked]>
Date: Tue, 17 Feb 2015 15:11:24 -0600

On 2/17/15 2:07 PM, Peter Saint-Andre - &yet wrote:

> someone needs to write a document that says so.

What about new protocols?

>> some recent discussions of other drafts.

http://tools.ietf.org/html/draft-ietf-paws-protocol-20#section-7

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Pete Resnick <[email-masked]>
Date: Tue, 17 Feb 2015 15:11:24 -0600

pr

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 17 Feb 2015 16:29:52 -0500

> What about new protocols?

HTTPbis included a blacklist of the registered TLS cipher suites  that
should not be used, with one that is on the registered list as MTI.  Is
something like that needed more generally or is cleanup of the TLS registry
of recommendations needed?
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2 Section 9.2 and
appendix A
TLS registry:
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

The recommended list in this draft, section 4.2 includes cipher suites that
were all registered for use with TLS 1.2 as far as I can tell.

If this doesn't help, just ignore.

-Kathleen

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 17 Feb 2015 16:29:52 -0500

-Kathleen

-- 

Best regards,
Kathleen

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 14:31:16 -0700

> What about new protocols?

Right, I was thinking of existing protocols. For new protocols, I do 
think it makes sense to reference this BCP. Something vaguely along the 
lines of what we did in RFC 6648 seems sensible.

> http://tools.ietf.org/html/draft-ietf-paws-protocol-20#section-7

Thanks. That reference seems fine to me.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 14:31:16 -0700

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Pete Resnick <[email-masked]>
Date: Tue, 17 Feb 2015 15:59:37 -0600

On 2/17/15 3:31 PM, Peter Saint-Andre - &yet wrote:
> think it makes sense to reference this BCP.

But that is exactly what the PAWS document does, and in fact PAWS was 
asked to do so by the security ADs, if I recall correctly.

pr

> Something vaguely along the lines of what we did in RFC 6648 seems 
> sensible.
>

---

From: Pete Resnick <[email-masked]>
Date: Tue, 17 Feb 2015 15:59:37 -0600

pr

---

From: Pete Resnick <[email-masked]>
Date: Tue, 17 Feb 2015 16:02:27 -0600

> asked to do so by the security ADs, if I recall correctly.

Bah. I misread your response. We are in violent agreement. (*facedesk*)

---

From: Pete Resnick <[email-masked]>
Date: Tue, 17 Feb 2015 16:02:27 -0600

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 17 Feb 2015 15:28:31 -0800

On Feb 17, 2015, at 12:52 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:

> I propose that we add the following text after the bullet points at the start of Section 5 ("Applicability Statement"):
> 

Thanks Peter. I think this is good, but does not get to Pete’s point about new protocols. And in that case if the expectation is that new protocols will conform to this BCP’s recommendations, that should be made explicit I think.

The text above also slightly skirts the case where an existing protocol is being updated for some other reason besides modernizing its TLS/DTLS usage. So if the Foo protocol required support for weaker ciphers than what the BCP requires/recommends, and someone writes Foobis for the purpose of making non-TLS-related updates, do we expect Foobis to conform to the BCP? Or continue to require support for weaker ciphers for interoperability purposes? Or both? Or leave it up to the consensus at the time of Foobis publication? Would be good to clarify that case further I think.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 17 Feb 2015 15:28:31 -0800

Alissa

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 18 Feb 2015 01:33:47 +0200

> The text above also slightly skirts the case where an existing protocol is being updated for some other reason besides modernizing its TLS/DTLS usage. So if the Foo protocol required support for we…

In fact I think the text addresses exactly this case, by making the 
update conditional on "the community... wishing to modernize [the 
protocol's] usage of TLS". In other words, what works for one community 
may not work for another, e.g. for reasons of interoperability.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 18 Feb 2015 01:33:47 +0200

Thanks,
	Yaron

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 16:53:02 -0700

On 2/17/15 4:33 PM, Yaron Sheffer wrote:
>>> I propose that we add the following text after the bullet points at
>>> the start of Section 5 ("Applicability Statement"):
>>>
>> Thanks Peter. I think this is good, but does not get to Pete’s point
>> about new protocols. And in that case if the expectation is that new
>> protocols will conform to this BCP’s recommendations, that should be
>> made explicit I think.

Right, that is a somewhat separate issue from the paragraph above (which 
should say "prescribed by existing application protocols"). We also had 
an ordering issue with the email threads here, and I agree that we need 
to have some text about new protocols, too. I'll propose something 
separately about those.

>> The text above also slightly skirts the case where an existing
>> protocol is being updated for some other reason besides modernizing
>> its TLS/DTLS usage. So if the Foo protocol required support for weaker
>> ciphers than what the BCP requires/recommends, and someone writes
>> Foobis for the purpose of making non-TLS-related updates, do we expect
>> Foobis to conform to the BCP? Or continue to require support for
>> weaker ciphers for interoperability purposes? Or both? Or leave it up
>> to the consensus at the time of Foobis publication? Would be good to
>> clarify that case further I think.
>>
>

I agree with Yaron here. One example that came up during WG discussion 
of this document was certain IoT protocols, since the relevant devices 
might not have support for all of the necessary algorithms. Instead of 
building in an explicit carve-out for those protocols, we felt it was 
better for those communities to decide how they wanted to proceed.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 16:53:02 -0700

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 17 Feb 2015 16:00:44 -0800

On Feb 17, 2015, at 3:53 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:

> I agree with Yaron here. One example that came up during WG discussion of this document was certain IoT protocols, since the relevant devices might not have support for all of the necessary algorithms. Instead of building in an explicit carve-out for those protocols, we felt it was better for those communities to decide how they wanted to proceed.

Ok, fair enough. I would personally find it a little better to make that more explicit in the document, but will not quibble over it.

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 17 Feb 2015 16:00:44 -0800

Thanks,
Alissa

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 17:21:54 -0700

On 2/17/15 5:00 PM, Alissa Cooper wrote:
>>>> its TLS/DTLS usage.

Actually, we're not saying anything about the reasons why a community 
might be modernizing its core specifications, our statement was about 
wishing to modernize the security profile. There are no protocol police, 
but if I were still an AD I'd strongly encourage any community working 
on a bis effort for other reasons to apply these best practice 
recommendations while they're at it. :-)

>>>> So if the Foo protocol required support for weaker

Here is updated, proposed text for Section 5...

###

5.  Applicability Statement

    The recommendations of this document primarily apply to the
    deployment of application layer services that are most commonly used
    with TLS and DTLS on the Internet today.  Examples include, but are
    not limited to:

    o  Operators of web services that wish to protect HTTP traffic with
       TLS.

    o  Operators of email services who wish to protect IMAP, POP3, or
       SMTP traffic with TLS.

    o  Operators of instant-messaging services who wish to protect XMPP
       or IRC traffic with TLS.

    o  Operators of realtime media services who wish to protect SRTP
       traffic with DTLS.

    This document does not modify the implementation and deployment
    recommendations (e.g., mandatory-to-implement cipher suites)
    prescribed by existing application protocols that employ TLS or DTLS.
    If the community that uses such an application protocol wishes to
    modernize its usage of TLS or DTLS to be consistent with the best
    practices recommended here, it needs to publish a document that
    explicitly updates the existing application protocol definition (one
    example of such a document is [I-D.ietf-uta-xmpp]).

    Designers of new application protocols developed through the Internet
    Standards Process are expected to conform to the best practices
    recommended here, unless they provide documentation of compelling
    reasons that would prevent such conformance (e.g., widespread
    deployment on constrained devices that lack support for the necessary
    algorithms).

###

I somewhat fear that we're opening a can of worms with the final 
paragraph, but so be it.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 17:21:54 -0700

###

###

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 18:23:42 -0700

On 2/17/15 2:29 PM, Kathleen Moriarty wrote:
>
>
> On Tue, Feb 17, 2015 at 4:11 PM, Pete Resnick <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         If an application protocol wishes to follow the recommendations
>         here, someone needs to write a document that says so.
>
>
> something like that needed more generally or is cleanup of the TLS
> registry of recommendations needed?

It might be, but that's probably a job for the TLS WG. :-)

> https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2 Section 9.2
> and appendix A
> TLS registry:
> The recommended list in this draft, section 4.2 includes cipher suites
> that were all registered for use with TLS 1.2 as far as I can tell.

Correct! :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 18:23:42 -0700

Correct! :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Leif Johansson <[email-masked]>
Date: Wed, 18 Feb 2015 11:45:22 +0100

> http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

I think there is a very clear difference between MTI and deployment
best practice and the text above is trying to express that difference.

I don't think UTA wants a piece of the action over at CFRG - that group
doesn't need another set of "helpful" hands IMHO :-)

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Wed, 18 Feb 2015 11:45:22 +0100

Cheers Leif

---

From: Ralph Holz <[email-masked]>
Date: Wed, 18 Feb 2015 21:52:11 +1100

Hi,

> I somewhat fear that we're opening a can of worms with the final

I am not against making this change - but let's recall that we already have
had the IoT community utter serious concerns that the BCP might affect
their efforts. It is not a straight-forward call to make.

Ralph

---

From: Ralph Holz <[email-masked]>
Date: Wed, 18 Feb 2015 21:52:11 +1100

Hi,

Ralph

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Feb 2015 10:59:48 +0000

Hi Leif,

> On 02/17/2015 08:49 PM, Alissa Cooper wrote:
  [snip]
> doesn't need another set of "helpful" hands IMHO :-)
As a CFRG co-chair, I thank you for not trying to be "helpful" :-).

I think the difference is that UTA picks from documented ciphers, while 
CFRG might recommend new ones. So at least there is some logical 
separation of duties.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Feb 2015 10:59:48 +0000

Hi Leif,

  [snip]

---

From: Leif Johansson <[email-masked]>
Date: Wed, 18 Feb 2015 12:06:37 +0100

> As a CFRG co-chair, I thank you for not trying to be "helpful" :-).

You are welcome.

> CFRG might recommend new ones. So at least there is some logical

That is my understanding as chair and that is what the authors are
trying to get across by the paragraph we're talking about.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Wed, 18 Feb 2015 12:06:37 +0100

You are welcome.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Wed, 18 Feb 2015 12:07:58 +0100

On 02/18/2015 11:52 AM, Ralph Holz wrote:
> I am not against making this change - but let's recall that we already
> have had the IoT community utter serious concerns that the BCP might
> affect their efforts. It is not a straight-forward call to make.
> 
> Ralph

The idea of making best practice sorta-kinda normative makes me a bit
queasy.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Wed, 18 Feb 2015 12:07:58 +0100

Cheers Leif

---

From: Ralph Holz <[email-masked]>
Date: Wed, 18 Feb 2015 23:18:29 +1100

Hi,

> The idea of making best practice sorta-kinda normative makes me a bit
So.... do we really need any sort of language to express a hope or can we
just keep it silent and see if developers of new protocols turn to the BCP
for inspiration anyway, hope expressed or not? I think they would.

Ralph

---

From: Ralph Holz <[email-masked]>
Date: Wed, 18 Feb 2015 23:18:29 +1100

Hi,

Ralph

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Wed, 18 Feb 2015 17:44:36 +0000

I do think that we need to explicitly address the new application designers case since this question has been raised (and addressed) multiple times in the past.
Why wouldn't we just soften the language along the following lines:

"Designers of new application protocols developed through the Internet Standards Process are expected to take into consideration the best practices recommended here and reference them in their recommendations. In case of disparity, it is encouraged to document the reasons leading to different recommendations. This will help the readers to avoid any possible confusion and prevent segregation of the Internet community."

Orit.

From: Ralph Holz [mailto:[email-masked]] 
Sent: Wednesday, February 18, 2015 4:18 AM
To: Leif Johansson
Cc: Peter Saint-Andre - &yet; Alissa Cooper; [email-masked]; [email-masked]; Orit Levin (LCA); Yaron Sheffer; [email-masked]; IESG
Subject: Re: [Uta] Alissa Cooper's Discuss on draft-ietf-uta-tls-bcp-09: (with DISCUSS and COMMENT)

Hi,

So.... do we really need any sort of language to express a hope or can we just keep it silent and see if developers of new protocols turn to the BCP for inspiration anyway, hope expressed or not? I think they would.

Ralph

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Wed, 18 Feb 2015 17:44:36 +0000

Orit.

Hi,

Ralph

---

From: Pete Resnick <[email-masked]>
Date: Wed, 18 Feb 2015 12:53:47 -0600

> The idea of making best practice sorta-kinda normative makes me a bit

Let's not forget that a BCP *is* a community consensus document. It 
means that the IETF community has decided that we do things a particular 
way. A BCP *is* normative.

I think it's quite reasonable for the document to say, "MUST NOT 
negotiate SSLv2" because doing otherwise causes harm to implementations 
and to the net in general. There are no Internet police. If you violate 
that MUST NOT, you don't go to jail. We're simply saying that they way 
to do security properly on the Internet is that you MUST NOT use SSLv2.

So I don't have a problem with the document saying, "Existing protocols 
have tradeoffs to make between interoperability and security, so we (the 
IETF) expect those tradeoffs to be made. New protocols we (the IETF) 
expect to abide by the requirements and recommendations in this document 
unless they give some serious justification for not doing so." That's 
what we mean by a BCP.

pr

---

From: Pete Resnick <[email-masked]>
Date: Wed, 18 Feb 2015 12:53:47 -0600

pr

---

From: Pete Resnick <[email-masked]>
Date: Wed, 18 Feb 2015 13:15:19 -0600

On 2/18/15 1:08 PM, Leif Johansson wrote:
>> 18 feb 2015 kl. 19:54 skrev Pete Resnick<[email-masked]>:
>>
>>      
>> Let's not forget that a BCP *is* a community consensus document. It means that the IETF community has decided that we do things a particular way. A BCP *is* normative.
>>
>> I think it's quite reasonable for the document to say, "MUST NOT negotiate SSLv2" because doing otherwise causes harm to implementations and to the net in general. There are no Internet police. If you violate that MUST NOT, you don't go to jail. We're simply saying that they way to do security properly on the Internet is that you MUST NOT use SSLv2.
>>
>> So I don't have a problem with the document saying, "Existing protocols have tradeoffs to make between interoperability and security, so we (the IETF) expect those tradeoffs to be made. New protocols we (the IETF) expect to abide by the requirements and recommendations in this document unless they give some serious justification for not doing so." That's what we mean by a BCP.
>>      
> hmm yeah sure
>    

"During a lecture the Oxford linguistic philosopher J. L. Austin made 
the claim that although a double negative in English implies a positive 
meaning, there is no language in which a double positive implies a 
negative. To which [philosopher Sidney] Morgenbesser responded in a 
dismissive tone, 'Yeah, right.'"

pr

---

From: Pete Resnick <[email-masked]>
Date: Wed, 18 Feb 2015 13:15:19 -0600

pr

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 18 Feb 2015 12:16:22 -0700

> unless they give some serious justification for not doing so." That's

Exactly. Yesterday I proposed the following text for the section on 
applicability:

Does that meet our needs?

Peter

---

From: "Leif Johansson" <[email-masked]>
Date: Wed, 18 Feb 2015 20:08:43 +0100

> 18 feb 2015 kl. 19:54 skrev Pete Resnick <[email-masked]>:
> 

hmm yeah sure

---

From: "Leif Johansson" <[email-masked]>
Date: Wed, 18 Feb 2015 20:08:43 +0100

> So I don't have a problem with the document saying, "Existing protocols have tradeoffs to make between interoperability and security, so we (the IETF) expect those tradeoffs to be made. New protocols we (the IETF) expect to abide by the requirements and recommendations in this document unless they give some serious justification for not doing so." That's what we mean by a BCP

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 18 Feb 2015 12:16:22 -0700

Peter

---

From: "Leif Johansson" <[email-masked]>
Date: Wed, 18 Feb 2015 20:18:49 +0100

> 18 feb 2015 kl. 20:16 skrev Peter Saint-Andre - &yet <[email-masked]>:
> 
> Exactly. Yesterday I proposed the following text for the section on applicability:
> 

wfm

---

From: "Leif Johansson" <[email-masked]>
Date: Wed, 18 Feb 2015 20:18:49 +0100

wfm

---

From: "Leif Johansson" <[email-masked]>
Date: Wed, 18 Feb 2015 20:21:01 +0100

> 18 feb 2015 kl. 20:15 skrev Pete Resnick <[email-masked]>:
> 
> "During a lecture the Oxford linguistic philosopher J. L. Austin made the claim that although a double negative in English implies a positive meaning, there is no language in which a double positive implies a negative. To which [philosopher Sidney] Morgenbesser responded in a dismissive tone, 'Yeah, right.'"
> 
> pr

hillarious :-)

I meant to express support unhindered by enthusiasm

---

From: "Leif Johansson" <[email-masked]>
Date: Wed, 18 Feb 2015 20:21:01 +0100

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Wed, 18 Feb 2015 20:16:12 +0000

Just to clarify, I have no objection to the original text by Peter.
Cheers,
Orit.

> -----Original Message-----
> From: Leif Johansson [mailto:[email-masked]]
> Sent: Wednesday, February 18, 2015 11:19 AM
> To: Peter Saint-Andre - &yet
> Cc: Pete Resnick; Ralph Holz; [email-masked]; [email-masked]; Alissa Cooper;
> Orit Levin (LCA); Yaron Sheffer; [email-masked]; IESG

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Wed, 18 Feb 2015 20:16:12 +0000

> >> to do security properly on the Internet is that you MUST NOT use SSLv2

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 18 Feb 2015 15:23:34 -0500

On Wed, Feb 18, 2015 at 2:16 PM, Peter Saint-Andre - &yet <[email-masked]>
wrote:

> That meets my understanding of how we have been using this draft.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 18 Feb 2015 15:23:34 -0500

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 18 Feb 2015 12:39:54 -0800

> Does that meet our needs?

WFM. I will clear when the rev comes through.

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 18 Feb 2015 12:39:54 -0800

Thanks,
Alissa

---

From: "Leif Johansson" <[email-masked]>
Date: Wed, 18 Feb 2015 22:51:33 +0100

> 18 feb 2015 kl. 21:40 skrev Alissa Cooper <[email-masked]>:
> 
> 

thx!

---

From: "Leif Johansson" <[email-masked]>
Date: Wed, 18 Feb 2015 22:51:33 +0100

thx!

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 18 Feb 2015 15:05:45 -0700

> WFM. I will clear when the rev comes through.

Great. We'll do that after tomorrow's telechat.

Peter

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 18 Feb 2015 15:05:45 -0700

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Feb 2015 22:27:20 +0000

>    practices recommended here, it needs to publish a document that

Someone might have e.g. an IANA registry with their MTI ciphersuites.
Or something. Maybe re-wording that'd be good.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Feb 2015 22:27:20 +0000

S.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 18 Feb 2015 16:49:57 -0700

On 2/18/15 3:27 PM, Stephen Farrell wrote:
> Or something.

Like RFC 5327 perhaps? (The IANA registry for that protocol lists 
HMAC-SHA1-80 and RSA-SHA256.)

> Maybe re-wording that'd be good.

This should do it:

s/needs to publish a document that updates/needs to update/

Peter

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 18 Feb 2015 16:49:57 -0700

This should do it:

Peter

---

From: Ralph Holz <[email-masked]>
Date: Thu, 19 Feb 2015 15:11:47 +1100

OK with me, too.

On 19 February 2015 at 06:21, Leif Johansson <[email-masked]> wrote:

> negotiate SSLv2" because doing otherwise causes harm to implementations and
> to the net in general. There are no Internet police. If you violate that
> MUST NOT, you don't go to jail. We're simply saying that they way to do
> security properly on the Internet is that you MUST NOT use SSLv2.
> >>>
> >>> So I don't have a problem with the document saying, "Existing
> protocols have tradeoffs to make between interoperability and security, so
> we (the IETF) expect those tradeoffs to be made. New protocols we (the
> IETF) expect to abide by the requirements and recommendations in this
> document unless they give some serious justification for not doing so."
> That's what we mean by a BCP.
> >>>
> >> hmm yeah sure
> >>
> >

---

From: Ralph Holz <[email-masked]>
Date: Thu, 19 Feb 2015 15:11:47 +1100

OK with me, too.