Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Yoav Nir]

> On 8 Nov 2017, at 2:25, Watson Ladd  wrote:
> 
> On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar  wrote:
>> FWIW: In my experience middleboxes don't ossify based on what the spec says,
>> they ossify based on what they see on the wire. So, if common
>> implementations send CCS in a particular way, that's what will get --- and,
>> I'll argue, what has gotten --- ossified. I also agree with David and Eric
>> that compatibility mode shouldn't be required because QUIC doesn't need it.
> 
> What does compatibility mode mean here? If we end up with having two
> slightly different versions of TLS 1.3, one that looks more like TLS
> 1.2 and the other that does not, that doesn't seem like a good thing
> to me.

So you’d prefer that we just make this compatibility mode mandatory and always 
use it?  Despite the wasted bits, I think I’m with you on that.

Yoav

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

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Yoav Nir]

> On 8 Nov 2017, at 2:32, Salz, Rich  wrote:
> 
> ➢ Given that we're almost there, and that only really browsers are
> asking for these hacks, and that even some of those were almost ready
> to ship without these hacks, I don't think that this is entirely
> unrealistic as an aspiration.
> 
> The Internet is more than just a couple of browser executables.
> 
> Does nobody think of the servers?
>  
> I do, but I don't really see how they're relevant for this question. Don't 
> the servers control the middleboxes they are behind?
>  
> The smiley got lost.  But smiley isn’t quite the right emoticon either. 

Maybe we need a resigned to the harsh reality emoticon. Oh wait, there is one 
[1]

> But to answer your question: no, the often don’t.  And it’s not just the 
> middleboxes they are behind, but all those along the way.

The server-side middleboxes tend to be somewhat higher quality and get more 
regular updates. There are also fewer vendors, so the problem is more 
manageable.

>  
> To say that only browsers were asking for these hacks is also a little 
> disingenuous.  It was a self-selected design group (to be charitable) that 
> mostly worked by themselves without the whole WG being involved.  I’m glad we 
> seem to be ending up with something that works, with the only thing being 
> lost is some nerd esthetics, but let’s not forget the (to me, disappointing) 
> way the whole thing went down: a collaboration among, and only among, Google, 
> Mozilla, and Facebook.

Sure. Whatever applies to browsers applies to every app or library that uses a 
web service. So wget, cURL, any of the libraries for Java, whatever you call 
the libraries behind apps on the various mobile platforms. 

Yoav 

[1] https://www.urbandictionary.com/define.php?term=%F0%9F%98%8C


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

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[David Benjamin]

On Tue, Nov 7, 2017 at 7:32 PM Eric Rescorla  wrote:

> On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd  wrote:
>
>> On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar  wrote:
>> > FWIW: In my experience middleboxes don't ossify based on what the spec
>> says,
>> > they ossify based on what they see on the wire. So, if common
>> > implementations send CCS in a particular way, that's what will get ---
>> and,
>> > I'll argue, what has gotten --- ossified. I also agree with David and
>> Eric
>> > that compatibility mode shouldn't be required because QUIC doesn't need
>> it.
>>
>> What does compatibility mode mean here?
>
>
> It means:
>
> 1. Send the fake session_id
> 2. Send a bunch of spurious CCS values.
>
>
> If we end up with having two
>> slightly different versions of TLS 1.3, one that looks more like TLS
>> 1.2 and the other that does not, that doesn't seem like a good thing
>> to me.
>>
>
> Well, the idea is that this is a purely local decision by one side.
>

In particular, either "mode" leaves everything interoperable with
everything else, modulo middlebox misbehavior. The arrangement with CCS and
session_id is that the sender MAY send some random vestigial junk that the
receiver MUST ignore.

If you know your implementation lives in a context whether it doesn't
matter (QUIC, internal networks, a happy unrealistic future where networks
are made of unicorns and sunshine instead of middleboxes), you can avoid
sending the useless bits. Otherwise, you probably want to send it.

-Ekr
>
>
>> My understanding is we already have ossification here and the debate
>> is what to do about it.
>>
>>
>> --
>> "Man is born free, but everywhere he is in chains".
>> --Rousseau.
>>
> ___
> 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] PR#1091: Changes to provide middlebox robustness

[Martin Thomson]

On Tue, Nov 7, 2017 at 5:19 AM, Eric Rescorla  wrote:
> - The client sends a fake session_id and the server echoes it

One friendly amendment.  I think that we should insist (with a MUST)
that the server send CCS in the case that it receives a non-empty
session_id.  That gives clients the ability to insist on use of the
compatibility hack by a server.

Evidence shows that the server can't ensure that these (expletive
deleted) middleboxes don't mess with the connect unless the client
takes the steps that are outlined here, so it has no way to control
the use of the compatibility mode.  On the other hand, having the
server not send CCS when compatibility mode was needed would somewhat
undermine the client's efforts.

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

Re: [TLS] network-based security solution use cases

[Stephen Farrell]

Hiya,

On 08/11/17 00:23, Nancy Cam-Winget (ncamwing) wrote:
> Hi Stephen,
> Please see below:
> 
> On 11/7/17, 4:08 PM, "Stephen Farrell"  wrote:
> 
> 
> Hiya,
> 
> On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote:
> > Hi Stephen, Adding to Flemming’s comment,  finding “exact quotes”
> > will be difficult 
> 
> I'm sorry but when making a claim that such and such a regulation
> *requires* breaking TLS then you really do need to be that precise.
> [NCW] In TLS 1.2, not sure why you state *requires* as there is the 
> visibility afforded to 
> at least allow for the identity disclosure to enable white or blacklist for 
> example.  

Quoting from your draft wrt PCI-DSS:

" Requirement #2 (and Appendix A2 as it concerns TLS)
   describes the need to be able to detect protocol and protocol usage
   correctness."

That one is nice - you seem to be arguing for protocol non-conformance
(or for weakening conformant implementations) in order to help ensure
"protocol usage correctness." That kind of makes my head spin.

Another quote wrt NERC:

" In fact, regulatory standards such as NERC CIP
   [NERCCIP] place strong requirements about network perimeter security
   and its ability to have visibility to provide security information to
   the security management and control systems. "

Where exactly did you see those "strong requirements" that presumably
*require* breaking TLS?

I don't see them.

When I or others ask to be shown them we don't get shown them.

To me that means those are not *required*.

> 
> > as their intent is really not to break things but
> > rather want to ensure that inspection and oversight is available to
> > affect guards/protections within an (enterprise/data center)
> > infrastructure.   That said, PCI and other regulations will have a
> > lot of documents that one has to go through….one that kind-of calls
> > explicitly to the use of packet inspection, firewalling and such is
> > in:
> > 
> > https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.pdf
> 
> The first mention of TLS there talks about protecting administrator
> passwords via TLS. That totally argues against deployment of any kind
> of MitM infrastructure.
> [NCW] Agreed, they also state in ensuring that the newest TLS version where 
> possible is used.  BUT, they also expect monitoring and troubleshooting.

Sure. Not all monitoring *requires* breaking TLS. Same for
troubleshooting.

Of course people who sell kit for that or have been doing
that for a while might want to see what they do as being
mandatory/required/regulated-for but I'm not seeing it.

> 
> > 
> > It is an assessment questionnaire for vendors to evaluate their
> > compliance, the requirements speak to securing the network and
> > systems including firewalls, DMZs and the ability to do packet
> > inspection.
> 
> Please point me at the specific text. Given you added PCI-DSS to
> your document I would assume you did the work already. If not,
> that's a bit odd.
> [NCW] From the link above, you can look at requirements in 1.3,
> also Requirement 10 details the need to monitor and provide audit trails
> for network resources and cardholder data

You mean 1.3 on page 6 I guess. I see nothing on pages 6 or 7
that call for MitMing TLS. That seems to be about addressing
and DMZs and firewall and router configs.

Requirement 10 seems to be dealing with audit of accesses to
cardholder data, not with TLS at all. I read pages 50-55 for
that.

Honestly, what you're saying is there does not seem to be
there.

S.


> 
> S.
> 
> 
> > 
> > Thanks, Nancy
> > 
> > On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)"
> >  wrote:
> > 
> > Thanks for taking an initial look at the document Stephen - please
> > see below for responses so far
> > 
> > On 11/7/17 4:13 AM, Stephen Farrell wrote:
> >> Hiya,
> >> 
> >> On 07/11/17 02:48, Flemming Andreasen wrote:
> >>> We didn't draw any particular line, but the use case scenarios
> >>> that we tried to highlight are those related to overall security
> >>> and regulatory requirements (including public sector)
> >> I had a quick look at the draft (will try read properly en-route
> >> to ietf-100) and I followed the reference to [1] but that only lead
> >> to a forest of documents in which I didn't find any reference to
> >> breaking TLS so far at least. Can you provide an explicit pointer
> >> to the exact document on which that claim is based?
> > For NERC, you can look under  "(CIP) Critital Infrastructure 
> > Protection". CIP-005-5 for example covers the electronic security 
> > perimeter, which has a couple of relevant requirements and associated
> > text:
> > 
> > 
> 

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Eric Rescorla]

On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd  wrote:

> On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar  wrote:
> > FWIW: In my experience middleboxes don't ossify based on what the spec
> says,
> > they ossify based on what they see on the wire. So, if common
> > implementations send CCS in a particular way, that's what will get ---
> and,
> > I'll argue, what has gotten --- ossified. I also agree with David and
> Eric
> > that compatibility mode shouldn't be required because QUIC doesn't need
> it.
>
> What does compatibility mode mean here?


It means:

1. Send the fake session_id
2. Send a bunch of spurious CCS values.


If we end up with having two
> slightly different versions of TLS 1.3, one that looks more like TLS
> 1.2 and the other that does not, that doesn't seem like a good thing
> to me.
>

Well, the idea is that this is a purely local decision by one side.

-Ekr


> My understanding is we already have ossification here and the debate
> is what to do about it.
>
>
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Salz, Rich]

➢ Given that we're almost there, and that only really browsers are
asking for these hacks, and that even some of those were almost ready
to ship without these hacks, I don't think that this is entirely
unrealistic as an aspiration.

The Internet is more than just a couple of browser executables.

Does nobody think of the servers?


  *   I do, but I don't really see how they're relevant for this question. 
Don't the servers control the middleboxes they are behind?

The smiley got lost.  But smiley isn’t quite the right emoticon either.  But to 
answer your question: no, the often don’t.  And it’s not just the middleboxes 
they are behind, but all those along the way.

To say that only browsers were asking for these hacks is also a little 
disingenuous.  It was a self-selected design group (to be charitable) that 
mostly worked by themselves without the whole WG being involved.  I’m glad we 
seem to be ending up with something that works, with the only thing being lost 
is some nerd esthetics, but let’s not forget the (to me, disappointing) way the 
whole thing went down: a collaboration among, and only among, Google, Mozilla, 
and Facebook.


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

Re: [TLS] network-based security solution use cases

[Watson Ladd]

On Tue, Nov 7, 2017 at 4:23 PM, Nancy Cam-Winget (ncamwing)
 wrote:
> Hi Stephen,
> Please see below:
>
> On 11/7/17, 4:08 PM, "Stephen Farrell"  wrote:
>
>
> Hiya,
>
> On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote:
> > Hi Stephen, Adding to Flemming’s comment,  finding “exact quotes”
> > will be difficult
>
> I'm sorry but when making a claim that such and such a regulation
> *requires* breaking TLS then you really do need to be that precise.
> [NCW] In TLS 1.2, not sure why you state *requires* as there is the 
> visibility afforded to
> at least allow for the identity disclosure to enable white or blacklist for 
> example.
>
> > as their intent is really not to break things but
> > rather want to ensure that inspection and oversight is available to
> > affect guards/protections within an (enterprise/data center)
> > infrastructure.   That said, PCI and other regulations will have a
> > lot of documents that one has to go through….one that kind-of calls
> > explicitly to the use of packet inspection, firewalling and such is
> > in:
> >
> > https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.pdf
>
> The first mention of TLS there talks about protecting administrator
> passwords via TLS. That totally argues against deployment of any kind
> of MitM infrastructure.
> [NCW] Agreed, they also state in ensuring that the newest TLS version where
> possible is used.  BUT, they also expect monitoring and troubleshooting.
>
> >
> > It is an assessment questionnaire for vendors to evaluate their
> > compliance, the requirements speak to securing the network and
> > systems including firewalls, DMZs and the ability to do packet
> > inspection.
>
> Please point me at the specific text. Given you added PCI-DSS to
> your document I would assume you did the work already. If not,
> that's a bit odd.
> [NCW] From the link above, you can look at requirements in 1.3,
> also Requirement 10 details the need to monitor and provide audit trails
> for network resources and cardholder data.

None of the questions in requirement 10 require middlebox interception.
>
> S.
>
>
> >
> > Thanks, Nancy
> >
> > On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)"
> >  wrote:
> >
> > Thanks for taking an initial look at the document Stephen - please
> > see below for responses so far
> >
> > On 11/7/17 4:13 AM, Stephen Farrell wrote:
> >> Hiya,
> >>
> >> On 07/11/17 02:48, Flemming Andreasen wrote:
> >>> We didn't draw any particular line, but the use case scenarios
> >>> that we tried to highlight are those related to overall security
> >>> and regulatory requirements (including public sector)
> >> I had a quick look at the draft (will try read properly en-route
> >> to ietf-100) and I followed the reference to [1] but that only lead
> >> to a forest of documents in which I didn't find any reference to
> >> breaking TLS so far at least. Can you provide an explicit pointer
> >> to the exact document on which that claim is based?
> > For NERC, you can look under  "(CIP) Critital Infrastructure
> > Protection". CIP-005-5 for example covers the electronic security
> > perimeter, which has a couple of relevant requirements and associated
> > text:
> >
> > 
> http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=United%20States
> >
> >
> >
> > To be clear though, the document does not specifically call out
> > breaking TLS, but it does clearly call out the need to detect
> > malicious inbound and outbound communications by leveraging an
> > "Electronic Access Point" (e.g. IDS/IPS) to enforce the Electronic
> > Security Perimeter.
> >> I'd also claim that your reference to PCI-DSS is misleading, as
> >> that same spec also explicitly calls for there to be good key
> >> management specifically including minimising the number of copies
> >> of keys, so at most, one might be able to claim that PCI-DSS is ok
> >> with people who break TLS in a nod-and-a-wink manner. But if you do
> >> have a real quote from PCI-DSS that calls for breaking TLS then
> >> please do also send that (it's been asked for a bunch of times
> >> without any answer being provided so far).
> >
> > I will need to look more closely for such a quote - if anybody else
> > knows of one, please chime in as well.
> >
> > Thanks
> >
> > -- Flemming
> >
> >
> >> Thanks, S.
> >>
> >>
> >> [1]
> >> 
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
> >
> >>
> >
> >
> >
> >
>
>
>
> ___
> TLS mailing 

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Watson Ladd]

On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar  wrote:
> FWIW: In my experience middleboxes don't ossify based on what the spec says,
> they ossify based on what they see on the wire. So, if common
> implementations send CCS in a particular way, that's what will get --- and,
> I'll argue, what has gotten --- ossified. I also agree with David and Eric
> that compatibility mode shouldn't be required because QUIC doesn't need it.

What does compatibility mode mean here? If we end up with having two
slightly different versions of TLS 1.3, one that looks more like TLS
1.2 and the other that does not, that doesn't seem like a good thing
to me.

My understanding is we already have ossification here and the debate
is what to do about it.


-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

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

Re: [TLS] network-based security solution use cases

[Nancy Cam-Winget (ncamwing)]

Hi Stephen,
Please see below:

On 11/7/17, 4:08 PM, "Stephen Farrell"  wrote:


Hiya,

On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote:
> Hi Stephen, Adding to Flemming’s comment,  finding “exact quotes”
> will be difficult 

I'm sorry but when making a claim that such and such a regulation
*requires* breaking TLS then you really do need to be that precise.
[NCW] In TLS 1.2, not sure why you state *requires* as there is the visibility 
afforded to 
at least allow for the identity disclosure to enable white or blacklist for 
example.  

> as their intent is really not to break things but
> rather want to ensure that inspection and oversight is available to
> affect guards/protections within an (enterprise/data center)
> infrastructure.   That said, PCI and other regulations will have a
> lot of documents that one has to go through….one that kind-of calls
> explicitly to the use of packet inspection, firewalling and such is
> in:
> 
> https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.pdf

The first mention of TLS there talks about protecting administrator
passwords via TLS. That totally argues against deployment of any kind
of MitM infrastructure.
[NCW] Agreed, they also state in ensuring that the newest TLS version where 
possible is used.  BUT, they also expect monitoring and troubleshooting.

> 
> It is an assessment questionnaire for vendors to evaluate their
> compliance, the requirements speak to securing the network and
> systems including firewalls, DMZs and the ability to do packet
> inspection.

Please point me at the specific text. Given you added PCI-DSS to
your document I would assume you did the work already. If not,
that's a bit odd.
[NCW] From the link above, you can look at requirements in 1.3,
also Requirement 10 details the need to monitor and provide audit trails
for network resources and cardholder data.

S.


> 
> Thanks, Nancy
> 
> On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)"
>  wrote:
> 
> Thanks for taking an initial look at the document Stephen - please
> see below for responses so far
> 
> On 11/7/17 4:13 AM, Stephen Farrell wrote:
>> Hiya,
>> 
>> On 07/11/17 02:48, Flemming Andreasen wrote:
>>> We didn't draw any particular line, but the use case scenarios
>>> that we tried to highlight are those related to overall security
>>> and regulatory requirements (including public sector)
>> I had a quick look at the draft (will try read properly en-route
>> to ietf-100) and I followed the reference to [1] but that only lead
>> to a forest of documents in which I didn't find any reference to
>> breaking TLS so far at least. Can you provide an explicit pointer
>> to the exact document on which that claim is based?
> For NERC, you can look under  "(CIP) Critital Infrastructure 
> Protection". CIP-005-5 for example covers the electronic security 
> perimeter, which has a couple of relevant requirements and associated
> text:
> 
> 
http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=United%20States
> 
> 
> 
> To be clear though, the document does not specifically call out
> breaking TLS, but it does clearly call out the need to detect
> malicious inbound and outbound communications by leveraging an
> "Electronic Access Point" (e.g. IDS/IPS) to enforce the Electronic
> Security Perimeter.
>> I'd also claim that your reference to PCI-DSS is misleading, as
>> that same spec also explicitly calls for there to be good key
>> management specifically including minimising the number of copies
>> of keys, so at most, one might be able to claim that PCI-DSS is ok
>> with people who break TLS in a nod-and-a-wink manner. But if you do
>> have a real quote from PCI-DSS that calls for breaking TLS then
>> please do also send that (it's been asked for a bunch of times
>> without any answer being provided so far).
> 
> I will need to look more closely for such a quote - if anybody else 
> knows of one, please chime in as well.
> 
> Thanks
> 
> -- Flemming
> 
> 
>> Thanks, S.
>> 
>> 
>> [1] 
>> 
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
>
>> 
> 
> 
> 
> 



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

Re: [TLS] network-based security solution use cases

[Stephen Farrell]

Hiya,

On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote:
> Hi Stephen, Adding to Flemming’s comment,  finding “exact quotes”
> will be difficult 

I'm sorry but when making a claim that such and such a regulation
*requires* breaking TLS then you really do need to be that precise.

> as their intent is really not to break things but
> rather want to ensure that inspection and oversight is available to
> affect guards/protections within an (enterprise/data center)
> infrastructure.   That said, PCI and other regulations will have a
> lot of documents that one has to go through….one that kind-of calls
> explicitly to the use of packet inspection, firewalling and such is
> in:
> 
> https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.pdf

The first mention of TLS there talks about protecting administrator
passwords via TLS. That totally argues against deployment of any kind
of MitM infrastructure.

> 
> It is an assessment questionnaire for vendors to evaluate their
> compliance, the requirements speak to securing the network and
> systems including firewalls, DMZs and the ability to do packet
> inspection.

Please point me at the specific text. Given you added PCI-DSS to
your document I would assume you did the work already. If not,
that's a bit odd.

S.


> 
> Thanks, Nancy
> 
> On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)"
>  wrote:
> 
> Thanks for taking an initial look at the document Stephen - please
> see below for responses so far
> 
> On 11/7/17 4:13 AM, Stephen Farrell wrote:
>> Hiya,
>> 
>> On 07/11/17 02:48, Flemming Andreasen wrote:
>>> We didn't draw any particular line, but the use case scenarios
>>> that we tried to highlight are those related to overall security
>>> and regulatory requirements (including public sector)
>> I had a quick look at the draft (will try read properly en-route
>> to ietf-100) and I followed the reference to [1] but that only lead
>> to a forest of documents in which I didn't find any reference to
>> breaking TLS so far at least. Can you provide an explicit pointer
>> to the exact document on which that claim is based?
> For NERC, you can look under  "(CIP) Critital Infrastructure 
> Protection". CIP-005-5 for example covers the electronic security 
> perimeter, which has a couple of relevant requirements and associated
> text:
> 
> http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=United%20States
> 
> 
> 
> To be clear though, the document does not specifically call out
> breaking TLS, but it does clearly call out the need to detect
> malicious inbound and outbound communications by leveraging an
> "Electronic Access Point" (e.g. IDS/IPS) to enforce the Electronic
> Security Perimeter.
>> I'd also claim that your reference to PCI-DSS is misleading, as
>> that same spec also explicitly calls for there to be good key
>> management specifically including minimising the number of copies
>> of keys, so at most, one might be able to claim that PCI-DSS is ok
>> with people who break TLS in a nod-and-a-wink manner. But if you do
>> have a real quote from PCI-DSS that calls for breaking TLS then
>> please do also send that (it's been asked for a bunch of times
>> without any answer being provided so far).
> 
> I will need to look more closely for such a quote - if anybody else 
> knows of one, please chime in as well.
> 
> Thanks
> 
> -- Flemming
> 
> 
>> Thanks, S.
>> 
>> 
>> [1] 
>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
>
>> 
> 
> 
> 
> 



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

Re: [TLS] network-based security solution use cases

[Stephen Farrell]

Hiya,

On 07/11/17 23:27, Flemming Andreasen wrote:
> Thanks for taking an initial look at the document Stephen - please see
> below for responses so far
> 
> On 11/7/17 4:13 AM, Stephen Farrell wrote:
>> Hiya,
>>
>> On 07/11/17 02:48, Flemming Andreasen wrote:
>>> We didn't draw any particular line, but the use case scenarios that we
>>> tried to highlight are those related to overall security and regulatory
>>> requirements (including public sector)
>> I had a quick look at the draft (will try read properly en-route to
>> ietf-100) and I followed the reference to [1] but that only lead to a
>> forest of documents in which I didn't find any reference to breaking
>> TLS so far at least. Can you provide an explicit pointer to the
>> exact document on which that claim is based?
> For NERC, you can look under  "(CIP) Critital Infrastructure
> Protection". CIP-005-5 for example covers the electronic security
> perimeter, which has a couple of relevant requirements and associated text:
> 
> http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=United%20States
> 

Thanks for that.

So I didn't see any mention of TLS in that document at all.

> 
> To be clear though, the document does not specifically call out breaking
> TLS, but it does clearly call out the need to detect malicious inbound

For inbound (on page 9) I see it mentions IDSes and application
layer firewalls as examples yes. Given that the latter would not
require any messing with TLS at all, this seems to be a very
clear example of a regulation not requiring breaking TLS. That'd
mean there is no regulatory requirement at all wouldn't it?

But again, if there are real regulatory requirements there that
really do call for MitM attacks on TLS I'd be glad to look at them
if you want to quote them.

> and outbound communications by leveraging an "Electronic Access Point"
> (e.g. IDS/IPS) to enforce the Electronic Security Perimeter.

Personally, I have to say I find the outbound stuff nonsense.
I know people make money selling product and services for that.

>> I'd also claim that your reference to PCI-DSS is misleading, as that
>> same spec also explicitly calls for there to be good key management
>> specifically including minimising the number of copies of keys, so
>> at most, one might be able to claim that PCI-DSS is ok with people
>> who break TLS in a nod-and-a-wink manner. But if you do have a real
>> quote from PCI-DSS that calls for breaking TLS then please do also
>> send that (it's been asked for a bunch of times without any answer
>> being provided so far).
> 
> I will need to look more closely for such a quote - if anybody else
> knows of one, please chime in as well.

It's been asked for a number of times without any substantive
response. I would assume that one of the authors of this would
be able to point at the text that caused you to add in a mention
of PCI-DSS. If not, that seems odd.

I actually looked through the PCI spec myself and found that it
is fairly explicitly asking for good crypto and not bad crypto.
(E.g. as mentioned, saying to minimise the number of copies of
keys that are anywhere.)

Maybe the ADs ought liaise to some of those organisations and
ask them if they do or do not recognise the claims related to
breaking TLS being attributed to them?

Or even better, maybe just not making those claims would be
easier all around and more accurate.

S.

> 
> Thanks
> 
> -- Flemming
> 
> 
>> Thanks,
>> S.
>>
>>
>> [1]
>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
>>
>>
> 
> 



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

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Eric Rescorla]

On Tue, Nov 7, 2017 at 3:41 PM, Salz, Rich  wrote:

> ➢ Given that we're almost there, and that only really browsers are
> asking for these hacks, and that even some of those were almost ready
> to ship without these hacks, I don't think that this is entirely
> unrealistic as an aspiration.
>
> The Internet is more than just a couple of browser executables.
>
> Does nobody think of the servers?
>

I do, but I don't really see how they're relevant for this question. Don't
the servers control the middleboxes they are behind?

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

Re: [TLS] network-based security solution use cases

[Nancy Cam-Winget (ncamwing)]

Hi Stephen,
Adding to Flemming’s comment,  finding “exact quotes” will be difficult as 
their intent is really not to break things but rather want to ensure that 
inspection and oversight is available to affect guards/protections within an 
(enterprise/data center) infrastructure.   That said, PCI and other regulations 
will have a lot of documents that one has to go through….one that kind-of calls 
explicitly to the use of packet inspection, firewalling and such is in:

https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.pdf

It is an assessment questionnaire for vendors to evaluate their compliance, the 
requirements speak to securing the network and systems including firewalls, 
DMZs and the ability to do packet inspection.

Thanks, Nancy 

On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)"  wrote:

Thanks for taking an initial look at the document Stephen - please see 
below for responses so far

On 11/7/17 4:13 AM, Stephen Farrell wrote:
> Hiya,
>
> On 07/11/17 02:48, Flemming Andreasen wrote:
>> We didn't draw any particular line, but the use case scenarios that we
>> tried to highlight are those related to overall security and regulatory
>> requirements (including public sector)
> I had a quick look at the draft (will try read properly en-route to
> ietf-100) and I followed the reference to [1] but that only lead to a
> forest of documents in which I didn't find any reference to breaking
> TLS so far at least. Can you provide an explicit pointer to the
> exact document on which that claim is based?
For NERC, you can look under  "(CIP) Critital Infrastructure 
Protection". CIP-005-5 for example covers the electronic security 
perimeter, which has a couple of relevant requirements and associated text:


http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=United%20States
 


To be clear though, the document does not specifically call out breaking 
TLS, but it does clearly call out the need to detect malicious inbound 
and outbound communications by leveraging an "Electronic Access Point" 
(e.g. IDS/IPS) to enforce the Electronic Security Perimeter.
> I'd also claim that your reference to PCI-DSS is misleading, as that
> same spec also explicitly calls for there to be good key management
> specifically including minimising the number of copies of keys, so
> at most, one might be able to claim that PCI-DSS is ok with people
> who break TLS in a nod-and-a-wink manner. But if you do have a real
> quote from PCI-DSS that calls for breaking TLS then please do also
> send that (it's been asked for a bunch of times without any answer
> being provided so far).

I will need to look more closely for such a quote - if anybody else 
knows of one, please chime in as well.

Thanks

-- Flemming


> Thanks,
> S.
>
>
> [1]
> 
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
>



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

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Salz, Rich]

➢ Given that we're almost there, and that only really browsers are
asking for these hacks, and that even some of those were almost ready
to ship without these hacks, I don't think that this is entirely
unrealistic as an aspiration.

The Internet is more than just a couple of browser executables.

Does nobody think of the servers?

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

Re: [TLS] network-based security solution use cases

[Flemming Andreasen]

Thanks for taking an initial look at the document Stephen - please see 
below for responses so far


On 11/7/17 4:13 AM, Stephen Farrell wrote:

Hiya,

On 07/11/17 02:48, Flemming Andreasen wrote:

We didn't draw any particular line, but the use case scenarios that we
tried to highlight are those related to overall security and regulatory
requirements (including public sector)

I had a quick look at the draft (will try read properly en-route to
ietf-100) and I followed the reference to [1] but that only lead to a
forest of documents in which I didn't find any reference to breaking
TLS so far at least. Can you provide an explicit pointer to the
exact document on which that claim is based?
For NERC, you can look under  "(CIP) Critital Infrastructure 
Protection". CIP-005-5 for example covers the electronic security 
perimeter, which has a couple of relevant requirements and associated text:


http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=United%20States 



To be clear though, the document does not specifically call out breaking 
TLS, but it does clearly call out the need to detect malicious inbound 
and outbound communications by leveraging an "Electronic Access Point" 
(e.g. IDS/IPS) to enforce the Electronic Security Perimeter.

I'd also claim that your reference to PCI-DSS is misleading, as that
same spec also explicitly calls for there to be good key management
specifically including minimising the number of copies of keys, so
at most, one might be able to claim that PCI-DSS is ok with people
who break TLS in a nod-and-a-wink manner. But if you do have a real
quote from PCI-DSS that calls for breaking TLS then please do also
send that (it's been asked for a bunch of times without any answer
being provided so far).


I will need to look more closely for such a quote - if anybody else 
knows of one, please chime in as well.


Thanks

-- Flemming



Thanks,
S.


[1]
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP



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

Re: [TLS] network-based security solution use cases

[Flemming Andreasen]

On 11/7/17 12:23 PM, Eric Rescorla wrote:



On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen > wrote:


Thank you for the feedback Ekr - please see below for responses


On 11/6/17 12:43 PM, Eric Rescorla wrote:

I took a look at this.

Without getting into the question of whether the types of middleboxes
you describe here provide a security benefit, there are several
points
in the document that are either wrong or at least
misleading/confusing.

- Key Synchronization
This document notes that in TLS 1.2, it is possible for a middlebox
that traffic keys match on both sides of the connection it is
proxying,
but in TLS 1.3 it is not:

   There are several techniques that can be utilized.  Those
techniques
   function with TLS 1.2 and earlier versions but not with TLS 1.3.

   One technique is for the middlebox to negotiate the same master
   secret with the original TLS client and server, as if the two
   endpoints handshake directly.  This is also known as "Triple
   Handshake" used by legitimate middleboxes.  [BreakTLS]
describes the
   methods with RSA and DH key exchanges. When the proxy session keys
   are the same as for a direct handshake, the middlebox is able to
   "cut-through" the two TLS proxy sessions when it finishes the
   security inspection.

   This technique is not functional with TLS 1.3 since the transcript
   hash over the handshake messages is part of the key derivation
   procedure.

First, I would note that this property of TLS 1.2 is bad, as it leads
to Unknown Key Share (UKS) attacks, which can be the basis of real
attacks on TLS 1.2 as fielded. It is for this reason that the TLS
WG published RFC 7627.


Thanks for the bringing that one up - we will make sure to include
that in the next version.

Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3,
it's an integral part of the protocol that cannot be disabled. The
TLS 1.2 extension does not share that property.


It seems like an odd complaint that we are making protection against 
Unknown Key Shares an integral part of the protocol


I understand your point. What I am saying is that there are some side 
effects of doing so that impacts use case scenarios that exist today. If 
you cannot drop out, then you have two choices:
1) Always be a MITM, which you may not want to (e.g. consider sessions 
with financial institutions)
2) Never be a MITM, which means you cannot do any of the network-based 
security use cases we have highlighted


What you really want is the ability to do it more selectively.



Finally, you note several times in the document (e.g., S 4.5), that
with key synchronization, the middlebox can perform the handshake and
then disengage from the connection. However, the cases you mention
(e.g.., detecting exploit attempts) ultimately require examining
all traffic in the connection.


We have several different use case scenarios in there, and I agree
with the observation that they cannot all be satisfied at the same
time. For example, we cannot scan for malware in an encrypted
stream to a financial institution that we are not allowed to
decrypt. That doesn't mean either use case is invalid. Customers
do both in real-life (just not at the same time).


I'm finding it a bit puzzling what you claim customers do. 
Specifically, you seem to be saying that customers examine the 
beginning of the connection and then stop. What are they scanning for 
and what makes them stop?


It's the handshake process, which typically governs the associated 
policy for the session (e.g. decrypt-and-inspect or do-not-decrypt). You 
will try to determine whether the session should undergo inspection at 
the time the ClientHello passes through the box, however sometimes, you 
end up making a final (and different) decision when the ServerHello is 
received. The decision is guided by policies configured for the 
middlebox which may determine it based on various criteria (e.g. 
category of the destination such as "Financial Services", geography, etc.)



- PSK and resumption
You write:

   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 

Re: [TLS] TLS Extensions: Omitting Handshake Messages

[Illya Gerasymchuk]

Okay, thank you very much, this clears it all up!

Can I make a suggestion of making the section that describes the extension
mechanism to mention that extensions can, in fact, choose to omit messages
not marked as situation-depended/optional? Maybe this is already covered by
the "it would be technically possible to use extensions to change major aspects
of the design of TLS" part, but neither reading RFC 5246, nor the TLS 1.3
draft, nor the RFC 4366 (and other related ones), makes it clear, in my
opinion. I'm talking from a perspective of someone who studied  SSL 3.0,
TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3 and related RFCs in detail in the last
2-3 months, but only knew the basics before (not basics cryptography and
other constructs that TLS uses, only the basics of the TLS protocol
itself). I've asked the same question I posted here to some friends and on
the internet and everyone said that, from what they understood from the
spec, *extensions could not remove *messages marked as non-optional. Having
such information presented explicitly would be of great help to anyone who
is working on changes/extensions to/for TLS.

Thank you,

- Illya

On Tue, Nov 7, 2017 at 10:46 PM, Eric Rescorla  wrote:

> On Tue, Nov 7, 2017 at 2:40 PM, Illya Gerasymchuk 
> wrote:
>
>> Thank you very much for your answer. So just to be clear, hypothetically,
>> it would be possible to define an extension for TLS 1.2 that *converts
>> it to TLS 1.3 completely*, correct?
>>
>
> Well, this is effectively the syntax that TLS 1.3 with PR 1091 uses,
> except that it's called "supported_versions".
>
>
>
>> For example, would it be possible, to have an extension called 
>> *TLS_1.2_TO_TLS_1.3
>> *that would define the full handshake to be the following, *and still be
>> TLS 1.2 compliant?* (I just copied the full hadshake from the TLS 1.3
>> draft and added the text in bold):
>>
>
> This seems like a philosophical question.
>
>
>
>
>> To give you a little more background for my motivation behind this, the
>> topic for my master thesis is "TLS For IOT", the goal of which is to define
>> a new version of TLS protocol, which would be usable on low-power,
>> low-energy devices, *while remaining backwards compatible with regular
>> TLS.*
>>
>
> Well, backward compatible here typically would mean "you can send a
> ClientHello to the server and it won't choke", and this would be true for
> both your proposal and TLS 1.3. Any other questions about compliance kind
> of seem like standards lawyering.
>
> -Ekr
>
>
>
>
> But would that still be considered *TLS Extension Compliant*? (if I can
>> remove some of the messages not marked as optional in the spec, such as
>> *ServerHelloDone*, then the answer would be yes). The answer to this
>> question conditions whether I would need to define 2 separate protocols:
>> one for TLS 1.2, one for TLS 1.3 or if I potentially can just define the
>> same protocol that could be used by clients and servers supporting both:
>> TLS 1.2 and TLS 1.3, by the means of an extension. My main goals would be
>> to limit the number of messages sent, the amount of transmitted data, as
>> well as use lighter algorithms. Quite a few of the ideas I had initially
>> are already implemented in TLS 1.3, so I wanted to migrate a lot of those
>> to clients and servers that only support TLS 1.2. I've been reading a lot
>> of RFC's and papers about the work done on this topic, but I haven't found
>> any of them that does such a thing specifically (removing any of the
>> messages not marked as optional).
>>
>> I'm well aware that I need to be extremely careful when removing messages
>> or making any significant changes to the protocol.
>>
>
>
>
>>
>> Thank you,
>>
>> - Illya
>>
>> On Tue, Nov 7, 2017 at 5:56 PM, Eric Rescorla  wrote:
>>
>>>
>>>
>>> On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk >> > wrote:
>>>
 Greetings,

 I've been reading though various RFCs and couldn't find a definite
 answer to my question: can a negotiated TLS extension skip some of the TLS
 Handshake messages and still be compliant with the TLS specification? My
 goal is to develop a new version of TLS (as part of my Master Thesis work),
 while preferably, staying backwards-compatible.

 Here, I will be specifically talking about TLS 1.2, defined in RFC
 5246. Below is a message flow for the full handshake (taken directly from
 RFC 5246):

   Client  Server
   --  --

   ClientHello  >
 ServerHello
 Certificate*

 ServerKeyExchange*

 CertificateRequest*
   <  ServerHelloDone
   Certificate*
   ClientKeyExchange
   

Re: [TLS] TLS Extensions: Omitting Handshake Messages

[Martin Thomson]

Hi Illya,

You are actually describing TLS 1.3, especially with recent (proposed)
changes.  It uses an extension to negotiate version, looking like TLS
1.2 otherwise.  It has the ability to use lighter-weight algorithms,
etc...

On Wed, Nov 8, 2017 at 9:40 AM, Illya Gerasymchuk  wrote:
> Thank you very much for your answer. So just to be clear, hypothetically, it
> would be possible to define an extension for TLS 1.2 that converts it to TLS
> 1.3 completely, correct? For example, would it be possible, to have an
> extension called TLS_1.2_TO_TLS_1.3 that would define the full handshake to
> be the following, and still be TLS 1.2 compliant? (I just copied the full
> hadshake from the TLS 1.3 draft and added the text in bold):
>
> Client   Server
>
> ClientHello
> + TLS_1.2_TO_TLS_1.3
> + key_share >
> < HelloRetryRequest
> +
> TLS_1.2_TO_TLS_1.3
> + key_share
>
> ClientHello
> + key_share >
> ServerHello
> + key_share
>   {EncryptedExtensions}
>   {CertificateRequest*}
>  {Certificate*}
>{CertificateVerify*}
>  {Finished}
> <   [Application Data*]
> {Certificate*}
> {CertificateVerify*}
> {Finished}  >
>
>[Application Data]
> <-->   [Application Data]
>
> To give you a little more background for my motivation behind this, the
> topic for my master thesis is "TLS For IOT", the goal of which is to define
> a new version of TLS protocol, which would be usable on low-power,
> low-energy devices, while remaining backwards compatible with regular TLS.
> My idea is to define this new protocol through various extensions (even
> though I had't had a chance to discuss this with my supervisors, since they
> seem to be away). Considering the extension above, I know that I could
> easily define a new protocol that would do something like:
>
>> if TLS_1.2_TO_TLS_1.3 extension present in ClientHello:
>> use my custom protocol (with new messages and some omitted)
>> else:
>> use regular TLS 1.2
>
>
> But would that still be considered TLS Extension Compliant? (if I can remove
> some of the messages not marked as optional in the spec, such as
> ServerHelloDone, then the answer would be yes). The answer to this question
> conditions whether I would need to define 2 separate protocols: one for TLS
> 1.2, one for TLS 1.3 or if I potentially can just define the same protocol
> that could be used by clients and servers supporting both: TLS 1.2 and TLS
> 1.3, by the means of an extension. My main goals would be to limit the
> number of messages sent, the amount of transmitted data, as well as use
> lighter algorithms. Quite a few of the ideas I had initially are already
> implemented in TLS 1.3, so I wanted to migrate a lot of those to clients and
> servers that only support TLS 1.2. I've been reading a lot of RFC's and
> papers about the work done on this topic, but I haven't found any of them
> that does such a thing specifically (removing any of the messages not marked
> as optional).
>
> I'm well aware that I need to be extremely careful when removing messages or
> making any significant changes to the protocol.
>
> Thank you,
>
> - Illya
>
> On Tue, Nov 7, 2017 at 5:56 PM, Eric Rescorla  wrote:
>>
>>
>>
>> On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk 
>> wrote:
>>>
>>> Greetings,
>>>
>>> I've been reading though various RFCs and couldn't find a definite answer
>>> to my question: can a negotiated TLS extension skip some of the TLS
>>> Handshake messages and still be compliant with the TLS specification? My
>>> goal is to develop a new version of TLS (as part of my Master Thesis work),
>>> while preferably, staying backwards-compatible.
>>>
>>> Here, I will be specifically talking about TLS 1.2, defined in RFC 5246.
>>> Below is a message flow for the full handshake (taken directly from RFC
>>> 5246):
>>>
>>>   Client  Server
>>>   --  --
>>>
>>>   ClientHello  >
>>> ServerHello
>>>

Re: [TLS] TLS Extensions: Omitting Handshake Messages

[Eric Rescorla]

On Tue, Nov 7, 2017 at 2:40 PM, Illya Gerasymchuk 
wrote:

> Thank you very much for your answer. So just to be clear, hypothetically,
> it would be possible to define an extension for TLS 1.2 that *converts
> it to TLS 1.3 completely*, correct?
>

Well, this is effectively the syntax that TLS 1.3 with PR 1091 uses, except
that it's called "supported_versions".



> For example, would it be possible, to have an extension called 
> *TLS_1.2_TO_TLS_1.3
> *that would define the full handshake to be the following, *and still be
> TLS 1.2 compliant?* (I just copied the full hadshake from the TLS 1.3
> draft and added the text in bold):
>

This seems like a philosophical question.




> To give you a little more background for my motivation behind this, the
> topic for my master thesis is "TLS For IOT", the goal of which is to define
> a new version of TLS protocol, which would be usable on low-power,
> low-energy devices, *while remaining backwards compatible with regular
> TLS.*
>

Well, backward compatible here typically would mean "you can send a
ClientHello to the server and it won't choke", and this would be true for
both your proposal and TLS 1.3. Any other questions about compliance kind
of seem like standards lawyering.

-Ekr




But would that still be considered *TLS Extension Compliant*? (if I can
> remove some of the messages not marked as optional in the spec, such as
> *ServerHelloDone*, then the answer would be yes). The answer to this
> question conditions whether I would need to define 2 separate protocols:
> one for TLS 1.2, one for TLS 1.3 or if I potentially can just define the
> same protocol that could be used by clients and servers supporting both:
> TLS 1.2 and TLS 1.3, by the means of an extension. My main goals would be
> to limit the number of messages sent, the amount of transmitted data, as
> well as use lighter algorithms. Quite a few of the ideas I had initially
> are already implemented in TLS 1.3, so I wanted to migrate a lot of those
> to clients and servers that only support TLS 1.2. I've been reading a lot
> of RFC's and papers about the work done on this topic, but I haven't found
> any of them that does such a thing specifically (removing any of the
> messages not marked as optional).
>
> I'm well aware that I need to be extremely careful when removing messages
> or making any significant changes to the protocol.
>



>
> Thank you,
>
> - Illya
>
> On Tue, Nov 7, 2017 at 5:56 PM, Eric Rescorla  wrote:
>
>>
>>
>> On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk 
>> wrote:
>>
>>> Greetings,
>>>
>>> I've been reading though various RFCs and couldn't find a definite
>>> answer to my question: can a negotiated TLS extension skip some of the TLS
>>> Handshake messages and still be compliant with the TLS specification? My
>>> goal is to develop a new version of TLS (as part of my Master Thesis work),
>>> while preferably, staying backwards-compatible.
>>>
>>> Here, I will be specifically talking about TLS 1.2, defined in RFC 5246.
>>> Below is a message flow for the full handshake (taken directly from RFC
>>> 5246):
>>>
>>>   Client  Server
>>>   --  --
>>>
>>>   ClientHello  >
>>> ServerHello
>>> Certificate*
>>>
>>> ServerKeyExchange*
>>>
>>> CertificateRequest*
>>>   <  ServerHelloDone
>>>   Certificate*
>>>   ClientKeyExchange
>>>   CertificateVerify*
>>>   [ChangeCipherSpec]
>>>   Finished   >
>>>
>>> [ChangeCipherSpec]
>>>   >>   Application Data  <--->   Application Data
>>>
>>>
>>> * (asterisk) Indicates optional or situation-dependent messages that are
>>> not always sent.
>>> Now, I do know that it's perfect legal for a TLS extension to modify the
>>> structure of some message or add a new message, but I'm not sure if one of
>>> the messages, not defined as optional/situation-dependent can be omitted.
>>>
>>> Let me give you a concrete example. Let's say I create a new extension
>>> called *XYZ*. The client and the server negotiate that extension in the
>>> their extended hello messages. Would it be legal for the *XYZ*
>>> extension to mandate the server not to send the *ServerHelloDone*
>>> message? As far as I understood, this is not legal.
>>>
>>
>> You certainly can use extensions to indicate that a new message is to be
>> sent, so I don't think it would be necessarily be prohibited to have it
>> remove a message, though I can't offhand think of an example of where we do
>> so.
>>
>>
>> RFC 5245 Section 4.4.1.4 states that:
>>>
>>> "it would be technically possible to use extensions to change major aspects
>>> of the design of TLS; 

Re: [TLS] TLS Extensions: Omitting Handshake Messages

[Illya Gerasymchuk]

Thank you very much for your answer. So just to be clear, hypothetically,
it would be possible to define an extension for TLS 1.2 that *converts
it to TLS 1.3 completely*, correct? For example, would it be possible, to
have an extension called *TLS_1.2_TO_TLS_1.3 *that would define the full
handshake to be the following, *and still be TLS 1.2 compliant?* (I just
copied the full hadshake from the TLS 1.3 draft and added the text in bold):

*Client*   *Server*

ClientHello*+ TLS_1.2_TO_TLS_1.3*
+ key_share >
< HelloRetryRequest
*+
TLS_1.2_TO_TLS_1.3*
+ key_share

ClientHello
+ key_share >
ServerHello
+ key_share
  {EncryptedExtensions}
  {CertificateRequest*}
 {Certificate*}
   {CertificateVerify*}
 {Finished}
<   [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished}  >

   [Application Data]
<-->   [Application Data]

To give you a little more background for my motivation behind this, the
topic for my master thesis is "TLS For IOT", the goal of which is to define
a new version of TLS protocol, which would be usable on low-power,
low-energy devices, *while remaining backwards compatible with regular TLS.
*My idea is to define this new protocol through various extensions (even
though I had't had a chance to discuss this with my supervisors, since they
seem to be away). Considering the extension above, I know that I could
easily define a new protocol that would do something like:


>
>
> *if TLS_1.2_TO_TLS_1.3 extension present in ClientHello:use my custom
> protocol (with new messages and some omitted)else:use regular TLS 1.2*


But would that still be considered *TLS Extension Compliant*? (if I can
remove some of the messages not marked as optional in the spec, such as
*ServerHelloDone*, then the answer would be yes). The answer to this
question conditions whether I would need to define 2 separate protocols:
one for TLS 1.2, one for TLS 1.3 or if I potentially can just define the
same protocol that could be used by clients and servers supporting both:
TLS 1.2 and TLS 1.3, by the means of an extension. My main goals would be
to limit the number of messages sent, the amount of transmitted data, as
well as use lighter algorithms. Quite a few of the ideas I had initially
are already implemented in TLS 1.3, so I wanted to migrate a lot of those
to clients and servers that only support TLS 1.2. I've been reading a lot
of RFC's and papers about the work done on this topic, but I haven't found
any of them that does such a thing specifically (removing any of the
messages not marked as optional).

I'm well aware that I need to be extremely careful when removing messages
or making any significant changes to the protocol.

Thank you,

- Illya

On Tue, Nov 7, 2017 at 5:56 PM, Eric Rescorla  wrote:

>
>
> On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk 
> wrote:
>
>> Greetings,
>>
>> I've been reading though various RFCs and couldn't find a definite answer
>> to my question: can a negotiated TLS extension skip some of the TLS
>> Handshake messages and still be compliant with the TLS specification? My
>> goal is to develop a new version of TLS (as part of my Master Thesis work),
>> while preferably, staying backwards-compatible.
>>
>> Here, I will be specifically talking about TLS 1.2, defined in RFC 5246.
>> Below is a message flow for the full handshake (taken directly from RFC
>> 5246):
>>
>>   Client  Server
>>   --  --
>>
>>   ClientHello  >
>> ServerHello
>> Certificate*
>> ServerKeyExchange*
>>
>> CertificateRequest*
>>   <  ServerHelloDone
>>   Certificate*
>>   ClientKeyExchange
>>   CertificateVerify*
>>   [ChangeCipherSpec]
>>   Finished   >
>>
>> [ChangeCipherSpec]
>>   >   

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Martin Thomson]

On Wed, Nov 8, 2017 at 7:23 AM, Salz, Rich  wrote:
> “We can remove it when middleboxes aren’t a problem.”  Talk about 
> aspirational (

Given that we're almost there, and that only really browsers are
asking for these hacks, and that even some of those were almost ready
to ship without these hacks, I don't think that this is entirely
unrealistic as an aspiration.

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

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

[Alex C]

If the embedded device is capable of running TLS anyway (e.g. fast enough
to do RSA) why not have the phone act as a dumb proxy?

However I see the draft has some additional scenarios where it makes sense,
such as where the device must work with an off-the-shelf proxy that only
speaks HTTP.

On Wed, Nov 8, 2017 at 4:15 AM, Hannes Tschofenig  wrote:

> FWIW: I can tell you what the threat model was with the layered TLS work.
>
> Let me give you a very specific example. Imagine a Bluetooth Low Energy
> device that communicates via a phone to a cloud-based service. The
> communication from the phone to the cloud uses HTTPS. The communication
> from the BLE device to the phone uses ordinary BLE
> services/characteristics.
>
> The Layered TLS/application layer TLS would in this case run from the
> BLE device all the way to the cloud-based service at the application layer.
>
> This allows us to provide end-to-end security across a proxy (in this
> case the phone) and independent of the underlying protocols.
>
> Does this make sense?
>
> Ciao
> Hannes
>
>
> On 11/07/2017 10:21 AM, Alex C wrote:
> > What exactly is the threat model here?
> >
> > Are you trying to hide a connection from a reverse proxy at the server
> > end? If so, the server operator should not have deployed a reverse proxy
> > in the first place.
> >
> > Are you trying to hide from a MITM proxy that supplies its own
> > certificate? If so, then what prevents the proxy from doing the same to
> > the tunnelled session?
> > When MITM proxies learn to do that, will we create another tunnelling
> > protocol inside this one?
> >
> > This is a cat-and-mouse game with middleboxes (much like the version
> > negotiation problem, but in a different way). Keep playing and everyone
> > loses.
> >
> > On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes  > > wrote:
> >
> > Hey TLS folks,
> >
> > Owen, Max, and I have been kicking around some ideas for how to make
> > secure connections in environments where HTTPS is subject to MitM /
> > proxying.
> >
> > The below draft lays out a way to tunnel TLS over HTTPS, in hopes of
> > creating a channel you could use when you really need things to be
> > private, even from the local MitM.
> >
> > Feedback obviously very welcome.  Interested in whether folks think
> > this is a useful area in which to develop an RFC, and any thoughts
> > on how to do this better.
> >
> > Thanks,
> > --Richard
> >
> >
> > On Mon, Oct 30, 2017 at 3:47 PM,  > > wrote:
> >
> >
> > A new version of I-D, draft-friel-tls-over-http-00.txt
> > has been successfully submitted by Owen Friel and posted to the
> > IETF repository.
> >
> > Name:   draft-friel-tls-over-http
> > Revision:   00
> > Title:  Application-Layer TLS
> > Document date:  2017-10-30
> > Group:  Individual Submission
> > Pages:  20
> > URL:
> > https://www.ietf.org/internet-drafts/draft-friel-tls-over-
> http-00.txt
> >  tls-over-http-00.txt>
> > Status:
> >  https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
> > 
> > Htmlized:
> >  https://tools.ietf.org/html/draft-friel-tls-over-http-00
> > 
> > Htmlized:
> >  https://datatracker.ietf.org/doc/html/draft-friel-tls-over-
> http-00
> >  http-00>
> >
> >
> > Abstract:
> >Many clients need to establish secure connections to
> application
> >services but face challenges establishing these connections
> > due to
> >the presence of middleboxes that terminate TLS connections
> > from the
> >client and restablish new TLS connections to the service.
> This
> >document defines a mechanism for transporting TLS records in
> HTTP
> >message bodies between clients and services.  This enables
> > clients
> >and services to establish secure connections using TLS at the
> >application layer, and treat any middleboxes that are
> > intercepting
> >traffic at the network layer as untrusted transport.  In
> > short, this
> >mechanism moves the TLS handshake up the OSI stack to the
> > application
> >layer.
> >
> >
> >
> >
> > 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 

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Salz, Rich]

I think Hubert makes excellent points.

“We can remove it when middleboxes aren’t a problem.”  Talk about aspirational (

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

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Eric Rescorla]

On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario  wrote:

> On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote:
> > On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario  wrote:
> > > In general +1, I like to see TLS 1.3 deployed ASAP and making the
> spurious
> > > failures as rare as possible is a good way to make that happen.
> > >
> > > that being said, I have few comments:
> > >
> > > On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote:
> > > > https://github.com/tlswg/tls13-spec/pull/1091
> > > >
> > > > As I mentioned a while back, we've been seeing evidence of middlebox
> > > > intolerance. I just posted PR 1091, which is based on a bunch of work
> > > > by the BoringSSL team and an original suggestion by Kyle Nekritz that
> > > > should significantly decrease the rate of these errors.
> > > >
> > > > The general idea here is to make TLS 1.3 look more like TLS 1.2
> > > > resumption. The major changes are:
> > > >
> > > > - Move version negotiation entirely into "supported_versions", and
> hence
> > > >
> > > >   ServerHello.version == 0x0303 (TLS 1.2)
> > > >
> > > > - Restore the missing session_id and compression fields in
> ServerHello
> > >
> > > less special cases in parser code - big +1
> > >
> > > > - The client sends a fake session_id and the server echoes it
> > > > - The server sends ChangeCipherSpec messages after
> > > > ServerHello/HelloRetryRequest
> > > >
> > > >   (so that the middlebox ignores any "encrypted" data afterwards),
> > > >   and the client sends ChangeCipherSpec after ClientHello. Either
> > > >   side has to ignore ChangeCipherSpec during the handshake.
> > >
> > > That's the part I have a bit of a problem with.
> > > If the CCS is necessary to make middleboxes work, and given that
> > > lack-of-CCS-
> > > intolerance is not something that we can detect reliably (not in a way
> > > that
> > > can be simulated by an attacker), I think the CCS should be baked in
> the
> > > TLS
> > > 1.3 as deep as it was baked into TLS 1.2.
> >
> > You don't detect it on an individualized basis. Rather, you measure
> whether
> > it's
> > necessary and if/when the necessary level of CCS becomes low enough, you
> > just stop sending it ever.
> >
> > > That is, the standard should make it a mandatory message to send, fully
> > > parsed
> > > and validated, requiring aborting connection if it is received at any
> > > unexpected moment, in duplicate, omitted or malformed. Not only as
> part of
> > > the
> > > "compatibility mode".
> >
> > Yeah, I'm not enthusiastic about this. It's more stuff in the state
> machine
> > that
> > we hope to eventually eliminate. And as David says, it's totally
> unnecessary
> > for QUIC and DTLS
> >
> > -Ekr
>
> what I was getting at is that if you want to be compatible with
> middleboxes,
> you send that CCS always, as you never know what thing will be between you
> and
> the peer
>
> that means that all the large implementations will be sending them always
>
> that means that new middleboxes will likely end up expecting it either way
> and
> existing ones won't have much incentive to update/fix
>
> secondly, if we allow for sending CCS at any point, we will end up with the
> same bug as the Alert processing DoS there was in some implementations —
> one
> that allowed the peer to send unlimited amount of warning alerts


Given that this is (a) not encrypted (b) just discarded and (c) only
allowed during the handshake, this
doesn't seem like much of a DoS.


so even if we mark it as optional, I still think we should allow for it to
> be
> sent at only very specific moments and only once per side
>

I might be fine if it were required in this way, but not fine if it was
required that one enforce it.

-Ekr

>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Hubert Kario]

On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote:
> On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario  wrote:
> > In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious
> > failures as rare as possible is a good way to make that happen.
> > 
> > that being said, I have few comments:
> > 
> > On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote:
> > > https://github.com/tlswg/tls13-spec/pull/1091
> > > 
> > > As I mentioned a while back, we've been seeing evidence of middlebox
> > > intolerance. I just posted PR 1091, which is based on a bunch of work
> > > by the BoringSSL team and an original suggestion by Kyle Nekritz that
> > > should significantly decrease the rate of these errors.
> > > 
> > > The general idea here is to make TLS 1.3 look more like TLS 1.2
> > > resumption. The major changes are:
> > > 
> > > - Move version negotiation entirely into "supported_versions", and hence
> > > 
> > >   ServerHello.version == 0x0303 (TLS 1.2)
> > > 
> > > - Restore the missing session_id and compression fields in ServerHello
> > 
> > less special cases in parser code - big +1
> > 
> > > - The client sends a fake session_id and the server echoes it
> > > - The server sends ChangeCipherSpec messages after
> > > ServerHello/HelloRetryRequest
> > > 
> > >   (so that the middlebox ignores any "encrypted" data afterwards),
> > >   and the client sends ChangeCipherSpec after ClientHello. Either
> > >   side has to ignore ChangeCipherSpec during the handshake.
> > 
> > That's the part I have a bit of a problem with.
> > If the CCS is necessary to make middleboxes work, and given that
> > lack-of-CCS-
> > intolerance is not something that we can detect reliably (not in a way
> > that
> > can be simulated by an attacker), I think the CCS should be baked in the
> > TLS
> > 1.3 as deep as it was baked into TLS 1.2.
> 
> You don't detect it on an individualized basis. Rather, you measure whether
> it's
> necessary and if/when the necessary level of CCS becomes low enough, you
> just stop sending it ever.
>
> > That is, the standard should make it a mandatory message to send, fully
> > parsed
> > and validated, requiring aborting connection if it is received at any
> > unexpected moment, in duplicate, omitted or malformed. Not only as part of
> > the
> > "compatibility mode".
> 
> Yeah, I'm not enthusiastic about this. It's more stuff in the state machine
> that
> we hope to eventually eliminate. And as David says, it's totally unnecessary
> for QUIC and DTLS
> 
> -Ekr

what I was getting at is that if you want to be compatible with middleboxes, 
you send that CCS always, as you never know what thing will be between you and 
the peer

that means that all the large implementations will be sending them always

that means that new middleboxes will likely end up expecting it either way and 
existing ones won't have much incentive to update/fix

secondly, if we allow for sending CCS at any point, we will end up with the 
same bug as the Alert processing DoS there was in some implementations — one 
that allowed the peer to send unlimited amount of warning alerts

so even if we mark it as optional, I still think we should allow for it to be 
sent at only very specific moments and only once per side

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Extensions: Omitting Handshake Messages

[Eric Rescorla]

On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk 
wrote:

> Greetings,
>
> I've been reading though various RFCs and couldn't find a definite answer
> to my question: can a negotiated TLS extension skip some of the TLS
> Handshake messages and still be compliant with the TLS specification? My
> goal is to develop a new version of TLS (as part of my Master Thesis work),
> while preferably, staying backwards-compatible.
>
> Here, I will be specifically talking about TLS 1.2, defined in RFC 5246.
> Below is a message flow for the full handshake (taken directly from RFC
> 5246):
>
>   Client  Server
>   --  --
>
>   ClientHello  >
> ServerHello
> Certificate*
> ServerKeyExchange*
> CertificateRequest*
>   <  ServerHelloDone
>   Certificate*
>   ClientKeyExchange
>   CertificateVerify*
>   [ChangeCipherSpec]
>   Finished   >
>
> [ChangeCipherSpec]
>      Application Data  <--->   Application Data
>
>
> * (asterisk) Indicates optional or situation-dependent messages that are
> not always sent.
> Now, I do know that it's perfect legal for a TLS extension to modify the
> structure of some message or add a new message, but I'm not sure if one of
> the messages, not defined as optional/situation-dependent can be omitted.
>
> Let me give you a concrete example. Let's say I create a new extension
> called *XYZ*. The client and the server negotiate that extension in the
> their extended hello messages. Would it be legal for the *XYZ* extension
> to mandate the server not to send the *ServerHelloDone* message? As far
> as I understood, this is not legal.
>

You certainly can use extensions to indicate that a new message is to be
sent, so I don't think it would be necessarily be prohibited to have it
remove a message, though I can't offhand think of an example of where we do
so.


RFC 5245 Section 4.4.1.4 states that:
>
> "it would be technically possible to use extensions to change major aspects
> of the design of TLS; for example the design of cipher suite
> negotiation.  This is not recommended; it would be more appropriate to
> define a new version of TLS -- particularly since the TLS handshake
> algorithms have specific protection against version rollback attacks
> based on the version number, and the possibility of version rollback
> should be a significant consideration in any major design change"
>

To be honest, this mostly seems aspirational :)


I would assume, however, that those major aspects do no include omitting
> messages not marked as optional/situation-dependent in the spec.
>
> Both, TLS 1.2 and TLS 1.3 draft specs mention REQUIRED/MUST in the section
> describing the ClientHello. There are no REQUIRED mentions in other
> messages though. You do have the following for the Finished: "A Finished
> message is always sent immediately after a change cipher spec message to
> verify that the key exchange and authentication processes were successful."
> , so things like these lead me to believe that the messages not explicitly
> marked as optional, are in fact, required.
>

They're required absent some extension and you would have to be pretty
careful with changes which moved them.

-Ekr


>
>
> Thank you.
>
>
> ___
> 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] TLS Extensions: Omitting Handshake Messages

[Illya Gerasymchuk]

Greetings,

I've been reading though various RFCs and couldn't find a definite answer
to my question: can a negotiated TLS extension skip some of the TLS
Handshake messages and still be compliant with the TLS specification? My
goal is to develop a new version of TLS (as part of my Master Thesis work),
while preferably, staying backwards-compatible.

Here, I will be specifically talking about TLS 1.2, defined in RFC 5246.
Below is a message flow for the full handshake (taken directly from RFC
5246):

  Client  Server
  --  --

  ClientHello  >
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
  <  ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished   >
  [ChangeCipherSpec]
     Application Data


* (asterisk) Indicates optional or situation-dependent messages that are
not always sent.
Now, I do know that it's perfect legal for a TLS extension to modify the
structure of some message or add a new message, but I'm not sure if one of
the messages, not defined as optional/situation-dependent can be omitted.

Let me give you a concrete example. Let's say I create a new extension
called *XYZ*. The client and the server negotiate that extension in the
their extended hello messages. Would it be legal for the *XYZ* extension to
mandate the server not to send the *ServerHelloDone* message? As far as I
understood, this is not legal.

RFC 5245 Section 4.4.1.4 states that:

"it would be technically possible to use extensions to change major aspects
of the design of TLS; for example the design of cipher suite negotiation.
This is not recommended; it would be more appropriate to define a new
version of TLS -- particularly since the TLS handshake algorithms have
specific protection against version rollback attacks based on the version
number, and the possibility of version rollback should be a
significant consideration
in any major design change"

I would assume, however, that those major aspects do no include omitting
messages not marked as optional/situation-dependent in the spec.

Both, TLS 1.2 and TLS 1.3 draft specs mention REQUIRED/MUST in the section
describing the ClientHello. There are no REQUIRED mentions in other
messages though. You do have the following for the Finished: "A Finished
message is always sent immediately after a change cipher spec message to
verify that the key exchange and authentication processes were successful."
, so things like these lead me to believe that the messages not explicitly
marked as optional, are in fact, required.

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

Re: [TLS] network-based security solution use cases

[Eric Rescorla]

On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen 
wrote:

> Thank you for the feedback Ekr - please see below for responses
>
>
> On 11/6/17 12:43 PM, Eric Rescorla wrote:
>
> I took a look at this.
>
> Without getting into the question of whether the types of middleboxes
> you describe here provide a security benefit, there are several points
> in the document that are either wrong or at least misleading/confusing.
>
> - Key Synchronization
> This document notes that in TLS 1.2, it is possible for a middlebox
> that traffic keys match on both sides of the connection it is proxying,
> but in TLS 1.3 it is not:
>
>There are several techniques that can be utilized.  Those techniques
>function with TLS 1.2 and earlier versions but not with TLS 1.3.
>
>One technique is for the middlebox to negotiate the same master
>secret with the original TLS client and server, as if the two
>endpoints handshake directly.  This is also known as "Triple
>Handshake" used by legitimate middleboxes.  [BreakTLS] describes the
>methods with RSA and DH key exchanges.  When the proxy session keys
>are the same as for a direct handshake, the middlebox is able to
>"cut-through" the two TLS proxy sessions when it finishes the
>security inspection.
>
>This technique is not functional with TLS 1.3 since the transcript
>hash over the handshake messages is part of the key derivation
>procedure.
>
> First, I would note that this property of TLS 1.2 is bad, as it leads
> to Unknown Key Share (UKS) attacks, which can be the basis of real
> attacks on TLS 1.2 as fielded. It is for this reason that the TLS
> WG published RFC 7627.
>
> Thanks for the bringing that one up - we will make sure to include that in
> the next version.
>
> Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3, it's an
> integral part of the protocol that cannot be disabled. The TLS 1.2
> extension does not share that property.
>

It seems like an odd complaint that we are making protection against
Unknown Key Shares an integral part of the protocol



> Finally, you note several times in the document (e.g., S 4.5), that
> with key synchronization, the middlebox can perform the handshake and
> then disengage from the connection. However, the cases you mention
> (e.g.., detecting exploit attempts) ultimately require examining
> all traffic in the connection.
>
> We have several different use case scenarios in there, and I agree with
> the observation that they cannot all be satisfied at the same time. For
> example, we cannot scan for malware in an encrypted stream to a financial
> institution that we are not allowed to decrypt. That doesn't mean either
> use case is invalid. Customers do both in real-life (just not at the same
> time).
>

I'm finding it a bit puzzling what you claim customers do. Specifically,
you seem to be saying that customers examine the beginning of the
connection and then stop. What are they scanning for and what makes them
stop?



> - PSK and resumption
> You write:
>
>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.
>
> In TLS 1.3, PSKs and session resumption are basically the same and
> have the same properties. While I concede that the document does
> not require the client to offer key_shares, as a practical matter
> it is very unlikely that a client will act in such a way that
> failure to retain the PSK causes a hard failure, for two reasons:
>
> (a) In every version of TLS, the ticket lifetime is just a hint, and
> the server can forget it at any time
> (https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.
> html#NSTMessage). Thus,
> a client which does not allow a full handshake will often
> find itself unable to connect.
>
> (b) The relevant question is not whether the client offers a key share
> extension but whether it advertises any DH groups. If the client sends
> a group but not a key share, the server can send HelloRetryRequest
> to force the client to send a key share.
>
> For these reasons, as far as I know, every client (and at least every
> browser client) should allow a full handshake even when trying to resume.
>
> If that is indeed the case, then I 

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Eric Rescorla]

On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario  wrote:

> In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious
> failures as rare as possible is a good way to make that happen.
>
> that being said, I have few comments:
>
> On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote:
> > https://github.com/tlswg/tls13-spec/pull/1091
> >
> > As I mentioned a while back, we've been seeing evidence of middlebox
> > intolerance. I just posted PR 1091, which is based on a bunch of work
> > by the BoringSSL team and an original suggestion by Kyle Nekritz that
> > should significantly decrease the rate of these errors.
> >
> > The general idea here is to make TLS 1.3 look more like TLS 1.2
> > resumption. The major changes are:
> >
> > - Move version negotiation entirely into "supported_versions", and hence
> >   ServerHello.version == 0x0303 (TLS 1.2)
> > - Restore the missing session_id and compression fields in ServerHello
>
> less special cases in parser code - big +1
>
> > - The client sends a fake session_id and the server echoes it
> > - The server sends ChangeCipherSpec messages after
> > ServerHello/HelloRetryRequest
> >   (so that the middlebox ignores any "encrypted" data afterwards),
> >   and the client sends ChangeCipherSpec after ClientHello. Either
> >   side has to ignore ChangeCipherSpec during the handshake.
>
> That's the part I have a bit of a problem with.
> If the CCS is necessary to make middleboxes work, and given that
> lack-of-CCS-
> intolerance is not something that we can detect reliably (not in a way that
> can be simulated by an attacker), I think the CCS should be baked in the
> TLS
> 1.3 as deep as it was baked into TLS 1.2.
>

You don't detect it on an individualized basis. Rather, you measure whether
it's
necessary and if/when the necessary level of CCS becomes low enough, you
just stop sending it ever.


That is, the standard should make it a mandatory message to send, fully
> parsed
> and validated, requiring aborting connection if it is received at any
> unexpected moment, in duplicate, omitted or malformed. Not only as part of
> the
> "compatibility mode".
>

Yeah, I'm not enthusiastic about this. It's more stuff in the state machine
that
we hope to eventually eliminate. And as David says, it's totally unnecessary
for QUIC and DTLS

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

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[David Benjamin]

On Tue, Nov 7, 2017 at 10:53 AM Hubert Kario  wrote:

> In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious
> failures as rare as possible is a good way to make that happen.
>
> that being said, I have few comments:
>
> On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote:
> > https://github.com/tlswg/tls13-spec/pull/1091
> >
> > As I mentioned a while back, we've been seeing evidence of middlebox
> > intolerance. I just posted PR 1091, which is based on a bunch of work
> > by the BoringSSL team and an original suggestion by Kyle Nekritz that
> > should significantly decrease the rate of these errors.
> >
> > The general idea here is to make TLS 1.3 look more like TLS 1.2
> > resumption. The major changes are:
> >
> > - Move version negotiation entirely into "supported_versions", and hence
> >   ServerHello.version == 0x0303 (TLS 1.2)
> > - Restore the missing session_id and compression fields in ServerHello
>
> less special cases in parser code - big +1
>
> > - The client sends a fake session_id and the server echoes it
> > - The server sends ChangeCipherSpec messages after
> > ServerHello/HelloRetryRequest
> >   (so that the middlebox ignores any "encrypted" data afterwards),
> >   and the client sends ChangeCipherSpec after ClientHello. Either
> >   side has to ignore ChangeCipherSpec during the handshake.
>
> That's the part I have a bit of a problem with.
> If the CCS is necessary to make middleboxes work, and given that
> lack-of-CCS-
> intolerance is not something that we can detect reliably (not in a way that
> can be simulated by an attacker), I think the CCS should be baked in the
> TLS
> 1.3 as deep as it was baked into TLS 1.2.
>
> That is, the standard should make it a mandatory message to send, fully
> parsed
> and validated, requiring aborting connection if it is received at any
> unexpected moment, in duplicate, omitted or malformed. Not only as part of
> the
> "compatibility mode".
>

Having the receiver check would work for us (it's what our prototypes do).
And it's true that, were receivers to enforce this, it would be more likely
that implementations reliably work in these environments despite not
testing against them directly.

But we got feedback that this would be too much complexity for some folks.
Getting CCS/handshake synchronization right is a little subtle. And indeed,
I think CCS in TLS 1.2 was generally considered to have been a mistake.
Having the receiver ignore CCS also allows use cases without this kind of
baggage (consider QUIC's embedding of TLS 1.3) to unilaterally disable this
compatibility mode.

So I think I prefer the formulation in the PR.


> > - Merge HRR and ServerHello into a single message with the semantics
> >   distinguished by a special ServerHello.Random value.
> > - Switch the record layer version to 0x0303 for post-ClientHello
> >   messages to match ServerHello.
> >
> > Once you do this, the middleboxes seem to mostly ignore everything
> > after the CCS, so the rest of the handshake proceeds smoothly.
>
> So I have this crazy idea... What happens if the first message sent by
> client
> and server is the CCS?
>

We didn't test that variant, but we did try turning off the
client-generated session ID to see if that was necessary and it was if I
recall, the failure rate without that was comparable to draft-18 if not
higher. Additionally, we know that making the record layer say TLS 1.2 was
necessary once we made ServerHello.version say TLS 1.2. (We'd have had a
proposal for the working group sooner had we not missed that difference
first time around! :-( )

This makes me doubt just sticking a CCS in front would suffice. It suggests
that middleboxes are actually parsing out TLS more deeply than that. Which
is also what one can expect. I think the clear conclusion one can draw from
this issue and similar elsewhere is that every reliably observable property
of network traffic will, over time, become ossified. The Internet is very
change-averse, and TLS 1.2 gave it far too many bits to latch onto.


> > This is all a bit nasty, but none of it changes the cryptographic
> > computations or the state machine (because you just ignore CCS).
> > Several of the most unpleasant changes (sending fake session id and
> > sending ChangeCipherSpec), are only needed in compatibility mode,
> > and if you don't have to worry about middleboxes, you can just
> > omit them.
> >
> > There are implementations of these changes (except for HRR) in both
> > BoringSSL and NSS, and Google has preliminary measurements with these
> > changes that show comparable error rates to TLS 1.2 (I expect them to
> > publish those shortly). We expect to have further measurements from
> > Chrome as well as from Firefox by the WG meeting.
> >
> > Please take a look and hopefully we can close on this in Singapore.
>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., 

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

[Peter Saint-Andre]

On 11/7/17 8:15 AM, Hannes Tschofenig wrote:
> FWIW: I can tell you what the threat model was with the layered TLS work.
> 
> Let me give you a very specific example. Imagine a Bluetooth Low Energy
> device that communicates via a phone to a cloud-based service. The
> communication from the phone to the cloud uses HTTPS. The communication
> from the BLE device to the phone uses ordinary BLE
> services/characteristics.
> 
> The Layered TLS/application layer TLS would in this case run from the
> BLE device all the way to the cloud-based service at the application layer.
> 
> This allows us to provide end-to-end security across a proxy (in this
> case the phone) and independent of the underlying protocols.
> 
> Does this make sense?

Given your assumptions, yes. Although IMHO there's got to be a better
way to accomplish the goal of end-to-end security here. If I were going
to IETF 100, I'd propose getting together for a beer to discuss...

Peter



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

Re: [TLS] network-based security solution use cases

[Flemming Andreasen]

Thank you for the feedback Ekr - please see below for responses

On 11/6/17 12:43 PM, Eric Rescorla wrote:

I took a look at this.

Without getting into the question of whether the types of middleboxes
you describe here provide a security benefit, there are several points
in the document that are either wrong or at least misleading/confusing.

- Key Synchronization
This document notes that in TLS 1.2, it is possible for a middlebox
that traffic keys match on both sides of the connection it is proxying,
but in TLS 1.3 it is not:

   There are several techniques that can be utilized. Those techniques
   function with TLS 1.2 and earlier versions but not with TLS 1.3.

   One technique is for the middlebox to negotiate the same master
   secret with the original TLS client and server, as if the two
   endpoints handshake directly.  This is also known as "Triple
   Handshake" used by legitimate middleboxes.  [BreakTLS] describes the
   methods with RSA and DH key exchanges.  When the proxy session keys
   are the same as for a direct handshake, the middlebox is able to
   "cut-through" the two TLS proxy sessions when it finishes the
   security inspection.

   This technique is not functional with TLS 1.3 since the transcript
   hash over the handshake messages is part of the key derivation
   procedure.

First, I would note that this property of TLS 1.2 is bad, as it leads
to Unknown Key Share (UKS) attacks, which can be the basis of real
attacks on TLS 1.2 as fielded. It is for this reason that the TLS
WG published RFC 7627.

Thanks for the bringing that one up - we will make sure to include that 
in the next version.


Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3, it's 
an integral part of the protocol that cannot be disabled. The TLS 1.2 
extension does not share that property.



Second, this property is really only available with RSA. Although
it is possible for an attacker to synchronize DH keys by generating
bogus DH parameters, the technique described by Bhargavan et al
results in an insecure MS (i.e., the server's public DH share).
[See Section V-B of https://www.mitls.org/downloads/tlsauth.pdf]
Any middlebox doing this, therefore, has completely broken TLS
for the endpoints on both sides of it. Your document suggests
that people do use this technique: I sincerely hope not.


I'm not aware of actual implementations doing this with DH.



In short, this property of TLS 1.3 is really a property of the use
of (EC)DHE [0], the use of which is important for security even in TLS 1.2
(hence the rapid increase in the use of ECDHE and the corresponding
decline in static RSA). Even if TLS 1.3 were never deployed, the
continued use of static RSA is going to be come increasingly
nonviable.


Fair point.



Finally, you note several times in the document (e.g., S 4.5), that
with key synchronization, the middlebox can perform the handshake and
then disengage from the connection. However, the cases you mention
(e.g.., detecting exploit attempts) ultimately require examining
all traffic in the connection.

We have several different use case scenarios in there, and I agree with 
the observation that they cannot all be satisfied at the same time. For 
example, we cannot scan for malware in an encrypted stream to a 
financial institution that we are not allowed to decrypt. That doesn't 
mean either use case is invalid. Customers do both in real-life (just 
not at the same time).




- PSK and resumption
You write:

   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.

In TLS 1.3, PSKs and session resumption are basically the same and
have the same properties. While I concede that the document does
not require the client to offer key_shares, as a practical matter
it is very unlikely that a client will act in such a way that
failure to retain the PSK causes a hard failure, for two reasons:

(a) In every version of TLS, the ticket lifetime is just a hint, and
    the server can forget it at any time
    
(https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#NSTMessage 
). 
Thus,

    a client which does not allow a full handshake will often
    find itself unable to connect.

(b) The relevant 

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Hubert Kario]

In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious 
failures as rare as possible is a good way to make that happen.

that being said, I have few comments:

On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/pull/1091
> 
> As I mentioned a while back, we've been seeing evidence of middlebox
> intolerance. I just posted PR 1091, which is based on a bunch of work
> by the BoringSSL team and an original suggestion by Kyle Nekritz that
> should significantly decrease the rate of these errors.
> 
> The general idea here is to make TLS 1.3 look more like TLS 1.2
> resumption. The major changes are:
> 
> - Move version negotiation entirely into "supported_versions", and hence
>   ServerHello.version == 0x0303 (TLS 1.2)
> - Restore the missing session_id and compression fields in ServerHello

less special cases in parser code - big +1

> - The client sends a fake session_id and the server echoes it
> - The server sends ChangeCipherSpec messages after
> ServerHello/HelloRetryRequest
>   (so that the middlebox ignores any "encrypted" data afterwards),
>   and the client sends ChangeCipherSpec after ClientHello. Either
>   side has to ignore ChangeCipherSpec during the handshake.

That's the part I have a bit of a problem with.
If the CCS is necessary to make middleboxes work, and given that lack-of-CCS-
intolerance is not something that we can detect reliably (not in a way that 
can be simulated by an attacker), I think the CCS should be baked in the TLS 
1.3 as deep as it was baked into TLS 1.2.

That is, the standard should make it a mandatory message to send, fully parsed 
and validated, requiring aborting connection if it is received at any 
unexpected moment, in duplicate, omitted or malformed. Not only as part of the 
"compatibility mode".

> - Merge HRR and ServerHello into a single message with the semantics
>   distinguished by a special ServerHello.Random value.
> - Switch the record layer version to 0x0303 for post-ClientHello
>   messages to match ServerHello.
> 
> Once you do this, the middleboxes seem to mostly ignore everything
> after the CCS, so the rest of the handshake proceeds smoothly.

So I have this crazy idea... What happens if the first message sent by client 
and server is the CCS?
 
> This is all a bit nasty, but none of it changes the cryptographic
> computations or the state machine (because you just ignore CCS).
> Several of the most unpleasant changes (sending fake session id and
> sending ChangeCipherSpec), are only needed in compatibility mode,
> and if you don't have to worry about middleboxes, you can just
> omit them.
> 
> There are implementations of these changes (except for HRR) in both
> BoringSSL and NSS, and Google has preliminary measurements with these
> changes that show comparable error rates to TLS 1.2 (I expect them to
> publish those shortly). We expect to have further measurements from
> Chrome as well as from Firefox by the WG meeting.
> 
> Please take a look and hopefully we can close on this in Singapore.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

[Yoav Nir]

Hi, Hannes.

I think it makes sense if the middlebox (whether a TLS proxy or a phone) cannot 
perform a MitM attack against the internal TLS. This can be achieved by having 
separate trust anchors for the application vs the ones used for HTTPS, 
specifically not including any “proxy CA certificate”.

Yoav

> On 7 Nov 2017, at 17:15, Hannes Tschofenig  wrote:
> 
> FWIW: I can tell you what the threat model was with the layered TLS work.
> 
> Let me give you a very specific example. Imagine a Bluetooth Low Energy
> device that communicates via a phone to a cloud-based service. The
> communication from the phone to the cloud uses HTTPS. The communication
> from the BLE device to the phone uses ordinary BLE
> services/characteristics.
> 
> The Layered TLS/application layer TLS would in this case run from the
> BLE device all the way to the cloud-based service at the application layer.
> 
> This allows us to provide end-to-end security across a proxy (in this
> case the phone) and independent of the underlying protocols.
> 
> Does this make sense?
> 
> Ciao
> Hannes
> 
> 
> On 11/07/2017 10:21 AM, Alex C wrote:
>> What exactly is the threat model here?
>> 
>> Are you trying to hide a connection from a reverse proxy at the server
>> end? If so, the server operator should not have deployed a reverse proxy
>> in the first place.
>> 
>> Are you trying to hide from a MITM proxy that supplies its own
>> certificate? If so, then what prevents the proxy from doing the same to
>> the tunnelled session?
>> When MITM proxies learn to do that, will we create another tunnelling
>> protocol inside this one?
>> 
>> This is a cat-and-mouse game with middleboxes (much like the version
>> negotiation problem, but in a different way). Keep playing and everyone
>> loses.
>> 
>> On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes > >> wrote:
>> 
>>Hey TLS folks,
>> 
>>Owen, Max, and I have been kicking around some ideas for how to make
>>secure connections in environments where HTTPS is subject to MitM /
>>proxying.
>> 
>>The below draft lays out a way to tunnel TLS over HTTPS, in hopes of
>>creating a channel you could use when you really need things to be
>>private, even from the local MitM.
>> 
>>Feedback obviously very welcome.  Interested in whether folks think
>>this is a useful area in which to develop an RFC, and any thoughts
>>on how to do this better.
>> 
>>Thanks,
>>--Richard
>> 
>> 
>>On Mon, Oct 30, 2017 at 3:47 PM, > 
>>>> 
>> wrote:
>> 
>> 
>>A new version of I-D, draft-friel-tls-over-http-00.txt
>>has been successfully submitted by Owen Friel and posted to the
>>IETF repository.
>> 
>>Name:   draft-friel-tls-over-http
>>Revision:   00
>>Title:  Application-Layer TLS
>>Document date:  2017-10-30
>>Group:  Individual Submission
>>Pages:  20
>>URL:
>>https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt 
>> 
>>
>> > >
>>Status:
>> https://datatracker.ietf.org/doc/draft-friel-tls-over-http/ 
>> 
>>> >
>>Htmlized:
>> https://tools.ietf.org/html/draft-friel-tls-over-http-00 
>> 
>>> >
>>Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00 
>> 
>>> >
>> 
>> 
>>Abstract:
>>   Many clients need to establish secure connections to application
>>   services but face challenges establishing these connections
>>due to
>>   the presence of middleboxes that terminate TLS connections
>>from the
>>   client and restablish new TLS connections to the service.  This
>>   document defines a mechanism for transporting TLS records in HTTP
>>   message bodies between clients and services.  This enables
>>clients
>>   and services to establish secure connections using TLS at the
>> 

Re: [TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

[Hannes Tschofenig]

On 11/07/2017 01:20 PM, Salz, Rich wrote:
> 
> ➢ Our work was motivated by the discussions in the IoT groups about
> re-inventing the TLS handshake at the application layer.
> 
>  Isn’t that what QUIC does (to a good enough approximation)?
> 

I see QUIC more as a new transport layer.

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

Re: [TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

[Salz, Rich]

➢ Our work was motivated by the discussions in the IoT groups about
re-inventing the TLS handshake at the application layer.

 Isn’t that what QUIC does (to a good enough approximation)?

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

[TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

[Hannes Tschofenig]

This is interesting since Mark Baugher and myself have also been working
on the use of TLS at the application layer and we did some
implementation work with mbed TLS (with TLS 1.3) and OpenSSL.

Our work was motivated by the discussions in the IoT groups about
re-inventing the TLS handshake at the application layer.

Our document can be found here:
https://tools.ietf.org/html/draft-tschofenig-layered-tls-00

Ciao
Hannes

On 11/07/2017 10:21 AM, Alex C wrote:
> What exactly is the threat model here?
> 
> Are you trying to hide a connection from a reverse proxy at the server
> end? If so, the server operator should not have deployed a reverse proxy
> in the first place.
> 
> Are you trying to hide from a MITM proxy that supplies its own
> certificate? If so, then what prevents the proxy from doing the same to
> the tunnelled session?
> When MITM proxies learn to do that, will we create another tunnelling
> protocol inside this one?
> 
> This is a cat-and-mouse game with middleboxes (much like the version
> negotiation problem, but in a different way). Keep playing and everyone
> loses.
> 
> On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes  > wrote:
> 
> Hey TLS folks,
> 
> Owen, Max, and I have been kicking around some ideas for how to make
> secure connections in environments where HTTPS is subject to MitM /
> proxying.
> 
> The below draft lays out a way to tunnel TLS over HTTPS, in hopes of
> creating a channel you could use when you really need things to be
> private, even from the local MitM. 
> 
> Feedback obviously very welcome.  Interested in whether folks think
> this is a useful area in which to develop an RFC, and any thoughts
> on how to do this better.
> 
> Thanks,
> --Richard
> 
> 
> On Mon, Oct 30, 2017 at 3:47 PM,  > wrote:
> 
> 
> A new version of I-D, draft-friel-tls-over-http-00.txt
> has been successfully submitted by Owen Friel and posted to the
> IETF repository.
> 
> Name:           draft-friel-tls-over-http
> Revision:       00
> Title:          Application-Layer TLS
> Document date:  2017-10-30
> Group:          Individual Submission
> Pages:          20
> URL:           
> https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt
> 
> 
> Status:       
>  https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
> 
> Htmlized:     
>  https://tools.ietf.org/html/draft-friel-tls-over-http-00
> 
> Htmlized:     
>  https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00
> 
> 
> 
> Abstract:
>    Many clients need to establish secure connections to application
>    services but face challenges establishing these connections
> due to
>    the presence of middleboxes that terminate TLS connections
> from the
>    client and restablish new TLS connections to the service.  This
>    document defines a mechanism for transporting TLS records in HTTP
>    message bodies between clients and services.  This enables
> clients
>    and services to establish secure connections using TLS at the
>    application layer, and treat any middleboxes that are
> intercepting
>    traffic at the network layer as untrusted transport.  In
> short, this
>    mechanism moves the TLS handshake up the OSI stack to the
> application
>    layer.
> 
> 
> 
> 
> 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
> 
> 
> 
> 
> 
> ___
> 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] New Version Notification for draft-friel-tls-over-http-00.txt

[Alex C]

What exactly is the threat model here?

Are you trying to hide a connection from a reverse proxy at the server end?
If so, the server operator should not have deployed a reverse proxy in the
first place.

Are you trying to hide from a MITM proxy that supplies its own certificate?
If so, then what prevents the proxy from doing the same to the tunnelled
session?
When MITM proxies learn to do that, will we create another tunnelling
protocol inside this one?

This is a cat-and-mouse game with middleboxes (much like the version
negotiation problem, but in a different way). Keep playing and everyone
loses.

On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes  wrote:

> Hey TLS folks,
>
> Owen, Max, and I have been kicking around some ideas for how to make
> secure connections in environments where HTTPS is subject to MitM /
> proxying.
>
> The below draft lays out a way to tunnel TLS over HTTPS, in hopes of
> creating a channel you could use when you really need things to be private,
> even from the local MitM.
>
> Feedback obviously very welcome.  Interested in whether folks think this
> is a useful area in which to develop an RFC, and any thoughts on how to do
> this better.
>
> Thanks,
> --Richard
>
>
> On Mon, Oct 30, 2017 at 3:47 PM,  wrote:
>
>>
>> A new version of I-D, draft-friel-tls-over-http-00.txt
>> has been successfully submitted by Owen Friel and posted to the
>> IETF repository.
>>
>> Name:   draft-friel-tls-over-http
>> Revision:   00
>> Title:  Application-Layer TLS
>> Document date:  2017-10-30
>> Group:  Individual Submission
>> Pages:  20
>> URL:https://www.ietf.org/internet-
>> drafts/draft-friel-tls-over-http-00.txt
>> Status: https://datatracker.ietf.org/
>> doc/draft-friel-tls-over-http/
>> Htmlized:   https://tools.ietf.org/html/draft-friel-tls-over-http-00
>> Htmlized:   https://datatracker.ietf.org/
>> doc/html/draft-friel-tls-over-http-00
>>
>>
>> Abstract:
>>Many clients need to establish secure connections to application
>>services but face challenges establishing these connections due to
>>the presence of middleboxes that terminate TLS connections from the
>>client and restablish new TLS connections to the service.  This
>>document defines a mechanism for transporting TLS records in HTTP
>>message bodies between clients and services.  This enables clients
>>and services to establish secure connections using TLS at the
>>application layer, and treat any middleboxes that are intercepting
>>traffic at the network layer as untrusted transport.  In short, this
>>mechanism moves the TLS handshake up the OSI stack to the application
>>layer.
>>
>>
>>
>>
>> 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
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] network-based security solution use cases

[Stephen Farrell]

Hiya,

On 07/11/17 02:48, Flemming Andreasen wrote:
>>
> We didn't draw any particular line, but the use case scenarios that we
> tried to highlight are those related to overall security and regulatory
> requirements (including public sector)

I had a quick look at the draft (will try read properly en-route to
ietf-100) and I followed the reference to [1] but that only lead to a
forest of documents in which I didn't find any reference to breaking
TLS so far at least. Can you provide an explicit pointer to the
exact document on which that claim is based?

I'd also claim that your reference to PCI-DSS is misleading, as that
same spec also explicitly calls for there to be good key management
specifically including minimising the number of copies of keys, so
at most, one might be able to claim that PCI-DSS is ok with people
who break TLS in a nod-and-a-wink manner. But if you do have a real
quote from PCI-DSS that calls for breaking TLS then please do also
send that (it's been asked for a bunch of times without any answer
being provided so far).

Thanks,
S.


[1]
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP



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