Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Watson Ladd]

On Wed, Dec 2, 2020, 3:18 PM Ackermann, Michael  wrote:
>
> Barbara,
> Thanks.
> And I think I was aware of all you state below regarding TLS, and apologize 
> for any related confusion regarding IPv6, even though, for the purposes of my 
> comment, they are similar.
>
>
> I don't disagree with anything you say on the TLS subject,  which is 
> essentially that prior versions of TLS may be considered insecure, etc.  and 
> should be deprecated.

Shouldn't we publish a document saying that? It seems this would
represent consensus, even your view of the issue.

>
> My associated point is that Enterprises are generally not aware of this and 
> that it is not currently on our Planning or Budget Radars.


TLS 1.2 has been around for how many years? All versions of OpenSSL
without support have been EOL for some time. How many other CVE remain
to be found in them? FIPS, PCI etc are all very clear that old TLS is
going away. Browsers have supported TLS 1.2 for years. So has Windows.
This depreciation should be easy given the extent of support for TLS
1.2.

I bet that most services you run are already using TLS 1.2 or even 1.3
because the client and server have been updated.

> Further, this means we are potentially years from effectively and 
> operationally addressing such issues.

Let's be about it.

>And we must do so in conjunction with Partners, Clouds, Clients and others.
> And my general, overall point is that the answer to addressing the above is 
> to find way(s) of making Enterprises aware and possibly assisting with 
> methods of addressing. I think I also said this  problem is not unique to 
> TLS or IPv6.  More, it is a lack of understanding of how things work 
> within Enterprise Networks and the lack of Enterprise engagement in Standards 
> Development processes.
> And finally, this may not be a gap that the IETF should care about or 
> address, but someone should, IMHO.

Your argument against the current text seems to be the following: we
have a problem. It is inconvenient for me that you will ask me to deal
with the problem. Therefore I would like the problem to not be
acknowledged.

Perhaps I am being too uncharitable. But I fail to see how softening
the language eases depreciation, or what the consequence you fear
happening are. You're free to continue ignoring the RFC series. But
reality does not go away if it is ignored.

Sincerely,
Watson Ladd

>
> Thanks
>
> Mike

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-external-psk-importer-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : Importing External PSKs for TLS
Authors : David Benjamin
  Christopher A. Wood
Filename: draft-ietf-tls-external-psk-importer-06.txt
Pages   : 11
Date: 2020-12-03

Abstract:
   This document describes an interface for importing external Pre-
   Shared Keys (PSKs) into TLS 1.3.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-06
https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[STARK, BARBARA H]

Ow! Mike is my friend. Don't go dissing my friend!

I think the problem in communication we've just experienced is because Mike 
strayed away from Last Call discussion on a specific document, to 
asking/discussing a more general question of how IETF can better communicate 
with enterprises and perhaps even engage with enterprises to make it easier to 
operationalize protocols inside enterprise networks. I didn't see Mike 
suggesting any changes to the draft in Last Call, relevant to this question. ?

I'd like to suggest that maybe we could discuss this a little more on the ietf 
list? But not here.
I'll see what happens if I start a thread over there (i...@ietf.org) ...
Barbara

[Let me drum up my courage first. Thinking about posting to that list is much 
more stressful to me than, for example, thinking about bungie jumping off the 
Macau Tower -- an experience I highly recommend.]

> > Barbara,
> > Thanks.
> > And I think I was aware of all you state below regarding TLS, and apologize
> for any related confusion regarding IPv6, even though, for the purposes of
> my comment, they are similar.
> >
> >
> > I don't disagree with anything you say on the TLS subject,  which is
> essentially that prior versions of TLS may be considered insecure, etc.  and
> should be deprecated.
> 
> Shouldn't we publish a document saying that? It seems this would
> represent consensus, even your view of the issue.
> 
> >
> > My associated point is that Enterprises are generally not aware of this and
> that it is not currently on our Planning or Budget Radars.
> 
> 
> TLS 1.2 has been around for how many years? All versions of OpenSSL
> without support have been EOL for some time. How many other CVE remain
> to be found in them? FIPS, PCI etc are all very clear that old TLS is
> going away. Browsers have supported TLS 1.2 for years. So has Windows.
> This depreciation should be easy given the extent of support for TLS
> 1.2.
> 
> I bet that most services you run are already using TLS 1.2 or even 1.3
> because the client and server have been updated.
> 
> > Further, this means we are potentially years from effectively and
> operationally addressing such issues.
> 
> Let's be about it.
> 
> >And we must do so in conjunction with Partners, Clouds, Clients and
> others.
> > And my general, overall point is that the answer to addressing the above is
> to find way(s) of making Enterprises aware and possibly assisting with
> methods of addressing. I think I also said this  problem is not unique to 
> TLS
> or IPv6.  More, it is a lack of understanding of how things work within
> Enterprise Networks and the lack of Enterprise engagement in Standards
> Development processes.
> > And finally, this may not be a gap that the IETF should care about or
> address, but someone should, IMHO.
> 
> Your argument against the current text seems to be the following: we
> have a problem. It is inconvenient for me that you will ask me to deal
> with the problem. Therefore I would like the problem to not be
> acknowledged.
> 
> Perhaps I am being too uncharitable. But I fail to see how softening
> the language eases depreciation, or what the consequence you fear
> happening are. You're free to continue ignoring the RFC series. But
> reality does not go away if it is ignored.
> 
> Sincerely,
> Watson Ladd
> 
> >
> > Thanks
> >
> > Mike
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

[Eric Rescorla]

Document: draft-vvv-tls-cross-sni-resumption-00.txt

I think we should adopt this draft. Some review comments below.

S 1.
   Section 4.2.11).  However, in the absence of additional signals, it
   discourages using a session ticket when the SNI value does not match
   ([RFC8446], Section 4.6.1), as there is normally no reason to assume
   that all servers sharing the same certificate would also share the
   same session keys.  The extension defined in this document allows the
   server to provide such a signal in-band.

"session keys" is a weird term here. Perhaps "same session cache"?


S 3.
   The server MAY send the extension if it reasonably believes that any
   server for any identity presented in its certificate would be capable
   of accepting that ticket.  The server SHOULD NOT send the extension
   otherwise, since, if the client follows the single-use ticket policy
   recommended by [RFC8446], sending the ticket results in it being no
   longer usable regardless of whether resumption has succeeded.

Would a MUST be cleaner here? "Reasonably believes" is already pretty
weak.

I think we should say you can't use this with 1.2, even though it's
kind of obvious.


 S 4.
 It seems like a cite to https://www.mitls.org/downloads/vhost_confusion.pdf
 and an explanation of any impact this mechanism has would be in order
 here.


   If a client certificate has been associated with the session, the
   client MUST use the same policy on whether to present said
   certificate to the server as if it were a new TLS session.  For
   instance, if the client would show a certificate choice prompt for
   every individual domain it connects to, it MUST show that prompt for
   the new host when performing cross-domain resumption.

This seems like it only applies with post-handshake auth, right, given
that you can't do resumption + client auth.

-Ekr




On Tue, Dec 1, 2020 at 5:49 AM Salz, Rich 
wrote:

> I support the draft and will review.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

[David Benjamin]

On Thu, Dec 3, 2020 at 1:16 PM Eric Rescorla  wrote:

>If a client certificate has been associated with the session, the
>client MUST use the same policy on whether to present said
>certificate to the server as if it were a new TLS session.  For
>instance, if the client would show a certificate choice prompt for
>every individual domain it connects to, it MUST show that prompt for
>the new host when performing cross-domain resumption.
>
> This seems like it only applies with post-handshake auth, right, given
> that you can't do resumption + client auth.
>

 I'm not sure if it's ever been written down anywhere (probably should
be...), but I think resumption is pretty much universally interpreted as
authenticating as the identities presented over the original connection,
client and server. That means that, independent of this draft, the client
should only offer a session if it is okay with both accepting the original
server identity, and presenting the original client identity. (Analogously,
HTTP connection reuse reuses TLS handshake-level decisions, so you have to
be okay with that decision to reuse the connection.)

It's common to key client certificate preferences by server domain, so this
text is saying you should offer cross-domain sessions consistent with that.
(Analogously, HTTP/2 cross-domain connection reuse has the same effect and
you have to be okay with that decision. In Chrome, we don't do cross-domain
connection reuse on connections with a client certificate, since the user
was only prompted for the original domain. I expect we'd apply a similar
rule to resumption.)

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

[Eric Rescorla]

On Thu, Dec 3, 2020 at 11:12 AM David Benjamin 
wrote:

> On Thu, Dec 3, 2020 at 1:16 PM Eric Rescorla  wrote:
>
>>If a client certificate has been associated with the session, the
>>client MUST use the same policy on whether to present said
>>certificate to the server as if it were a new TLS session.  For
>>instance, if the client would show a certificate choice prompt for
>>every individual domain it connects to, it MUST show that prompt for
>>the new host when performing cross-domain resumption.
>>
>> This seems like it only applies with post-handshake auth, right, given
>> that you can't do resumption + client auth.
>>
>
>  I'm not sure if it's ever been written down anywhere (probably should
> be...), but I think resumption is pretty much universally interpreted as
> authenticating as the identities presented over the original connection,
> client and server. That means that, independent of this draft, the client
> should only offer a session if it is okay with both accepting the original
> server identity, and presenting the original client identity. (Analogously,
> HTTP connection reuse reuses TLS handshake-level decisions, so you have to
> be okay with that decision to reuse the connection.)
>
> It's common to key client certificate preferences by server domain, so
> this text is saying you should offer cross-domain sessions consistent with
> that. (Analogously, HTTP/2 cross-domain connection reuse has the same
> effect and you have to be okay with that decision. In Chrome, we don't do
> cross-domain connection reuse on connections with a client certificate,
> since the user was only prompted for the original domain. I expect we'd
> apply a similar rule to resumption.)
>

Yes, this seems reasonable, but I didn't get it from the text, so maybe if
this is adopted we could file an issue.

-Ekr

David
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

[Salz, Rich]

  *I'm not sure if it's ever been written down anywhere (probably should 
be...), but I think resumption is pretty much universally interpreted as 
authenticating as the identities presented over the original connection, client 
and server. That means that, independent of this draft, the client should only 
offer a session if it is okay with both accepting the original server identity, 
and presenting the original client identity. (Analogously, HTTP connection 
reuse reuses TLS handshake-level decisions, so you have to be okay with that 
decision to reuse the connection.)

Totally agree.  @ekr, you want to make this change in your BIS draft?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF109: Confirming resolution on lone draft-ietf-tls-dtls-connection-id issue

[Christopher Wood]

A PR with the proposed change is here:

   https://github.com/tlswg/dtls-conn-id/pull/77

Please have a look and let the list know if you object to the change. Absent 
objection, we'll merge it and move the document forward.

Thanks,
Chris

On Tue, Nov 17, 2020, at 9:27 PM, Sean Turner wrote:
> All,
> 
> ekr proposed a fix to address the lone remaining AD review issue: 
> tweaking the MAC (AtE) input; see the later messages in [0]. During the 
> session there was consensus to tweak the proposal to be more like what 
> Ben proposed in email, with the CID length before the CID and the 
> on-the-wire header contiguous in the MAC input. Achim noted and ekr 
> agreed in the thread after the session that what was presented needed 
> to be tweaked. However, it appears that the general way forward, i.e., 
> tweak the MAC (AtE), still holds. If you disagree with this please join 
> the discussion in the thread referenced earlier. Once ekr has proposed 
> a PR, we will run a quick consensus check to make sure we can move this 
> I-D along.
> 
> Cheers,
> Chris, Joe, and Sean
> 
> [0] https://mailarchive.ietf.org/arch/msg/tls/fuIKh0KLOBDxEHO14OloItd87o8/
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

[Eric Rescorla]

Hmmm... I think it probably goes in this draft, but I'm open to being wrong.

On Thu, Dec 3, 2020 at 12:46 PM Salz, Rich  wrote:

>
>-  I'm not sure if it's ever been written down anywhere (probably
>should be...), but I think resumption is pretty much universally
>interpreted as authenticating as the identities presented over the original
>connection, client and server. That means that, independent of this draft,
>the client should only offer a session if it is okay with both accepting
>the original server identity, and presenting the original client identity.
>(Analogously, HTTP connection reuse reuses TLS handshake-level decisions,
>so you have to be okay with that decision to reuse the connection.)
>
>
>
> Totally agree.  @ekr, you want to make this change in your BIS draft?
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

[David Benjamin]

I think, like the tracking issue, it should go in both. (I wrote
https://github.com/tlswg/tls13-spec/pull/1205 to try to capture the
tracking case.) This draft should definitely (re)-state it because TLS
preferences are most common keyed by domain name. So even if it's in TLS
itself, it's worth emphasizing it.

At the same time, I think it is a general property of resumption. An
application may have different TLS preferences even for a single domain.
(E.g. web browsers make both credentialed and uncredentialed requests,
which are supposed to imply different client certificate preferences.) Or
maybe you have some contexts with different server authentication
preferences than other contexts. Such an application would need to adjust
its resumption behavior accordingly.

To me, the ideal state would be that TLS contains the long-form general
guidance and then this draft cites TLS as a reminder, because keying
preferences by domain is so common. But since the order between rfc8446bis
and this draft isn't yet clear, probably we restate the rules in full in
both and, after rfc8446bis is done, documents can be more concise.

On Thu, Dec 3, 2020 at 4:00 PM Eric Rescorla  wrote:

> Hmmm... I think it probably goes in this draft, but I'm open to being
> wrong.
>
> On Thu, Dec 3, 2020 at 12:46 PM Salz, Rich  wrote:
>
>>
>>-  I'm not sure if it's ever been written down anywhere (probably
>>should be...), but I think resumption is pretty much universally
>>interpreted as authenticating as the identities presented over the 
>> original
>>connection, client and server. That means that, independent of this draft,
>>the client should only offer a session if it is okay with both accepting
>>the original server identity, and presenting the original client identity.
>>(Analogously, HTTP connection reuse reuses TLS handshake-level decisions,
>>so you have to be okay with that decision to reuse the connection.)
>>
>>
>>
>> Totally agree.  @ekr, you want to make this change in your BIS draft?
>>
>>
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Gen-art] Genart last call review of draft-ietf-tls-external-psk-importer-05

[Brian E Carpenter]

FYI, the -06 draft satisfies all my concerns.

Thanks
   Brian Carpenter

On 07-Oct-20 15:24, Brian Carpenter via Datatracker wrote:
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
> 
> Gen-ART Last Call review of draft-ietf-tls-external-psk-importer-05
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-tls-external-psk-importer-05
> Reviewer: Brian Carpenter
> Review Date: 2020-10-07
> IETF LC End Date: 2020-10-15
> IESG Telechat date:  
> 
> Summary: Ready with issues
> 
> 
> Issues:
> ---
> 
>> 1.  Introduction
>>
>>Applications SHOULD provision separate PSKs for TLS 1.3 and prior
>>versions when possible.
> 
> I think that "when possible" could easily be used as a loophole by a
> lazy implementer. ("Impossible, because I'd have to refactor my code.")
> Since presumably this rule is to avoid all risk of a "related output"
> cryptanalytic vulnerability, why weaken the RFC2119 definition of SHOULD?
> The formal definition of SHOULD is stronger, with "the full implications
> must be understood and carefully weighed before choosing a different
> course." So I suggest simply deleting "when possible".
> 
>> 6.  Incremental Deployment
>>
>>   Recall that TLS 1.2 permits computing the TLS PRF with any hash
>>   algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and
>>   underlying HMAC hash algorithm) as TLS 1.3 with importers.  However,
>>   critically, the derived PSK will not be the same since the importer
>>   differentiates the PSK via the identity and target KDF and protocol.
>>   Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS
>>   1.2, and thereby avoid cross-protocol collisions.  Note that this
>>   does not preclude endpoints from using non-imported PSKs for TLS 1.2.
>>   Indeed, this is necessary for incremental deployment.
> 
> I read this three times and I have to ask whether "TLS 1.2" is
> really what you want in the penultimate line.
> 
> Nits:
> -
> 
>> 4.1.  External PSK Diversification
> ...
>>   ImportedIdentity.target_protocol MUST be the (D)TLS protocol version
>>   for which the PSK is being imported.  For example, TLS 1.3 [RFC8446]
>>   and QUICv1 [QUIC] use 0x0304. 
> 
> As far as I can tell, [QUIC] doesn't specify this, but draft-ietf-quic-tls
> does specify that QUICv1 uses TLS1.3. So the phrasing is a bit misleading.
> Maybe:
> 
>   For example, TLS 1.3 [RFC8446] uses 0x0304, which will therefore also be
>   used by QUICv1 [QUIC-TLS]. 
> 
> Are all the RFC2119 terms capitalised when required? For example, there
> are lower case 'may' and 'must' in the last paragraph of section 4.1
> (External PSK Diversification). I couldn't determine whether they were
> intended to be normative.
> 
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

[Salz, Rich]

  *   Hmmm... I think it probably goes in this draft, but I'm open to being 
wrong.

That’s okay with me.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] ALPS and TLS 1.3 half-RTT data

[David Benjamin]

Hi TLS and HTTP friends,

At the last HTTPWG interim, there was a question of why one would want
something like ALPS (draft-vvv-tls-alps) for HTTP SETTINGS
(draft-vvv-httpbis-alps) over TLS 1.3 half-RTT data. I know we've also had
some discussion on this topic in the TLSWG as well. At the HTTP meeting,
folks suggested writing up what a half-RTT-based mechanism might look like,
so I put together an I-D below. I hope it helps clarify some of our
thinking.

(The I-D is not meant for adoption or publication or anything. I figured an
I-D was probably the most familiar format for folks.)

David

-- Forwarded message -
From: 
Date: Thu, Dec 3, 2020 at 4:22 PM
Subject: New Version Notification for
draft-davidben-tls-alps-half-rtt-00.txt
To: David Benjamin 



A new version of I-D, draft-davidben-tls-alps-half-rtt-00.txt
has been successfully submitted by David Benjamin and posted to the
IETF repository.

Name:   draft-davidben-tls-alps-half-rtt
Revision:   00
Title:  Comparing ALPS and Half-RTT Data
Document date:  2020-12-03
Group:  Individual Submission
Pages:  11
URL:
https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.txt
Status:
https://datatracker.ietf.org/doc/draft-davidben-tls-alps-half-rtt/
Html:
https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.html
Htmlized:
https://tools.ietf.org/html/draft-davidben-tls-alps-half-rtt-00


Abstract:
   This document compares the Application Layer Protocols Settings
   extension with the half-RTT feature in TLS 1.3.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[BRUNGARD, DEBORAH A]

As Barbara builds her confidence for the IETF list and while we have Mike's 
attention-

Mike, you commented "More, it is a lack of understanding of how things work 
within Enterprise Networks and the lack of Enterprise engagement in Standards 
Development processes. And finally, this may not be a gap that the IETF should 
care about or address, but someone should, IMHO."

I wanted to +1 on to Barbara's message - many of us will say - "we do care". As 
IETF is "huge" (for many operators/users that is the biggest bottleneck on 
participating), not sure if you follow the ops area (I'm a routing AD, but ops 
always has my attention😊), they have several documents on enterprises. 
Currently a document on the impact of TLS1.3 on operational network security 
practices. They also have an IPv6 one. I think in all the Areas (I know best 
the routing area), we encourage operators and users to participate. If you have 
suggestions - we are interested.

How to increase visibility? Do you have suggestions? Liaisons? ISOC? When 
RFC7381 (Enterprise IPv6) was done, it was an ISOC blog:
https://www.internetsociety.org/blog/2014/10/new-rfc-7381-enterprise-ipv6-deployment-guidelines/

Possibly this draft should be a blog? Suggestions?

Thanks again for the interesting thread-
Deborah
for some humor - I'm still stumbling on the draft's requirement "Pragmatically, 
clients MUST NOT send". I'm not sure operationally how to ensure pragmatic 
client behavior - maybe a "pragmatic client" profile😊 I'll save that question 
for my ballot comment. And of course a google of pragmatic is very entertaining:
https://www.google.com/search?q=pragmatic&tbm=isch&source=iu&ictx=1&fir=UnkLahjDGGZYtM%252C2VmBAP_98FtW_M%252C%252Fm%252F0c6h9&vet=1&usg=AI4_-kQHPVOk9B-3gfzcXUP1bBCiuOQ5TQ&sa=X&ved=2ahUKEwjxqN-W1rLtAhXKhK0KHWuFBGYQ_B16BAgrEAE#imgrc=WzKrFQWEFvjiWM



-Original Message-
From: last-call  On Behalf Of STARK, BARBARA H
Sent: Thursday, December 3, 2020 12:03 PM
To: 'Watson Ladd' ; 'Ackermann, Michael' 

Cc: 'Peter Gutmann' ; 'Eliot Lear' 
; 'last-c...@ietf.org' ; 
'tls-cha...@ietf.org' ; 
'draft-ietf-tls-oldversions-deprec...@ietf.org' 
; 'tls@ietf.org' 
Subject: Re: [Last-Call] [TLS] Last Call: 
 (Deprecating TLSv1.0 and TLSv1.1) 
to Best Current Practice

Ow! Mike is my friend. Don't go dissing my friend!

I think the problem in communication we've just experienced is because Mike 
strayed away from Last Call discussion on a specific document, to 
asking/discussing a more general question of how IETF can better communicate 
with enterprises and perhaps even engage with enterprises to make it easier to 
operationalize protocols inside enterprise networks. I didn't see Mike 
suggesting any changes to the draft in Last Call, relevant to this question. ?

I'd like to suggest that maybe we could discuss this a little more on the ietf 
list? But not here.
I'll see what happens if I start a thread over there (i...@ietf.org) ...
Barbara

[Let me drum up my courage first. Thinking about posting to that list is much 
more stressful to me than, for example, thinking about bungie jumping off the 
Macau Tower -- an experience I highly recommend.]

> > Barbara,
> > Thanks.
> > And I think I was aware of all you state below regarding TLS, and apologize
> for any related confusion regarding IPv6, even though, for the purposes of
> my comment, they are similar.
> >
> >
> > I don't disagree with anything you say on the TLS subject,  which is
> essentially that prior versions of TLS may be considered insecure, etc.  and
> should be deprecated.
> 
> Shouldn't we publish a document saying that? It seems this would
> represent consensus, even your view of the issue.
> 
> >
> > My associated point is that Enterprises are generally not aware of this and
> that it is not currently on our Planning or Budget Radars.
> 
> 
> TLS 1.2 has been around for how many years? All versions of OpenSSL
> without support have been EOL for some time. How many other CVE remain
> to be found in them? FIPS, PCI etc are all very clear that old TLS is
> going away. Browsers have supported TLS 1.2 for years. So has Windows.
> This depreciation should be easy given the extent of support for TLS
> 1.2.
> 
> I bet that most services you run are already using TLS 1.2 or even 1.3
> because the client and server have been updated.
> 
> > Further, this means we are potentially years from effectively and
> operationally addressing such issues.
> 
> Let's be about it.
> 
> >And we must do so in conjunction with Partners, Clouds, Clients and
> others.
> > And my general, overall point is that the answer to addressing the above is
> to find way(s) of making Enterprises aware and possibly assisting with
> methods of addressing. I think I also said this  problem is not unique to 
> TLS
> or IPv6.  More, it is a lack of understanding of how things work within
> Enterprise Networks and the lack of Enterprise engagement in Standards
> Development processes.
> > And finally, t

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Ackermann, Michael]

Sorry for the delay in responding.   Tough day at the ranch.   Just getting 
caught up now (or trying).  

Barbara, thanks for your response on my behalf and you are correct, I am not 
making any recommended content changes to the draft at all, and I am not 
arguing against the current text, as Watson seemed to suggest.  
I am also not suggesting that because something is inconvenient for me or other 
Enterprises, that the problem should not be acknowledged, as Watson stated.  In 
fact, it is because I will need to acknowledge and deal with related problems, 
that I am very interested in this topic. And finally Watson seems to infer 
that I am advocating  "continuing to ignore the RFC series".This could not 
be further from the truth.   Trying to get enterprises more aware of RFC 
developments is the primary reason I continue participate in IETF.   I 
strive long for a situation where enterprises are as aware, informed and 
compliant as possible and if their needs are factored, this becomes more 
achievable.  

What I actually was saying,  was a response to previous discourse in this list 
topic,  that was questioning why a TLS conversion might be difficult or time 
consuming for Enterprises, from someone on the inside of such situations.   The 
enterprise perspective is not usually considered or understood at IETF, and 
this was an attempt to highlight and attempt to encourage, the "Bridging of 
that gap".   My extended point was that this lack of 
understanding/communication, between Enterprises and IETF, is not unique to 
this list topic issue.   I believe this would be in the best interests of all 
to address and improve this, both on this topic and globally.   I want to 
work towards that wherever and however I can.   

Finally I agree with Barbara that those of us who may care to care to 
constructively address & improve the more global aspects of Enterprise/IETF 
interaction, should do so off this list & subject chain.I am not aware 
of the "bungie jumping off the Macau Tower" aspects of the other list, so if 
there is a smaller and/or less painful start to this, I am all for whatever you 
suggest. 

Thanks

Mike


Your argument against the current text seems to be the following: we 
> have a problem. It is inconvenient for me that you will ask me to deal 
> with the problem. Therefore I would like the problem to not be 
> acknowledged.

-Original Message-
From: STARK, BARBARA H  
Sent: Thursday, December 3, 2020 12:03 PM
To: 'Watson Ladd' ; Ackermann, Michael 

Cc: 'Eliot Lear' ; 'Peter Gutmann' 
; 'draft-ietf-tls-oldversions-deprec...@ietf.org' 
; 'last-c...@ietf.org' 
; 'tls@ietf.org' ; 'tls-cha...@ietf.org' 

Subject: RE: [TLS] [Last-Call] Last Call: 
 (Deprecating TLSv1.0 and TLSv1.1) 
to Best Current Practice

[External email]


Ow! Mike is my friend. Don't go dissing my friend!

I think the problem in communication we've just experienced is because Mike 
strayed away from Last Call discussion on a specific document, to 
asking/discussing a more general question of how IETF can better communicate 
with enterprises and perhaps even engage with enterprises to make it easier to 
operationalize protocols inside enterprise networks. I didn't see Mike 
suggesting any changes to the draft in Last Call, relevant to this question. ?

I'd like to suggest that maybe we could discuss this a little more on the ietf 
list? But not here.
I'll see what happens if I start a thread over there (i...@ietf.org) ...
Barbara

[Let me drum up my courage first. Thinking about posting to that list is much 
more stressful to me than, for example, thinking about bungie jumping off the 
Macau Tower -- an experience I highly recommend.]

> > Barbara,
> > Thanks.
> > And I think I was aware of all you state below regarding TLS, and 
> > apologize
> for any related confusion regarding IPv6, even though, for the 
> purposes of my comment, they are similar.
> >
> >
> > I don't disagree with anything you say on the TLS subject,  which is
> essentially that prior versions of TLS may be considered insecure, 
> etc.  and should be deprecated.
>
> Shouldn't we publish a document saying that? It seems this would 
> represent consensus, even your view of the issue.
>
> >
> > My associated point is that Enterprises are generally not aware of 
> > this and
> that it is not currently on our Planning or Budget Radars.
>
>
> TLS 1.2 has been around for how many years? All versions of OpenSSL 
> without support have been EOL for some time. How many other CVE remain 
> to be found in them? FIPS, PCI etc are all very clear that old TLS is 
> going away. Browsers have supported TLS 1.2 for years. So has Windows.
> This depreciation should be easy given the extent of support for TLS 
> 1.2.
>
> I bet that most services you run are already using TLS 1.2 or even 1.3 
> because the client and server have been updated.
>
> > Further, this means we are potentially years from effectively and
> operationally addres

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Rob Sayre]

On Thu, Dec 3, 2020 at 2:38 PM Ackermann, Michael 
wrote:

> The enterprise perspective is not usually considered or understood at IETF
>

I think that perspective is both considered and understood, but not usually
accommodated.

I can't even imagine shipping TLS 1.2 for anything at this point, and I
don't think the IETF should be publishing new documents that make
allowances for TLS versions previous to 1.3.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

[David Schinazi]

I support adoption of draft-vvv-tls-cross-sni-resumption.

David

On Thu, Dec 3, 2020 at 1:49 PM Salz, Rich 
wrote:

>
>
>- Hmmm... I think it probably goes in this draft, but I'm open to
>being wrong.
>
>
>
> That’s okay with me.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] WGLC for "Guidance for External PSK Usage in TLS"

[Joseph Salowey]

This email starts the working group last call for "Guidance for External
PSK Usage in TLS", located here:

   https://tools.ietf.org/html/draft-ietf-tls-external-psk-guidance-01

Please review the document and send your comments to the list by December
18, 2020.

Note the the GitHub repository for this draft can be found here:

   https://github.com/tlswg/external-psk-design-team

Thanks,
Joe and Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Stephen Farrell]

(Even though this sub-thread has no effect on the draft, I
couldn't resist:-)

On 03/12/2020 23:53, Rob Sayre wrote:

The enterprise perspective is not usually considered or understood at IETF


I think that perspective is both considered and understood, but not usually
accommodated.


I think you're both wrong:-)

It seems wrong to me to assume that there is a singular
and united "enterprise perspective" on TLS and that was
very clear from earlier debates where some people made
one kind of assertion, while others, also correctly saying
they represented "enterprises" fully disagreed.

There are of course a set of networks that have difficulty
in managing and updating the systems that make up their
networks. There are others for whom updating TLS is going
to be much less of an issue due to the nature of those
networks (newer, or more automated/centralised, or whatever).
Both situations arise for understandable valid reasons but
dealing with the cases where problems do or don't arise
isn't helped IMO by over-claiming on any side.

And yes, in addition to the above, there are people whose
main (and also reasonable) concern is the web, and their
concerns and ability to handle updates do differ. And
there are others for whom other issues take precedence.

None of that means a lack of consideration, nor a lack
of accommodation. For things like TLS, where code is
often delivered via libraries, the timing of change does
sometimes make for awkward compromises, that will make
some of the above unhappy, but that's just life and is
why the WG chairs and ADs are such well paid consensus
callers:-)

I think the IETF process works pretty well for all this,
overall, and over time.

Cheers,
S.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Rob Sayre]

On Thu, Dec 3, 2020 at 4:54 PM Stephen Farrell 
wrote:

>
> There are of course a set of networks that have difficulty
> in managing and updating the systems that make up their
> networks.
>

That's true, but attackers run on their own schedule.

I don't think IETF documents should include caveats for older TLS versions
that are quite obviously flawed.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-ticketrequests-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : TLS Ticket Requests
Authors : Tommy Pauly
  David Schinazi
  Christopher A. Wood
Filename: draft-ietf-tls-ticketrequests-07.txt
Pages   : 8
Date: 2020-12-03

Abstract:
   TLS session tickets enable stateless connection resumption for
   clients without server-side, per-client, state.  Servers vend an
   arbitrary number of session tickets to clients, at their discretion,
   upon connection establishment.  Clients store and use tickets when
   resuming future connections.  This document describes a mechanism by
   which clients can specify the desired number of tickets needed for
   future connections.  This extension aims to provide a means for
   servers to determine the number of tickets to generate in order to
   reduce ticket waste, while simultaneously priming clients for future
   connection attempts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-07
https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ticketrequests-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Genart last call review of draft-ietf-tls-ticketrequests-06

[Christopher Wood]

Thanks for the feedback, Dale! We addressed your comments and updated the 
draft. The diff is available here:

   
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-ticketrequests-07.txt

Best,
Chris

On Fri, Nov 27, 2020, at 7:54 PM, Dale Worley via Datatracker wrote:
> Reviewer: Dale Worley
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document:  draft-ietf-tls-ticketrequests-06
> Reviewer:  Dale R. Worley
> Review Date:  2020-11-27
> IETF LC End Date:  2020-12-03
> IESG Telechat date:  Not known
> 
> Summary:
> 
> This draft is ready for publication as a Standards Track RFC.
> 
> Editorial comments:
> 
> 2.  Use Cases
> 
>*  Parallel HTTP connections: To minimize ticket reuse while still
>   improving performance, it may be useful to use multiple, distinct
>   tickets when opening parallel connections.
> 
> To the naive reader, the ordering of the phrases doesn't seem to match
> the logical ordering of the concepts.  Perhaps
> 
>*  Parallel HTTP connections: To improve performance, a client
>   may open parallel connections.  To avoid ticket reuse, the client
>   may use multiple, distinct tickets on each connection.
> 
> --
> 
>*  Decline resumption: Clients can indicate they have no intention of
>   resuming connections by sending a ticket request with count of
>   zero.
> 
> "have no intention" seems to me to suggest a decision that will not
> change.  Since the future cannot be guaranteed, perhaps better wording
> is "do not intend to resume", suggesting a current state that might
> possibly change in the future.
> 
>new_session_count  The number of tickets desired by the client when
>   the server chooses to negotiate a new connection.
> 
>resumption_count  The number of tickets desired by the client when
>   the server is willing to resume using a ticket presented in this
>   ClientHello.
> 
> If I understand the processing which is suggested correctly, when the
> client sends a ClientHello, the server can choose to either negotiate
> a new connection, or (if a ticket is present in the ClientHello) the
> server can choose to resume the previous connection represented by the
> ticket.  These two parameters provide the requested ticket count for
> the two situations.
> 
> Assuming the above is correct, I would recommend changing the wording
> slightly, as "when" suggests a fact which is true over an extended
> period of time, whereas the provided counts are applicable in just this
> one instance:
> 
>new_session_count  The number of tickets desired by the client if
>   the server chooses to negotiate a new connection.
> 
>resumption_count  The number of tickets desired by the client if
>   the server chooses to resume (using the ticket presented in this
>   ClientHello).
> 
> (Change "the" to "a" in the last sentence if the ClientHello can
> present more than one ticket among which the server can choose.)
> 
> [END]
> 
> 
> 
>

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Ackermann, Michael]

Deborah

Thanks so much for your informative and positive message.

I have not followed the OPs area too much, but will make an effort to do so 
now.   Any specific drafts you might suggest, I will review.   In particular,  
I am interested in what specific IPv6 document from the OPs area you refer too?



I took a look at the ISOC IPv6 doc you listed.   Interesting but it appears to 
be quite old.   Do you feel it is still relevant?Enterprises need a lot of 
info on IPv6 and I want to point them in the most effective directions.

By increasing visibility, do you mean ways to get Enterprises more involved or 
aware of IETF? I can sadly say none that have yet been effective, but I do 
intend to keep trying.   Perhaps you have ideas?



And finally, I checked out your Pragmatic Link.  Still laughing, even though it 
unfortunately seems to have very little relevance to my world 😊



Once again I really appreciate your constructive comments and  information.



Mike



-Original Message-
From: BRUNGARD, DEBORAH A 
Sent: Thursday, December 3, 2020 5:10 PM
To: STARK, BARBARA H ; 'Watson Ladd' ; 
Ackermann, Michael 
Cc: 'Peter Gutmann' ; 'Eliot Lear' 
; 'last-c...@ietf.org' ; 
'tls-cha...@ietf.org' ; 
'draft-ietf-tls-oldversions-deprec...@ietf.org' 
; 'tls@ietf.org' 
Subject: RE: [Last-Call] [TLS] Last Call: 
 (Deprecating TLSv1.0 and TLSv1.1) 
to Best Current Practice



[External email]





As Barbara builds her confidence for the IETF list and while we have Mike's 
attention-



Mike, you commented "More, it is a lack of understanding of how things work 
within Enterprise Networks and the lack of Enterprise engagement in Standards 
Development processes. And finally, this may not be a gap that the IETF should 
care about or address, but someone should, IMHO."



I wanted to +1 on to Barbara's message - many of us will say - "we do care". As 
IETF is "huge" (for many operators/users that is the biggest bottleneck on 
participating), not sure if you follow the ops area (I'm a routing AD, but ops 
always has my attention😊), they have several documents on enterprises. 
Currently a document on the impact of TLS1.3 on operational network security 
practices. They also have an IPv6 one. I think in all the Areas (I know best 
the routing area), we encourage operators and users to participate. If you have 
suggestions - we are interested.



How to increase visibility? Do you have suggestions? Liaisons? ISOC? When 
RFC7381 (Enterprise IPv6) was done, it was an ISOC blog:

https://www.internetsociety.org/blog/2014/10/new-rfc-7381-enterprise-ipv6-deployment-guidelines/



Possibly this draft should be a blog? Suggestions?



Thanks again for the interesting thread- Deborah for some humor - I'm still 
stumbling on the draft's requirement "Pragmatically, clients MUST NOT send". 
I'm not sure operationally how to ensure pragmatic client behavior - maybe a 
"pragmatic client" profile😊 I'll save that question for my ballot comment. And 
of course a google of pragmatic is very entertaining:

https://www.google.com/search?q=pragmatic&tbm=isch&source=iu&ictx=1&fir=UnkLahjDGGZYtM%252C2VmBAP_98FtW_M%252C%252Fm%252F0c6h9&vet=1&usg=AI4_-kQHPVOk9B-3gfzcXUP1bBCiuOQ5TQ&sa=X&ved=2ahUKEwjxqN-W1rLtAhXKhK0KHWuFBGYQ_B16BAgrEAE#imgrc=WzKrFQWEFvjiWM







-Original Message-

From: last-call mailto:last-call-boun...@ietf.org>> 
On Behalf Of STARK, BARBARA H

Sent: Thursday, December 3, 2020 12:03 PM

To: 'Watson Ladd' mailto:watsonbl...@gmail.com>>; 
'Ackermann, Michael' mailto:mackerm...@bcbsm.com>>

Cc: 'Peter Gutmann' 
mailto:pgut...@cs.auckland.ac.nz>>; 'Eliot Lear' 
mailto:lear=40cisco@dmarc.ietf.org>>; 
'last-c...@ietf.org' mailto:last-c...@ietf.org>>; 
'tls-cha...@ietf.org' mailto:tls-cha...@ietf.org>>; 
'draft-ietf-tls-oldversions-deprec...@ietf.org' 
mailto:draft-ietf-tls-oldversions-deprec...@ietf.org>>;
 'tls@ietf.org' mailto:tls@ietf.org>>

Subject: Re: [Last-Call] [TLS] Last Call: 
 (Deprecating TLSv1.0 and TLSv1.1) 
to Best Current Practice



Ow! Mike is my friend. Don't go dissing my friend!



I think the problem in communication we've just experienced is because Mike 
strayed away from Last Call discussion on a specific document, to 
asking/discussing a more general question of how IETF can better communicate 
with enterprises and perhaps even engage with enterprises to make it easier to 
operationalize protocols inside enterprise networks. I didn't see Mike 
suggesting any changes to the draft in Last Call, relevant to this question. ?



I'd like to suggest that maybe we could discuss this a little more on the ietf 
list? But not here.

I'll see what happens if I start a thread over there 
(i...@ietf.org) ...

Barbara



[Let me drum up my courage first. Thinking about posting to that list is much 
more stressful to me than, for example, thinking about bungie jumping off the 
Macau Tower -- an experience I highly recommend.]



> > Barbara,

> > Thanks.

> > And I think I 

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Rob Sayre]

Hi,

What is the definition of “enterprise”?

Thanks,
Rob

On Thu, Dec 3, 2020 at 7:48 PM Ackermann, Michael 
wrote:

> Deborah
>
> Thanks so much for your informative and positive message.
>
> I have not followed the OPs area too much, but will make an effort to do
> so now.   Any specific drafts you might suggest, I will review.   In
> particular,  I am interested in what specific IPv6 document from the OPs
> area you refer too?
>
>
>
> I took a look at the ISOC IPv6 doc you listed.   Interesting but it
> appears to be quite old.   Do you feel it is still relevant?Enterprises
> need a lot of info on IPv6 and I want to point them in the most effective
> directions.
>
> By increasing visibility, do you mean ways to get Enterprises more
> involved or aware of IETF? I can sadly say none that have yet been
> effective, but I do intend to keep trying.   Perhaps you have ideas?
>
>
>
> And finally, I checked out your Pragmatic Link.  Still laughing, even
> though it unfortunately seems to have very little relevance to my world 😊
>
>
>
> Once again I really appreciate your constructive comments and
>  information.
>
>
>
> Mike
>
>
>
> -Original Message-
> From: BRUNGARD, DEBORAH A 
> Sent: Thursday, December 3, 2020 5:10 PM
> To: STARK, BARBARA H ; 'Watson Ladd' <
> watsonbl...@gmail.com>; Ackermann, Michael 
> Cc: 'Peter Gutmann' ; 'Eliot Lear'  40cisco@dmarc.ietf.org>; 'last-c...@ietf.org' ; '
> tls-cha...@ietf.org' ; '
> draft-ietf-tls-oldversions-deprec...@ietf.org' <
> draft-ietf-tls-oldversions-deprec...@ietf.org>; 'tls@ietf.org' <
> tls@ietf.org>
> Subject: RE: [Last-Call] [TLS] Last Call:
>  (Deprecating TLSv1.0 and
> TLSv1.1) to Best Current Practice
>
>
>
> [External email]
>
>
>
>
>
> As Barbara builds her confidence for the IETF list and while we have
> Mike's attention-
>
>
>
> Mike, you commented "More, it is a lack of understanding of how things
> work within Enterprise Networks and the lack of Enterprise engagement in
> Standards Development processes. And finally, this may not be a gap that
> the IETF should care about or address, but someone should, IMHO."
>
>
>
> I wanted to +1 on to Barbara's message - many of us will say - "we do
> care". As IETF is "huge" (for many operators/users that is the biggest
> bottleneck on participating), not sure if you follow the ops area (I'm a
> routing AD, but ops always has my attention😊), they have several
> documents on enterprises. Currently a document on the impact of TLS1.3 on
> operational network security practices. They also have an IPv6 one. I think
> in all the Areas (I know best the routing area), we encourage operators and
> users to participate. If you have suggestions - we are interested.
>
>
>
> How to increase visibility? Do you have suggestions? Liaisons? ISOC? When
> RFC7381 (Enterprise IPv6) was done, it was an ISOC blog:
>
>
> https://www.internetsociety.org/blog/2014/10/new-rfc-7381-enterprise-ipv6-deployment-guidelines/
>
>
>
> Possibly this draft should be a blog? Suggestions?
>
>
>
> Thanks again for the interesting thread- Deborah for some humor - I'm
> still stumbling on the draft's requirement "Pragmatically, clients MUST NOT
> send". I'm not sure operationally how to ensure pragmatic client behavior -
> maybe a "pragmatic client" profile😊 I'll save that question for my
> ballot comment. And of course a google of pragmatic is very entertaining:
>
>
> https://www.google.com/search?q=pragmatic&tbm=isch&source=iu&ictx=1&fir=UnkLahjDGGZYtM%252C2VmBAP_98FtW_M%252C%252Fm%252F0c6h9&vet=1&usg=AI4_-kQHPVOk9B-3gfzcXUP1bBCiuOQ5TQ&sa=X&ved=2ahUKEwjxqN-W1rLtAhXKhK0KHWuFBGYQ_B16BAgrEAE#imgrc=WzKrFQWEFvjiWM
>
>
>
>
>
>
>
> -Original Message-
>
> From: last-call  On Behalf Of STARK, BARBARA H
>
> Sent: Thursday, December 3, 2020 12:03 PM
>
> To: 'Watson Ladd' ; 'Ackermann, Michael' <
> mackerm...@bcbsm.com>
>
> Cc: 'Peter Gutmann' ; 'Eliot Lear' <
> lear=40cisco@dmarc.ietf.org>; 'last-c...@ietf.org' ;
> 'tls-cha...@ietf.org' ; '
> draft-ietf-tls-oldversions-deprec...@ietf.org' <
> draft-ietf-tls-oldversions-deprec...@ietf.org>; 'tls@ietf.org' <
> tls@ietf.org>
>
> Subject: Re: [Last-Call] [TLS] Last Call:
>  (Deprecating TLSv1.0 and
> TLSv1.1) to Best Current Practice
>
>
>
> Ow! Mike is my friend. Don't go dissing my friend!
>
>
>
> I think the problem in communication we've just experienced is because
> Mike strayed away from Last Call discussion on a specific document, to
> asking/discussing a more general question of how IETF can better
> communicate with enterprises and perhaps even engage with enterprises to
> make it easier to operationalize protocols inside enterprise networks. I
> didn't see Mike suggesting any changes to the draft in Last Call, relevant
> to this question. ?
>
>
>
> I'd like to suggest that maybe we could discuss this a little more on the
> ietf list? But not here.
>
> I'll see what happens if I start a thread over there (i...@ietf.org) ...
>
> Barbara
>
>
>
> [Let me drum up my courage fi