[TLS] Fwd: New Version Notification for draft-nir-tls-tlsflags-02.txt

[Yoav Nir]

Hi.

Following today’s session, I’ve updated and submitted the draft.

It contains the proposal from slide #5 in my presentation.

It does not contain any fancy way of reserving bits for future popular 
extensions.

It uses a single numbering of the flags, not the more efficient separate 
numbering per context (CH, SH, EE, CH-in-CTLS)

I believe such bikeshedding can be done after adoption. Just so long as we 
don’t make it of asbestos. [1]

Yoav

[1] It was never about the color of the bike shed, but about the material: 
https://en.wikipedia.org/wiki/Law_of_triviality#Examples 



> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-nir-tls-tlsflags-02.txt
> Date: 23 July 2019 at 23:22:50 GMT-4
> To: "Yoav Nir" 
> 
> 
> A new version of I-D, draft-nir-tls-tlsflags-02.txt
> has been successfully submitted by Yoav Nir and posted to the
> IETF repository.
> 
> Name: draft-nir-tls-tlsflags
> Revision: 02
> Title:A Flags Extension for TLS 1.3
> Document date:2019-07-22
> Group:Individual Submission
> Pages:6
> URL:
> https://www.ietf.org/internet-drafts/draft-nir-tls-tlsflags-02.txt
> Status: https://datatracker.ietf.org/doc/draft-nir-tls-tlsflags/
> Htmlized:   https://tools.ietf.org/html/draft-nir-tls-tlsflags-02
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-nir-tls-tlsflags
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-nir-tls-tlsflags-02
> 
> Abstract:
>   A number of extensions are proposed in the TLS working group that
>   carry no interesting information except the 1-bit indication that a
>   certain optional feature is supported.  Such extensions take 4 octets
>   each.  This document defines a flags extension that can provide such
>   indications at an average marginal cost of 1 bit each.  More
>   precisely, it provides as many flag extensions as needed at 4 + the
>   order of the last set bit divided by 8.
> 
> 
> 
> 
> 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] TLS Impact on Network Security draft updated

[Dennis Jackson]

On 24/07/2019 04:13, Benjamin Kaduk wrote:
> On Wed, Jul 24, 2019 at 03:35:43AM +0100, Dennis Jackson wrote:
>> On 24/07/2019 02:55, Bret Jordan wrote:
>>> As a professional organization and part of due diligence, we need to try
>>> and understand the risks and ramifications on the deployments of our
>>> solutions. This means, understanding exactly how the market uses and
>>> needs to use the solutions we create. When we remove or change some
>>> technology, we should try hard to provide a work around. If a work
>>> around is not possible, we need to cleanly document how these changes
>>> are going to impact the market so it can prepare. This is the
>>> responsible and prudent thing to do in a professional organization like
>>> the IETF. 
>>>
>>
>> The IETF is for development of Internet Standards. If you want to
>> publish your (subjective) analysis of how a particular standard is going
>> to impact your market segment, there are any number of better venues:
>> trade magazines, industry associations, your company website, etc.
> 
> Actually, the Independent stream of the RFC series is purpose-built for
> individual commentary on the consequences of a particular standard
> [including in a particular segment], and would be superior (at least in
> my opinion) to any of the venues you list.  (See RFC 4846.)  But I
> believe the current ISE asks authors to try fairly hard to publish their
> work in the IETF before accepting it to the Indepndent stream.

I was thinking of 'published by the IETF' to mean the IETF stream.
Publishing in the Independent stream, without any proper review,
consensus or claim of fitness is a different matter altogether.

>>> The draft that Nancy and others have worked on is a great start to
>>> documenting how these new solutions are going to impact organizational
>>> networks. Regardless of whether you like the use-cases or regulations
>>> that some organizations have, they are valid and our new solutions are
>>> going to impact them. 
>>
>> This isn't a question of quality. The IETF simply doesn't publish
>> documents of this nature (to my knowledge).
> 
> The IETF can publish whatever there is IETF consensus to publish.  (And
> a little bit more, besides, though that is probably not relevant to the
> current discussion.)
> 
> I don't have a great sense of what you mean by "documents of this
> nature".  If you were to say "the IETF does not publish speculative and
> subjective discussion of possible future impact", I'd be fairly likely
> to agree with you (but I have also seen a fair bit of speculation get
> published).  

This was my intended meaning.

I'd feel rather differently about "the IETF does not
> publish objective analysis of the consequences of protocol changes on
> previously deployed configurations", and would ask if you think a
> document in the latter category is impossible for the TLS 1.2->1.3
> transition.  (My understanding is that the latter category of document
> is the desired proposal, regardless of the current state of the draft in
> question.)

The authors initiated this discussion by stating their draft was stable
and requesting publication. Consequently, I think it must be judged on
the current state, rather than the desired outcome.

Even considering your more generous interpretation... the objective
discussion is only 3 out of 15 pages and none of the 5 claims appears to
be correct. (As others have pointed out).

Best,
Dennis

> -Ben
> 
> 

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

Re: [TLS] TLS Impact on Network Security draft updated

[Watson Ladd]

On Tue, Jul 23, 2019, 6:55 PM Bret Jordan  wrote:

> As a professional organization and part of due diligence, we need to try
> and understand the risks and ramifications on the deployments of our
> solutions. This means, understanding exactly how the market uses and needs
> to use the solutions we create. When we remove or change some technology,
> we should try hard to provide a work around. If a work around is not
> possible, we need to cleanly document how these changes are going to impact
> the market so it can prepare. This is the responsible and prudent thing to
> do in a professional organization like the IETF.
>

What technology was removed?

Was it TLS proxies equipped with the private key? No, those still work.
Interception devices with a root? No, still work. So what broke?


> The draft that Nancy and others have worked on is a great start to
> documenting how these new solutions are going to impact organizational
> networks. Regardless of whether you like the use-cases or regulations that
> some organizations have, they are valid and our new solutions are going to
> impact them.
>

It continually conflates some methods of achieving a goal with all of them.
As shown by some of the exchanges the draft substantially overstates the
issues.


> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
> can not be unscrambled is an egg."
>
> On Jul 23, 2019, at 7:44 PM, Dennis Jackson 
> wrote:
>
> RFC 791  is nearly 40 years old.
> RFC 4074 lists 5 forms of deviations from RFC 1034 and explains
> the correct behavior.
> RFC 7021 describes a series of objective tests of RFC 6333 and
> the results.
>
>
> The above RFCs describe objective test results and how they
> relate to earlier RFCs. In contrast, this document offers a
> speculative and subjective discussion of possible future impact.
>
>
> I do not believe there is any precedent supporting publication.
>
>
> Best,
> Dennis
>
>
> ___
> 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] TLS Impact on Network Security draft updated

[Ackermann, Michael]

This should not be dismissed as small segments of industries.This 
represents ubiquitous use cases at all large organizations in Insurance, Health 
Care, Banking, Automotive and many others.
We as the IETF should not lightly dismiss such significant numbers and volume, 
even (or especially),  if the answers are not easy ones.Do we really want 
related solutions to be developed elsewhere?

From: TLS  On Behalf Of Watson Ladd
Sent: Tuesday, July 23, 2019 6:58 PM
To: Filippo Valsorda 
Cc: TLS List 
Subject: Re: [TLS] TLS Impact on Network Security draft updated

 ALERT This email was sent from a source external to BCBSM/BCN.
 DO NOT CLICK links or attachments unless you recognize the sender and trust 
the content.


On Tue, Jul 23, 2019, 3:47 PM Filippo Valsorda 
mailto:fili...@ml.filippo.io>> wrote:
Before any technical or wording feedback, I am confused as to the nature of 
this document. It does not seem to specify any protocol change or mechanism, 
and it does not even focus on solutions to move the web further.

Instead, it looks like a well edited blog post, presenting the perspective of 
one segment of the industry. (The perspective seems to also lack consensus, but 
I believe even that is secondary.) Note how as of 
draft-camwinget-tls-use-cases-05 there are no IANA considerations, no security 
considerations, and no occurrences of any of the BCP 14 key words (MUST, 
SHOULD, etc.).

Is there precedent for publishing such a document as an RFC?

I was going to say RFC 691 but no, it recommends changes to the protocol (as 
well as being quite amusing). RFC 4074 comes close describing bad behavior 
without an explicit plea to stop doing it, but has a security considerations 
section. RFC 7021 describes the impact of a particular networking technique on 
applications.

So there is precedent.

Sincerely,
Watson


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Impact on Network Security draft updated

[Benjamin Kaduk]

On Wed, Jul 24, 2019 at 03:35:43AM +0100, Dennis Jackson wrote:
> On 24/07/2019 02:55, Bret Jordan wrote:
> > As a professional organization and part of due diligence, we need to try
> > and understand the risks and ramifications on the deployments of our
> > solutions. This means, understanding exactly how the market uses and
> > needs to use the solutions we create. When we remove or change some
> > technology, we should try hard to provide a work around. If a work
> > around is not possible, we need to cleanly document how these changes
> > are going to impact the market so it can prepare. This is the
> > responsible and prudent thing to do in a professional organization like
> > the IETF. 
> > 
> 
> The IETF is for development of Internet Standards. If you want to
> publish your (subjective) analysis of how a particular standard is going
> to impact your market segment, there are any number of better venues:
> trade magazines, industry associations, your company website, etc.

Actually, the Independent stream of the RFC series is purpose-built for
individual commentary on the consequences of a particular standard
[including in a particular segment], and would be superior (at least in
my opinion) to any of the venues you list.  (See RFC 4846.)  But I
believe the current ISE asks authors to try fairly hard to publish their
work in the IETF before accepting it to the Indepndent stream.

> > The draft that Nancy and others have worked on is a great start to
> > documenting how these new solutions are going to impact organizational
> > networks. Regardless of whether you like the use-cases or regulations
> > that some organizations have, they are valid and our new solutions are
> > going to impact them. 
> 
> This isn't a question of quality. The IETF simply doesn't publish
> documents of this nature (to my knowledge).

The IETF can publish whatever there is IETF consensus to publish.  (And
a little bit more, besides, though that is probably not relevant to the
current discussion.)

I don't have a great sense of what you mean by "documents of this
nature".  If you were to say "the IETF does not publish speculative and
subjective discussion of possible future impact", I'd be fairly likely
to agree with you (but I have also seen a fair bit of speculation get
published).  I'd feel rather differently about "the IETF does not
publish objective analysis of the consequences of protocol changes on
previously deployed configurations", and would ask if you think a
document in the latter category is impossible for the TLS 1.2->1.3
transition.  (My understanding is that the latter category of document
is the desired proposal, regardless of the current state of the draft in
question.)

-Ben


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

Re: [TLS] TLS Impact on Network Security draft updated

[Dennis Jackson]

On 24/07/2019 02:55, Bret Jordan wrote:
> As a professional organization and part of due diligence, we need to try
> and understand the risks and ramifications on the deployments of our
> solutions. This means, understanding exactly how the market uses and
> needs to use the solutions we create. When we remove or change some
> technology, we should try hard to provide a work around. If a work
> around is not possible, we need to cleanly document how these changes
> are going to impact the market so it can prepare. This is the
> responsible and prudent thing to do in a professional organization like
> the IETF. 
> 

The IETF is for development of Internet Standards. If you want to
publish your (subjective) analysis of how a particular standard is going
to impact your market segment, there are any number of better venues:
trade magazines, industry associations, your company website, etc.

> The draft that Nancy and others have worked on is a great start to
> documenting how these new solutions are going to impact organizational
> networks. Regardless of whether you like the use-cases or regulations
> that some organizations have, they are valid and our new solutions are
> going to impact them. 

This isn't a question of quality. The IETF simply doesn't publish
documents of this nature (to my knowledge).

> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
> can not be unscrambled is an egg."

Best,
Dennis

>> On Jul 23, 2019, at 7:44 PM, Dennis Jackson
>> mailto:dennis.jack...@cs.ox.ac.uk>> wrote:
>>
>> RFC 791  is nearly 40 years old.
>> RFC 4074 lists 5 forms of deviations from RFC 1034 and explains 
>> the correct behavior. 
>> RFC 7021 describes a series of objective tests of RFC 6333 and 
>> the results. 
>>
>>
>> The above RFCs describe objective test results and how they 
>> relate to earlier RFCs. In contrast, this document offers a 
>> speculative and subjective discussion of possible future impact.
>>
>>
>> I do not believe there is any precedent supporting publication.
>>
>>
>> Best,
>> Dennis
> 
> 
> ___
> 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] TLS Impact on Network Security draft updated

[Salz, Rich]

I repeat my question: What does it say that RFC 8404 doesn’t?

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

Re: [TLS] TLS Impact on Network Security draft updated

[Bret Jordan]

As a professional organization and part of due diligence, we need to try and 
understand the risks and ramifications on the deployments of our solutions. 
This means, understanding exactly how the market uses and needs to use the 
solutions we create. When we remove or change some technology, we should try 
hard to provide a work around. If a work around is not possible, we need to 
cleanly document how these changes are going to impact the market so it can 
prepare. This is the responsible and prudent thing to do in a professional 
organization like the IETF. 

The draft that Nancy and others have worked on is a great start to documenting 
how these new solutions are going to impact organizational networks. Regardless 
of whether you like the use-cases or regulations that some organizations have, 
they are valid and our new solutions are going to impact them. 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not 
be unscrambled is an egg."

> On Jul 23, 2019, at 7:44 PM, Dennis Jackson  
> wrote:
> 
> RFC 791  is nearly 40 years old.
> RFC 4074 lists 5 forms of deviations from RFC 1034 and explains 
> the correct behavior. 
> RFC 7021 describes a series of objective tests of RFC 6333 and 
> the results. 
> 
> 
> The above RFCs describe objective test results and how they 
> relate to earlier RFCs. In contrast, this document offers a 
> speculative and subjective discussion of possible future impact.
> 
> 
> I do not believe there is any precedent supporting publication.
> 
> 
> Best,
> Dennis

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

Re: [TLS] TLS Flags extension - not sure it makes sense

[Adam Langley]

On Tue, Jul 23, 2019 at 3:09 PM Chris Inacio  wrote:
> I really want the savings on the wire that TLS flags extension provides – and 
> so I think it’s really good for the future cTLS but I’m not sure when I get 
> to use it in TLS 1.3 negotiation.  It goes in the clientHello message, but 
> how will I know that the server uses this extension?  I envision a future 
> where we will add the flags extension along with the more expensive 4-bytes 
> version for a REALLY long time.

The expectation is that applicable future extensions will be defined
as flags. Therefore, if the server supports the extension that you're
interested in then it'll also have to support the flags extension. If
it doesn't, then the extension will be ignored as normal.


Cheers

AGL

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

Re: [TLS] Question about draft-thomson-tls-sic

[Adam Langley]

On Tue, Jul 23, 2019 at 5:23 PM Watson Ladd  wrote:

> Suppose the following sequence of events happen:
>
> 1: A CA uses a new intermediate for reasons (no longer cross-signing, etc.)
> 2: A site gets a certificate from the new intermediate.
> 3: An older firefox version connects and thinks it knows all the
> certificates in the world.
>
> This would seem to break and it wasn't clear to me how this would be
> handled. Though as Martin points out this extension is merely codification
> of an occasional practice, so maybe this case does actually work out.
>

I think the client would have to fall back and retry the TLS connection
without requesting that intermediates be omitted. In general, I think this
is the only reliable answer as AIA-chasing doesn't always work. (Either the
AIA server can be down, or the chain can be from a private CA that doesn't
support AIA.)


Cheers

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

Re: [TLS] Draft minutes for Tuesday

[Watson Ladd]

Thank you!

On Tue, Jul 23, 2019, 3:14 PM Salz, Rich  wrote:

> Are on etherpad at https://etherpad.ietf.org/p/notes-ietf-105-tls
>
>
>
> Cut/pasted here (but more readable there):
>
> TLS at IETF 105
>
>
>
> Tuesday
>
>
>
> Status update (drafts, code points, etc) -- see the slides
>
>
>
> CFRG working on PAKE selection;  integration with TLS is obviously
> important, come to CFRG meeting.
>
>
>
> Delegated credentials
>
>- Server side patch in boringSSL; NSS client side soon to be in FF
>nightly; FB work in progress
>
>
>- Plan to drop LURK mention, remove PKCS#1 v1.5 (RSA PSS only) [Martin
>says needs more text for clarity]
>
>
>- Plan was to not go forward without proof that this doesn't weaken
>PKI security; a by-hand one is in progress
>
>
>- Refine "Delegated credentials" term to "Delegated authentication
>keys"
>
>
>- Plan is to start WGLC, but make sure it isn't finished until the
>analysis is done and reviewed by the WG
>
>
>-
>
>
One note: kc2kdm.com is up and working with NSS clients. Please hit it!
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Question about draft-thomson-tls-sic

[Watson Ladd]

Suppose the following sequence of events happen:

1: A CA uses a new intermediate for reasons (no longer cross-signing, etc.)
2: A site gets a certificate from the new intermediate.
3: An older firefox version connects and thinks it knows all the
certificates in the world.

This would seem to break and it wasn't clear to me how this would be
handled. Though as Martin points out this extension is merely codification
of an occasional practice, so maybe this case does actually work out.

Sincerely,
Watson Ladd
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Impact on Network Security draft updated

[Dennis Jackson]

RFC 791  is nearly 40 years old.
RFC 4074 lists 5 forms of deviations from RFC 1034 and explains 
the correct behavior. 
RFC 7021 describes a series of objective tests of RFC 6333 and 
the results. 


The above RFCs describe objective test results and how they 
relate to earlier RFCs. In contrast, this document offers a 
speculative and subjective discussion of possible future impact.


I do not believe there is any precedent supporting publication.


Best,
Dennis

> On Tue, Jul 23, 2019, 3:47 PM Filippo Valsorda  
> ;
> wrote:
>
> > Before any technical or wording feedback, I am confused as to the nature
> > of this document. It does not seem to specify any protocol change or
> > mechanism, and it does not even focus on solutions to move the web further.
> >
> > Instead, it looks like a well edited blog post, presenting the perspective
> > of one segment of the industry. (The perspective seems to also lack
> > consensus, but I believe even that is secondary.) Note how as of
> > draft-camwinget-tls-use-cases-05 there are no IANA considerations, no
> > security considerations, and no occurrences of any of the BCP 14 key words
> > (MUST, SHOULD, etc.).
> >
> > Is there precedent for publishing such a document as an RFC?
> >
>
> I was going to say RFC 691 but no, it recommends changes to the protocol
> (as well as being quite amusing). RFC 4074 comes close describing bad
> behavior without an explicit plea to stop doing it, but has a security
> considerations section. RFC 7021 describes the impact of a particular
> networking technique on applications.
>
> So there is precedent.
>
> Sincerely,
> Watson

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

Re: [TLS] TLS Impact on Network Security draft updated

[Watson Ladd]

On Tue, Jul 23, 2019, 3:47 PM Filippo Valsorda 
wrote:

> Before any technical or wording feedback, I am confused as to the nature
> of this document. It does not seem to specify any protocol change or
> mechanism, and it does not even focus on solutions to move the web further.
>
> Instead, it looks like a well edited blog post, presenting the perspective
> of one segment of the industry. (The perspective seems to also lack
> consensus, but I believe even that is secondary.) Note how as of
> draft-camwinget-tls-use-cases-05 there are no IANA considerations, no
> security considerations, and no occurrences of any of the BCP 14 key words
> (MUST, SHOULD, etc.).
>
> Is there precedent for publishing such a document as an RFC?
>

I was going to say RFC 691 but no, it recommends changes to the protocol
(as well as being quite amusing). RFC 4074 comes close describing bad
behavior without an explicit plea to stop doing it, but has a security
considerations section. RFC 7021 describes the impact of a particular
networking technique on applications.

So there is precedent.

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

Re: [TLS] TLS Impact on Network Security draft updated

[Bret Jordan]

Informational documents do not (usually) have normative statements.  If they 
had normative language, they would be standards track document. 


Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not 
be unscrambled is an egg."

> On Jul 23, 2019, at 6:46 PM, Filippo Valsorda  wrote:
> 
> Before any technical or wording feedback, I am confused as to the nature of 
> this document. It does not seem to specify any protocol change or mechanism, 
> and it does not even focus on solutions to move the web further.
> 
> Instead, it looks like a well edited blog post, presenting the perspective of 
> one segment of the industry. (The perspective seems to also lack consensus, 
> but I believe even that is secondary.) Note how as of 
> draft-camwinget-tls-use-cases-05 there are no IANA considerations, no 
> security considerations, and no occurrences of any of the BCP 14 key words 
> (MUST, SHOULD, etc.).
> 
> Is there precedent for publishing such a document as an RFC?
> 
> ___
> 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] TLS Impact on Network Security draft updated

[Filippo Valsorda]

Before any technical or wording feedback, I am confused as to the nature of 
this document. It does not seem to specify any protocol change or mechanism, 
and it does not even focus on solutions to move the web further.

Instead, it looks like a well edited blog post, presenting the perspective of 
one segment of the industry. (The perspective seems to also lack consensus, but 
I believe even that is secondary.) Note how as of 
draft-camwinget-tls-use-cases-05 there are no IANA considerations, no security 
considerations, and no occurrences of any of the BCP 14 key words (MUST, 
SHOULD, etc.).

Is there precedent for publishing such a document as an RFC?

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

Re: [TLS] TLS Impact on Network Security draft updated

[Eric Rescorla]

Document: draft-camwinget-tls-use-cases-05.txt

I have some technical comments on the current draft.


S 2.2.1.
   Note that even _if_ the SNI is provided by the client, there is no
   guarantee that the actual server responding is the one indicated in
   the SNI from the client.  SNI alone, without comparison of the server
   certificate, does not provide reliable information about the server
   that the client attempts to reach.  Where a client has been
   compromised by malware and connects to a command and control server,
   but presents an innocuous SNI to bypass protective filters, it is
   undetectable under TLS 1.3.

This actually applies to TLS 1.2 as well, because nothing requires
that a nonconformant client use the key supplied in the server certificate
(for instance, it might just just encrypt with a fixed key or tunnel
a key exchange in the TLS handshake somehow). This cannot be detected
by a passive observer.


S 2.2.2.
I don't understand the point of this section. TLS 1.3 resumption PSK
and TLS 1.2 resumption (with tickets, for instance) are largely
isomorphic. In both cases, the client can decline resumption, but that
is true in 1.2 as well (though there's no formal way to do it in 1.2).
As a practical matter, there's no real chance that a standard client
will not let you fall back to a full handshake.

In earlier versions of this document, it didn't recognize this point
and so this section (while misleading) made some sense, but at this
point I would just remove it.


S 2.2.3.
I don't get what this section is trying to say. Previous TLS versions
included anti-downgrade mechanisms, so you could never silently
downgrade versions. The TLS 1.3 anti-downgrade mechanisms are
designed to be stronger than TLS 1.2, but they don't fundamentally
change this situation.


S 2.2.4.
Yes, ESNI causes you problems, but if you are a selective MITM proxy,
you should just disable ESNI on clients using the same mechanisms
that you use to add your own trust anchor.


-Ekr








On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) <
ncamw...@cisco.com> wrote:

> Hi,
>
> Thanks to all the feedback provided, we have updated the
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>
> draft.  At this point, we believe the draft is stable and would like to
> request its publication as an informational draft.
>
>
>
> Warm regards,
>
> Nancy
>
>
>
>
> ___
> 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] Draft minutes for Tuesday

[Salz, Rich]

Are on etherpad at https://etherpad.ietf.org/p/notes-ietf-105-tls

Cut/pasted here (but more readable there):
TLS at IETF 105

Tuesday

Status update (drafts, code points, etc) -- see the slides

CFRG working on PAKE selection;  integration with TLS is obviously important, 
come to CFRG meeting.

Delegated credentials

  *   Server side patch in boringSSL; NSS client side soon to be in FF nightly; 
FB work in progress

  *   Plan to drop LURK mention, remove PKCS#1 v1.5 (RSA PSS only) [Martin says 
needs more text for clarity]

  *   Plan was to not go forward without proof that this doesn't weaken PKI 
security; a by-hand one is in progress

  *   Refine "Delegated credentials" term to "Delegated authentication keys"

  *   Plan is to start WGLC, but make sure it isn't finished until the analysis 
is done and reviewed by the WG

  *
Deprecate MD5 and SHA1 in TLS 1.2

  *   Make signature_algorithms mandatory in handshake; forbig MD5 and SHA1 
algs in that extension

  *   Andrei says MSFT can't enforce now but willing to do so in the future

  *   Consensus in room is to adopt as a WG item; to be confirmed on the list

  *
TLS Flags Extension

  *   TLS 1.2 has 46 extensions; TLS 1.3 has 28; more coming

  *   Many extensions have no data, just 1 bit of data (their presence) -- call 
them "flag extensions"

  *   Various methods (fixed-size bitmask, varying-size bitmask, array of 
bytes, etc)

  *   Can't re-do existing extensions (at least in clientHello), but server 
response and other messages could do so

  *   Consensus in room is to adopt as a WG item; to be confirmed on the list

  *
Suppress Intermediates

  *   A new flag in clientHello says "don't send intermediates"

  *   Not clear what to do if intermediate ends up not being available; options 
are then ugly

  *   Server would ignore extension if it "knows" its chain is "unusual" 
("weird" etc)

  *   There is interest, but not ready to ask for adoption yet

  *
TLS 1.3 Impact on Network Based Security Solutions

  *   Network solutions sometimes insert a middlebox proxy between the client 
and the server, observers TLS metadata to do policy and access control. TLS 1.3 
handshake changes affect these solutions.

  *   Incorporated feedback, has been stable since IETF 104. New commentary 
started today.

  *   Original plan was to ask for publication as informational even though 
it's not in charter.

  *   More people read this draft than any other draft; interesting and 
surprising factoid.

  *   Adjourn without action.

  *

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

[TLS] TLS Flags extension - not sure it makes sense

[Chris Inacio]

I really want the savings on the wire that TLS flags extension provides – and 
so I think it’s really good for the future cTLS but I’m not sure when I get to 
use it in TLS 1.3 negotiation.  It goes in the clientHello message, but how 
will I know that the server uses this extension?  I envision a future where we 
will add the flags extension along with the more expensive 4-bytes version for 
a REALLY long time.

Is there a plan / ability to turn off the 4-byte version?

(BTW: I’m happy if people who really work the details of TLS tell me I 
mis-understand.  I hope I do.)


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

Re: [TLS] TLS Impact on Network Security draft updated

[Ackermann, Michael]

+1

From: TLS  On Behalf Of Bret Jordan
Sent: Tuesday, July 23, 2019 5:52 PM
To: Sean Turner 
Cc: Tony Arcieri ; tls@ietf.org
Subject: Re: [TLS] TLS Impact on Network Security draft updated

 ALERT This email was sent from a source external to BCBSM/BCN.
 DO NOT CLICK links or attachments unless you recognize the sender and trust 
the content.

Thanks Sean.

It is critical that we understand and discuss all sides of an issue and address 
all use cases that market has. Beating people down and trying to attack people 
or their use cases is not something we should be doing in formal standards, 
especially here at the IETF.


Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not 
be unscrambled is an egg."


On Jul 23, 2019, at 4:51 PM, Sean Turner 
mailto:s...@sn3rd.com>> wrote:

Tony,

While you may have concerns or otherwise disagree with the contents of this 
draft, let’s please keep discussion on this list, on all issues, polite and 
professional.

spt
(as co-chair)


On Jul 23, 2019, at 16:05, Tony Arcieri 
mailto:basc...@gmail.com>> wrote:

On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) 
mailto:ncamw...@cisco..com>> wrote:
Hi,

Thanks to all the feedback provided, we have updated the 
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04

draft.  At this point, we believe the draft is stable and would like to request 
its publication as an informational draft.


I read this draft as the latest attempt in a disinformation campaign by 
manufacturers and users of middleboxes that passively decrypt TLS connections 
to politicize and reframe the argument around what is, at its core, a 
fundamentally insecure practice which is incompatible with technically sound 
and highly desirable protocol improvements to TLS.

I implore you stop using overly broad terminology, euphemisms, weasel words, 
and other deceptive language to argue your points.

This draft is titled "TLS 1.3 Impact on Network-Based Security", but the 
subtext is quite clearly the much narrower subfield of middlebox TLS 
decryption. By using such a grandiose title which is deceptively hiding the 
true subject matter, you are implying that middleboxes are the sum total of 
network security.

The draft begins "Enterprises [...] need to defend their information systems 
from attacks originating from both inside and outside their networks." I am 
co-owner of a company which heavily leverages firewalls for layer 3/4 network 
security in conjunction with TLS. We care deeply about network security, and 
believe that our network is *more secure* specifically because we *don't* 
perform middlebox interception of TLS.

I consider our company to be in the category of enterprise TLS users, and as an 
enterprise TLS user who cares deeply about network security, I do not identify 
whatsoever with the claims this draft is making about the needs of enterprise 
TLS users as a whole. In as much as what it describes to "network security", it 
is but one niche consideration within a vastly broader field, and one which is 
increasingly controversial.

I will point out, since you appear to work at Cisco, that your company works on 
approaches to network security (e.g. malware detection) which avoid decrypting 
TLS:

https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption

There is an entire world of network IDS systems beyond middleboxes which 
passively decrypt TLS.

It is factually inaccurate for this draft to be described as "TLS 1.3 Impact on 
Network-Based Security". If you are going to write a draft about the impact of 
TLS 1.3 on middleboxes for passive TLS decryption, please call a spade a spade 
and don't try to hide your true intentions under a bunch of weasel words and 
overly broad claims that make it sound like middlebox-related TLS decryption 
problems are the end of network security as we know it.

My 2c, on behalf of non-middlebox-using enterprise TLS users who feel that 
attempts by middlebox-using enterprise TLS users to weaken TLS in order to 
retain compatibility with their traffic decryption appliances is a threat to 
the security of our enterprise TLS deployments.
___
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



The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without 

Re: [TLS] TLS Impact on Network Security draft updated

[Arnaud.Taddei.IETF]

+1, neutrality is appreciated, thank you Sean

Collecting expressed views should prevail in a neutral way, there is no reason 
why inappropriate behaviour should be tolerated and let the impression that the 
loudest voice is prevailing

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday 23 July 2019 17:52, Bret Jordan  wrote:

> Thanks Sean.
>
> It is critical that we understand and discuss all sides of an issue and 
> address all use cases that market has. Beating people down and trying to 
> attack people or their use cases is not something we should be doing in 
> formal standards, especially here at the IETF.
>
> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can 
> not be unscrambled is an egg."
>
>> On Jul 23, 2019, at 4:51 PM, Sean Turner  wrote:
>>
>> Tony,
>>
>> While you may have concerns or otherwise disagree with the contents of this 
>> draft, let’s please keep discussion on this list, on all issues, polite and 
>> professional.
>>
>> spt
>> (as co-chair)
>>
>>> On Jul 23, 2019, at 16:05, Tony Arcieri  wrote:
>>>
>>> On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) 
>>>  wrote:
>>> Hi,
>>>
>>> Thanks to all the feedback provided, we have updated the 
>>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>>>
>>> draft.  At this point, we believe the draft is stable and would like to 
>>> request its publication as an informational draft.
>>>
>>> I read this draft as the latest attempt in a disinformation campaign by 
>>> manufacturers and users of middleboxes that passively decrypt TLS 
>>> connections to politicize and reframe the argument around what is, at its 
>>> core, a fundamentally insecure practice which is incompatible with 
>>> technically sound and highly desirable protocol improvements to TLS.
>>>
>>> I implore you stop using overly broad terminology, euphemisms, weasel 
>>> words, and other deceptive language to argue your points.
>>>
>>> This draft is titled "TLS 1.3 Impact on Network-Based Security", but the 
>>> subtext is quite clearly the much narrower subfield of middlebox TLS 
>>> decryption. By using such a grandiose title which is deceptively hiding the 
>>> true subject matter, you are implying that middleboxes are the sum total of 
>>> network security.
>>>
>>> The draft begins "Enterprises [...] need to defend their information 
>>> systems from attacks originating from both inside and outside their 
>>> networks." I am co-owner of a company which heavily leverages firewalls for 
>>> layer 3/4 network security in conjunction with TLS. We care deeply about 
>>> network security, and believe that our network is *more secure* 
>>> specifically because we *don't* perform middlebox interception of TLS.
>>>
>>> I consider our company to be in the category of enterprise TLS users, and 
>>> as an enterprise TLS user who cares deeply about network security, I do not 
>>> identify whatsoever with the claims this draft is making about the needs of 
>>> enterprise TLS users as a whole. In as much as what it describes to 
>>> "network security", it is but one niche consideration within a vastly 
>>> broader field, and one which is increasingly controversial.
>>>
>>> I will point out, since you appear to work at Cisco, that your company 
>>> works on approaches to network security (e.g. malware detection) which 
>>> avoid decrypting TLS:
>>>
>>> https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption
>>>
>>> There is an entire world of network IDS systems beyond middleboxes which 
>>> passively decrypt TLS.
>>>
>>> It is factually inaccurate for this draft to be described as "TLS 1.3 
>>> Impact on Network-Based Security". If you are going to write a draft about 
>>> the impact of TLS 1.3 on middleboxes for passive TLS decryption, please 
>>> call a spade a spade and don't try to hide your true intentions under a 
>>> bunch of weasel words and overly broad claims that make it sound like 
>>> middlebox-related TLS decryption problems are the end of network security 
>>> as we know it.
>>>
>>> My 2c, on behalf of non-middlebox-using enterprise TLS users who feel that 
>>> attempts by middlebox-using enterprise TLS users to weaken TLS in order to 
>>> retain compatibility with their traffic decryption appliances is a threat 
>>> to the security of our enterprise TLS deployments.
>>> ___
>>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Impact on Network Security draft updated

[Bret Jordan]

Thanks Sean.  

It is critical that we understand and discuss all sides of an issue and address 
all use cases that market has. Beating people down and trying to attack people 
or their use cases is not something we should be doing in formal standards, 
especially here at the IETF.


Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not 
be unscrambled is an egg."

> On Jul 23, 2019, at 4:51 PM, Sean Turner  wrote:
> 
> Tony,
> 
> While you may have concerns or otherwise disagree with the contents of this 
> draft, let’s please keep discussion on this list, on all issues, polite and 
> professional.
> 
> spt
> (as co-chair)
> 
>> On Jul 23, 2019, at 16:05, Tony Arcieri  wrote:
>> 
>> On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) 
>>  wrote:
>> Hi,
>> 
>> Thanks to all the feedback provided, we have updated the 
>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>> 
>> draft.  At this point, we believe the draft is stable and would like to 
>> request its publication as an informational draft.
>> 
>> 
>> I read this draft as the latest attempt in a disinformation campaign by 
>> manufacturers and users of middleboxes that passively decrypt TLS 
>> connections to politicize and reframe the argument around what is, at its 
>> core, a fundamentally insecure practice which is incompatible with 
>> technically sound and highly desirable protocol improvements to TLS.
>> 
>> I implore you stop using overly broad terminology, euphemisms, weasel words, 
>> and other deceptive language to argue your points.
>> 
>> This draft is titled "TLS 1.3 Impact on Network-Based Security", but the 
>> subtext is quite clearly the much narrower subfield of middlebox TLS 
>> decryption. By using such a grandiose title which is deceptively hiding the 
>> true subject matter, you are implying that middleboxes are the sum total of 
>> network security.
>> 
>> The draft begins "Enterprises [...] need to defend their information systems 
>> from attacks originating from both inside and outside their networks." I am 
>> co-owner of a company which heavily leverages firewalls for layer 3/4 
>> network security in conjunction with TLS. We care deeply about network 
>> security, and believe that our network is *more secure* specifically because 
>> we *don't* perform middlebox interception of TLS.
>> 
>> I consider our company to be in the category of enterprise TLS users, and as 
>> an enterprise TLS user who cares deeply about network security, I do not 
>> identify whatsoever with the claims this draft is making about the needs of 
>> enterprise TLS users as a whole. In as much as what it describes to "network 
>> security", it is but one niche consideration within a vastly broader field, 
>> and one which is increasingly controversial.
>> 
>> I will point out, since you appear to work at Cisco, that your company works 
>> on approaches to network security (e.g. malware detection) which avoid 
>> decrypting TLS:
>> 
>> https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption
>> 
>> There is an entire world of network IDS systems beyond middleboxes which 
>> passively decrypt TLS.
>> 
>> It is factually inaccurate for this draft to be described as "TLS 1.3 Impact 
>> on Network-Based Security". If you are going to write a draft about the 
>> impact of TLS 1.3 on middleboxes for passive TLS decryption, please call a 
>> spade a spade and don't try to hide your true intentions under a bunch of 
>> weasel words and overly broad claims that make it sound like 
>> middlebox-related TLS decryption problems are the end of network security as 
>> we know it.
>> 
>> My 2c, on behalf of non-middlebox-using enterprise TLS users who feel that 
>> attempts by middlebox-using enterprise TLS users to weaken TLS in order to 
>> retain compatibility with their traffic decryption appliances is a threat to 
>> the security of our enterprise TLS deployments.
>> ___
>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Impact on Network Security draft updated

[Watson Ladd]

On Tue, Jul 23, 2019, 1:51 PM Flemming Andreasen  wrote:

>
>
> On 7/23/19 2:35 PM, Watson Ladd wrote:
>
> This draft contains substantial omissions in section 3.
>
> Nothing in TLS 1.3 prevents scanning for servers and examining the
> certificates they present.
>
> Agreed, however there is no guarantee that the server will present the
> same certificate and other TLS parameters as it will for a particular
> client connection
>

True but for 99% (WAG) of setups this is driven by SNI and ciphersuite
which you see in the clear.

Nothing in TLS 1.3 prevents using reverse proxies to provide WAF
> functionality.
>
> Agreed however you need to terminate the TLS 1.3 connection at that WAF
>

That doesn't sound like a big difficulty especially given the WAF was
intercepting and decrypting before. What is the gain here? It's also more
secure: there is fun with headers that doesnt work if the WAF normalizes.

PCI-DSS compliance is not at odds with deploying TLS 1.3. In fact the
> citation to A2 is to a sun-setting of all pre TLS 1.2 versions for point of
> sale terminals. I really don't see where the conflict exists since all
> ciphers in 1.3 are secure.
>
> I'll defer to one of my co-authors on this one.
>
> The absence of these solutions means the draft overstates the impact of
> the increased protection TLS 1.3 provides. It's disappointing to see
> sustained and persistent opposition to encryption and privacy despite
> multiple RFCs saying that yes we should encrypt all the things.
>
> The draft is submitted with the intent of informing the community about
> impacts as we see them. The authors welcome discussion and constructive
> feedback and we will be happy to update and improve the draft accordingly
> when such information is provided and consensus forms around it. Specific
> text suggestions will be even better.
>

I seem to remember a discussion during the last call of TLS 1.3 where these
issues were raised. I think at minimum pointing out that this only affects
some networks with some choices of how to do things and that other
techniques (like reverse proxies) can achieve the same ends is necessary if
the goal is actually to help operators cope with TLS 1.3.


> Thanks
>
> -- Flemming
>
>
> On Tue, Jul 23, 2019, 8:08 AM Bret Jordan  wrote:
>
>> Nancy,
>>
>> I support this work and think this draft should be published. This is a
>> yet another good write up on some of the requirements that are needed for
>> operational security.
>>
>> Thanks,
>> Bret
>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
>> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
>> can not be unscrambled is an egg."
>>
>> On Jul 21, 2019, at 9:51 AM, Nancy Cam-Winget (ncamwing) <
>> ncamw...@cisco.com> wrote:
>>
>> Hi,
>> Thanks to all the feedback provided, we have updated the
>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>> draft.  At this point, we believe the draft is stable and would like to
>> request its publication as an informational draft.
>>
>> Warm regards,
>> Nancy
>>
>>
>> ___
>> 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 mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Impact on Network Security draft updated

[Salz, Rich]

What does it say that RFC 8404 doesn’t?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Impact on Network Security draft updated

[Flemming Andreasen]

On 7/23/19 4:14 PM, Viktor Dukhovni wrote:

On Sun, Jul 21, 2019 at 01:51:32PM +, Nancy Cam-Winget (ncamwing) wrote:


Thanks to all the feedback provided, we have updated the 
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
draft.  At this point, we believe the draft is stable and would like to request 
its publication as an informational draft.

I found the language of the draft (especially the introduction)
somewhat turgid and repetitive to the point of significantly
detracting from readability.  I think the draft needs substantial
editing for simplicity and clarity.

If you have any specific text suggestions, please let us know.

As to specific technical issues, I don't understand the point being
made in Section 2.2.2 about client key shares and resumption:

In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK),
which can be negotiated as part of an initial handshake and then used
in a subsequent handshake to perform resumption using the PSK.  TLS
1.3 states that the client SHOULD include a "key_share" extension to
enable the server to decline resumption and fall back to a full
handshake, however it is not an absolute requirement.

Example scenarios that are impacted by this are middleboxes that were
not part of the initial handshake, and hence do not know the PSK.  If
the client does not include the "key_share" extension, the middlebox
cannot force a fallback to the full handshake.  If the middlebox
policy requires it to inspect the session, it will have to fail the
connection instead.

[ AFAIK, even with PSK-based resumption, and even when the client's
   initial key share was not acceptable to server, the server can still
   perform a full handshake after HRR.  An MiTM middle-box can replace
   the server's HRR with its own, and then decline the client's PSK
   and perform a full handshake. ]


We will take another look at this part.


I also found the malicious server argument in section 2.2.1 somewhat
unconvincing, since malicious servers have lots of (previously)
innocuous domains to choose from, or can present self-signed
certificates for any SNI of their choice.
It all depends on what you are willing to accept. I still see a 
difference with TLS 1.3 here.




The impact of TLS 1.3 is largely limited to making it more difficult
to whitelist "known good" servers from MiTM inspection.  With TLS
1.3 a middle box that wants to be sure to MiTM sessions to "bad"
servers, must also MiTM sessions to "good" servers (in order to
determine that they're really "known good"), because authenticating
a "good" server is no longer possible without MiTM interception.
Blacklists of "known bad" are easily bypassed even with TLS 1.2.

Middleboxes that are limited to closing TCP connections for the
"known bad", are not particularly effective with TLS 1.2, and will
be increasingly less so as attacks become more sophisticated.  A
middlebox that wants to detect the bad must do MiTM interception,
and with TLS 1.3 will need to intercept *all* traffic, even the
previously "known good", once the "known good" peer deploys TLS 1.3.

Yes, optimizing out interception of the "authenticated known good"
is no longer possible.


Ok - thanks for the feedback.

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

Re: [TLS] TLS Impact on Network Security draft updated

[Flemming Andreasen]

On 7/23/19 4:05 PM, Tony Arcieri wrote:
On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) 
mailto:ncamw...@cisco.com>> wrote:


Hi,

Thanks to all the feedback provided, we have updated the
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04

draft. At this point, we believe the draft is stable and would
like to request its publication as an informational draft.


I read this draft as the latest attempt in a disinformation campaign 
by manufacturers and users of middleboxes that passively decrypt TLS 
connections to politicize and reframe the argument around what is, at 
its core, a fundamentally insecure practice which is incompatible with 
technically sound and highly desirable protocol improvements to TLS.


I implore you stop using overly broad terminology, euphemisms, weasel 
words, and other deceptive language to argue your points.


I am not a mind-reader, so I will refrain from attributing malice to 
your choice of words - I would appreciate it if you would extend the 
same courtesy.


This draft is titled "TLS 1.3 Impact on Network-Based Security", but 
the subtext is quite clearly the much narrower subfield of middlebox 
TLS decryption. By using such a grandiose title which is deceptively 
hiding the true subject matter, you are implying that middleboxes are 
the sum total of network security.
No such implication is intended - we will look for a more accurate 
document title.


The draft begins "Enterprises [...] need to defend their information 
systems from attacks originating from both inside and outside their 
networks." I am co-owner of a company which heavily leverages 
firewalls for layer 3/4 network security in conjunction with TLS. We 
care deeply about network security, and believe that our network is 
*more secure* specifically because we *don't* perform middlebox 
interception of TLS.


I consider our company to be in the category of enterprise TLS users, 
and as an enterprise TLS user who cares deeply about network security, 
I do not identify whatsoever with the claims this draft is making 
about the needs of enterprise TLS users as a whole. In as much as what 
it describes to "network security", it is but one niche consideration 
within a vastly broader field, and one which is increasingly 
controversial.


It is indeed controversial, and different enterprises have different 
views on these. I know this because I regularly interact with a number 
of these across different industries.


I will point out, since you appear to work at Cisco, that your company 
works on approaches to network security (e.g. malware detection) which 
avoid decrypting TLS:


https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption

I am quite familiar with this. Please note that it does not provide a 
full replacement for all existing capabilities


There is an entire world of network IDS systems beyond middleboxes 
which passively decrypt TLS.


Are you saying that it is possible to passively decrypt TLS 1.3 sessions 
without being a MITM (or otherwise sharing keying material) ?


It is factually inaccurate for this draft to be described as "TLS 1.3 
Impact on Network-Based Security". If you are going to write a draft 
about the impact of TLS 1.3 on middleboxes for passive TLS decryption, 
please call a spade a spade and don't try to hide your true intentions 
under a bunch of weasel words and overly broad claims that make it 
sound like middlebox-related TLS decryption problems are the end of 
network security as we know it.


My 2c, on behalf of non-middlebox-using enterprise TLS users who feel 
that attempts by middlebox-using enterprise TLS users to weaken TLS in 
order to retain compatibility with their traffic decryption appliances 
is a threat to the security of our enterprise TLS deployments.

Please see my earlier comments on this.

Thanks

-- Flemming



___
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] TLS Impact on Network Security draft updated

[Sean Turner]

Tony,

While you may have concerns or otherwise disagree with the contents of this 
draft, let’s please keep discussion on this list, on all issues, polite and 
professional.

spt
(as co-chair)

> On Jul 23, 2019, at 16:05, Tony Arcieri  wrote:
> 
> On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) 
>  wrote:
> Hi,
> 
> Thanks to all the feedback provided, we have updated the 
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
> 
> draft.  At this point, we believe the draft is stable and would like to 
> request its publication as an informational draft.
> 
> 
> I read this draft as the latest attempt in a disinformation campaign by 
> manufacturers and users of middleboxes that passively decrypt TLS connections 
> to politicize and reframe the argument around what is, at its core, a 
> fundamentally insecure practice which is incompatible with technically sound 
> and highly desirable protocol improvements to TLS.
> 
> I implore you stop using overly broad terminology, euphemisms, weasel words, 
> and other deceptive language to argue your points.
> 
> This draft is titled "TLS 1.3 Impact on Network-Based Security", but the 
> subtext is quite clearly the much narrower subfield of middlebox TLS 
> decryption. By using such a grandiose title which is deceptively hiding the 
> true subject matter, you are implying that middleboxes are the sum total of 
> network security.
> 
> The draft begins "Enterprises [...] need to defend their information systems 
> from attacks originating from both inside and outside their networks." I am 
> co-owner of a company which heavily leverages firewalls for layer 3/4 network 
> security in conjunction with TLS. We care deeply about network security, and 
> believe that our network is *more secure* specifically because we *don't* 
> perform middlebox interception of TLS.
> 
> I consider our company to be in the category of enterprise TLS users, and as 
> an enterprise TLS user who cares deeply about network security, I do not 
> identify whatsoever with the claims this draft is making about the needs of 
> enterprise TLS users as a whole. In as much as what it describes to "network 
> security", it is but one niche consideration within a vastly broader field, 
> and one which is increasingly controversial.
> 
> I will point out, since you appear to work at Cisco, that your company works 
> on approaches to network security (e.g. malware detection) which avoid 
> decrypting TLS:
> 
> https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption
> 
> There is an entire world of network IDS systems beyond middleboxes which 
> passively decrypt TLS.
> 
> It is factually inaccurate for this draft to be described as "TLS 1.3 Impact 
> on Network-Based Security". If you are going to write a draft about the 
> impact of TLS 1.3 on middleboxes for passive TLS decryption, please call a 
> spade a spade and don't try to hide your true intentions under a bunch of 
> weasel words and overly broad claims that make it sound like 
> middlebox-related TLS decryption problems are the end of network security as 
> we know it.
> 
> My 2c, on behalf of non-middlebox-using enterprise TLS users who feel that 
> attempts by middlebox-using enterprise TLS users to weaken TLS in order to 
> retain compatibility with their traffic decryption appliances is a threat to 
> the security of our enterprise TLS deployments.
> ___
> 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] TLS Impact on Network Security draft updated

[Flemming Andreasen]

On 7/23/19 2:35 PM, Watson Ladd wrote:

This draft contains substantial omissions in section 3.

Nothing in TLS 1.3 prevents scanning for servers and examining the 
certificates they present.
Agreed, however there is no guarantee that the server will present the 
same certificate and other TLS parameters as it will for a particular 
client connection
Nothing in TLS 1.3 prevents using reverse proxies to provide WAF 
functionality.

Agreed however you need to terminate the TLS 1.3 connection at that WAF
PCI-DSS compliance is not at odds with deploying TLS 1.3. In fact the 
citation to A2 is to a sun-setting of all pre TLS 1.2 versions for 
point of sale terminals. I really don't see where the conflict exists 
since all ciphers in 1.3 are secure.



I'll defer to one of my co-authors on this one.
The absence of these solutions means the draft overstates the impact 
of the increased protection TLS 1.3 provides. It's disappointing to 
see sustained and persistent opposition to encryption and privacy 
despite multiple RFCs saying that yes we should encrypt all the things.


The draft is submitted with the intent of informing the community about 
impacts as we see them. The authors welcome discussion and constructive 
feedback and we will be happy to update and improve the draft 
accordingly when such information is provided and consensus forms around 
it. Specific text suggestions will be even better.


Thanks

-- Flemming


On Tue, Jul 23, 2019, 8:08 AM Bret Jordan > wrote:


Nancy,

I support this work and think this draft should be published. This
is a yet another good write up on some of the requirements that
are needed for operational security.

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing
that can not be unscrambled is an egg."


On Jul 21, 2019, at 9:51 AM, Nancy Cam-Winget (ncamwing)
mailto:ncamw...@cisco.com>> wrote:

Hi,
Thanks to all the feedback provided, we have updated
thehttps://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
draft.  At this point, we believe the draft is stable and would
like to request its publication as an informational draft.
Warm regards,
Nancy
___
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 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] TLS Impact on Network Security draft updated

[Ackermann, Michael]

+1
And I would add that the pervasive effects of encryption are not limited to 
security of systems,  but limit the abilities of other system management, 
monitoring and diagnostic platforms as well.


From: TLS  On Behalf Of Mark O
Sent: Tuesday, July 23, 2019 4:28 PM
To: tls@ietf.org
Subject: Re: [TLS] TLS Impact on Network Security draft updated

 ALERT This email was sent from a source external to BCBSM/BCN.
 DO NOT CLICK links or attachments unless you recognize the sender and trust 
the content.


I don’t have a preference for whether this draft should become a working group 
item, or become an AD-sponsored or individual submission​, but in any case it 
contains important additions to the security considerations of RFC 8446. The 
use-cases it details are real-life scenarios where the introduction of TLS 1.3 
in place of 1.2 has an impact on the security of systems (according to the 
threat model outlined in RFC 3552 and the additional non-ComSec threats that 
have been identified subsequent to the publication of RFC 3552); therefore they 
should be accurately and publicly recorded.

-- Mark



On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) 
; wrote:



> Hi,

>

> Thanks to all the feedback provided, we have updated the

> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04

>

> draft.  At this point, we believe the draft is stable and would like to

> request its publication as an informational draft.

>

>

>

> Warm regards,

>

> Nancy

>

>

>

>

> ___

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls






This information is exempt under the Freedom of Information Act 2000 (FOIA) and 
may be exempt under other UK information legislation. Refer any FOIA queries to 
ncscinfo...@ncsc.gov.uk. All material is UK 
Crown Copyright ©



The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Impact on Network Security draft updated

[Mark O]

I don’t have a preference for whether this draft should become a working group 
item, or become an AD-sponsored or individual submission​, but in any case it 
contains important additions to the security considerations of RFC 8446. The 
use-cases it details are real-life scenarios where the introduction of TLS 1.3 
in place of 1.2 has an impact on the security of systems (according to the 
threat model outlined in RFC 3552 and the additional non-ComSec threats that 
have been identified subsequent to the publication of RFC 3552); therefore they 
should be accurately and publicly recorded.

-- Mark



On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) 
; wrote:



> Hi,

>

> Thanks to all the feedback provided, we have updated the

> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04

>

> draft.  At this point, we believe the draft is stable and would like to

> request its publication as an informational draft.

>

>

>

> Warm regards,

>

> Nancy

>

>

>

>

> ___

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls






This information is exempt under the Freedom of Information Act 2000 (FOIA) and 
may be exempt under other UK information legislation. Refer any FOIA queries to 
ncscinfo...@ncsc.gov.uk. All material is UK Crown Copyright ©

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

Re: [TLS] TLS Impact on Network Security draft updated

[Viktor Dukhovni]

On Sun, Jul 21, 2019 at 01:51:32PM +, Nancy Cam-Winget (ncamwing) wrote:

> Thanks to all the feedback provided, we have updated the 
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
> draft.  At this point, we believe the draft is stable and would like to 
> request its publication as an informational draft.

I found the language of the draft (especially the introduction)
somewhat turgid and repetitive to the point of significantly
detracting from readability.  I think the draft needs substantial
editing for simplicity and clarity.

As to specific technical issues, I don't understand the point being
made in Section 2.2.2 about client key shares and resumption:

   In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK),
   which can be negotiated as part of an initial handshake and then used
   in a subsequent handshake to perform resumption using the PSK.  TLS
   1.3 states that the client SHOULD include a "key_share" extension to
   enable the server to decline resumption and fall back to a full
   handshake, however it is not an absolute requirement.

   Example scenarios that are impacted by this are middleboxes that were
   not part of the initial handshake, and hence do not know the PSK.  If
   the client does not include the "key_share" extension, the middlebox
   cannot force a fallback to the full handshake.  If the middlebox
   policy requires it to inspect the session, it will have to fail the
   connection instead.

[ AFAIK, even with PSK-based resumption, and even when the client's
  initial key share was not acceptable to server, the server can still
  perform a full handshake after HRR.  An MiTM middle-box can replace
  the server's HRR with its own, and then decline the client's PSK
  and perform a full handshake. ]

I also found the malicious server argument in section 2.2.1 somewhat
unconvincing, since malicious servers have lots of (previously)
innocuous domains to choose from, or can present self-signed
certificates for any SNI of their choice.

The impact of TLS 1.3 is largely limited to making it more difficult
to whitelist "known good" servers from MiTM inspection.  With TLS
1.3 a middle box that wants to be sure to MiTM sessions to "bad"
servers, must also MiTM sessions to "good" servers (in order to
determine that they're really "known good"), because authenticating
a "good" server is no longer possible without MiTM interception.
Blacklists of "known bad" are easily bypassed even with TLS 1.2.

Middleboxes that are limited to closing TCP connections for the
"known bad", are not particularly effective with TLS 1.2, and will
be increasingly less so as attacks become more sophisticated.  A
middlebox that wants to detect the bad must do MiTM interception,
and with TLS 1.3 will need to intercept *all* traffic, even the
previously "known good", once the "known good" peer deploys TLS 1.3.

Yes, optimizing out interception of the "authenticated known good"
is no longer possible.

-- 
Viktor.

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

Re: [TLS] TLS Impact on Network Security draft updated

[Tony Arcieri]

On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) <
ncamw...@cisco.com> wrote:

> Hi,
>
> Thanks to all the feedback provided, we have updated the
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>
> draft.  At this point, we believe the draft is stable and would like to
> request its publication as an informational draft.
>

I read this draft as the latest attempt in a disinformation campaign by
manufacturers and users of middleboxes that passively decrypt TLS
connections to politicize and reframe the argument around what is, at its
core, a fundamentally insecure practice which is incompatible with
technically sound and highly desirable protocol improvements to TLS.

I implore you stop using overly broad terminology, euphemisms, weasel
words, and other deceptive language to argue your points.

This draft is titled "TLS 1.3 Impact on Network-Based Security", but the
subtext is quite clearly the much narrower subfield of middlebox TLS
decryption. By using such a grandiose title which is deceptively hiding the
true subject matter, you are implying that middleboxes are the sum total of
network security.

The draft begins "Enterprises [...] need to defend their information
systems from attacks originating from both inside and outside their
networks." I am co-owner of a company which heavily leverages firewalls for
layer 3/4 network security in conjunction with TLS. We care deeply about
network security, and believe that our network is *more secure*
specifically because we *don't* perform middlebox interception of TLS.

I consider our company to be in the category of enterprise TLS users, and
as an enterprise TLS user who cares deeply about network security, I do not
identify whatsoever with the claims this draft is making about the needs of
enterprise TLS users as a whole. In as much as what it describes to
"network security", it is but one niche consideration within a vastly
broader field, and one which is increasingly controversial.

I will point out, since you appear to work at Cisco, that your company
works on approaches to network security (e.g. malware detection) which
avoid decrypting TLS:

https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption

There is an entire world of network IDS systems beyond middleboxes which
passively decrypt TLS.

It is factually inaccurate for this draft to be described as "TLS 1.3
Impact on Network-Based Security". If you are going to write a draft about
the impact of TLS 1.3 on middleboxes for passive TLS decryption, please
call a spade a spade and don't try to hide your true intentions under a
bunch of weasel words and overly broad claims that make it sound like
middlebox-related TLS decryption problems are the end of network security
as we know it.

My 2c, on behalf of non-middlebox-using enterprise TLS users who feel that
attempts by middlebox-using enterprise TLS users to weaken TLS in order to
retain compatibility with their traffic decryption appliances is a threat
to the security of our enterprise TLS deployments.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Impact on Network Security draft updated

[Watson Ladd]

This draft contains substantial omissions in section 3.

Nothing in TLS 1.3 prevents scanning for servers and examining the
certificates they present. Nothing in TLS 1.3 prevents using reverse
proxies to provide WAF functionality. PCI-DSS compliance is not at odds
with deploying TLS 1.3. In fact the citation to A2 is to a sun-setting of
all pre TLS 1.2 versions for point of sale terminals. I really don't see
where the conflict exists since all ciphers in 1.3 are secure.

The absence of these solutions means the draft overstates the impact of the
increased protection TLS 1.3 provides. It's disappointing to see sustained
and persistent opposition to encryption and privacy despite multiple RFCs
saying that yes we should encrypt all the things.


On Tue, Jul 23, 2019, 8:08 AM Bret Jordan  wrote:

> Nancy,
>
> I support this work and think this draft should be published. This is a
> yet another good write up on some of the requirements that are needed for
> operational security.
>
> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
> can not be unscrambled is an egg."
>
> On Jul 21, 2019, at 9:51 AM, Nancy Cam-Winget (ncamwing) <
> ncamw...@cisco.com> wrote:
>
> Hi,
> Thanks to all the feedback provided, we have updated the
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
> draft.  At this point, we believe the draft is stable and would like to
> request its publication as an informational draft.
>
> Warm regards,
> Nancy
>
>
> ___
> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Impact on Network Security draft updated

[Bret Jordan]

Nancy,

I support this work and think this draft should be published. This is a yet 
another good write up on some of the requirements that are needed for 
operational security. 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not 
be unscrambled is an egg."

> On Jul 21, 2019, at 9:51 AM, Nancy Cam-Winget (ncamwing)  
> wrote:
> 
> Hi,
> Thanks to all the feedback provided, we have updated the 
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04 
> 
> draft.  At this point, we believe the draft is stable and would like to 
> request its publication as an informational draft.
>  
> Warm regards, 
> Nancy
>  
>  
> ___
> 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