Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon]

Encrypted dns transport works if you can trust the provider you are talking
to. DNSSEC works even if you can’t. And if your provider is trustworthy,
DNSSEC validation of results acquired through this tunnel should work. So
it’s silly in this case to trust the tunnel—there’s no upside to doing so
other than avoiding a few signature verifications.

Op za 30 mrt 2024 om 14:02 schreef Rob Sayre 

> On Sat, Mar 30, 2024 at 10:47 AM Erik Nygren  wrote:
>
>>
>> An attacker who can prevent SVCB resolution can deny clients any
>> associated security benefits.
>>
>>
> Yes.
>
>
>> A hostile recursive resolver can always deny service to SVCB queries, but
>> network intermediaries can often prevent resolution as well, even when the
>> client and recursive resolver validate DNSSEC and use a secure transport.
>> These downgrade attacks can prevent a client from being aware that "ech" is
>> configured which would result in the client sending the ClientHello in
>> cleartext.
>>
>>
> I think s/would/could/ here.
>
> I don't know if we want to write it, but doesn't using encrypted transport
> DNS to an IP address avoid this problem? Like using 1.1.1.1 or 8.8.8.8 etc.
> I know that raises centralization issues, but it does help with this issue.
>
> thanks,
> Rob
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon]

I think that would make sense, yes.

On Sat, Mar 30, 2024 at 10:58 AM Erik Nygren  wrote:

> Do we want a few sentences in Security Considerations that references
> https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1 to call this out?
>
> This seems like something that became less clear when we split these two
> docs apart.
> Most of draft-ietf-tls-svcb-ech used to be a section of what is now
> rfc9460 but got split out
> due to publication timelines.  It may be that some non-normative
> references back to rfc9460
> might help readers not miss things like this which might have been more
> clear when they
> were a single document.
>
>Erik
>
>
>
>
> On Fri, Mar 29, 2024 at 11:31 PM Ted Lemon  wrote:
>
>> Yes, that fully addresses my concern. Thanks!
>>
>> Op vr 29 mrt 2024 om 22:54 schreef Eric Rescorla 
>>
>>>
>>> Hi Ted,
>>>
>>> Doesn't this section of RFC 9460 address this case and say what you are
>>> recommending:
>>>
>>> https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1
>>>
>>> -Ekr
>>>
>>>
>>>
>>> On Fri, Mar 29, 2024 at 6:49 PM Ted Lemon  wrote:
>>>
>>>> Okay, I think I see the disconnect, maybe. The issue I'm pointing to is
>>>> that you may or may not be doing DNSSEC validation. And you may or may not
>>>> be /able/ to do DNSSEC validation if the infrastructure breaks it
>>>> accidentally or deliberately.
>>>>
>>>> The document says: "The SVCB-optional client behavior specified in
>>>> (Section 3 of [SVCB]) permits clients to fall back to a direct connection
>>>> if all SVCB options fail. This behavior is not suitable for ECH, because
>>>> fallback would negate the privacy benefits of ECH."
>>>>
>>>> So it's saying that the default handling of SVCB is incorrect and would
>>>> fail open, and overriding that behavior. Given that this is the case, that
>>>> implies that it matters whether the data has been validated, but nowhere in
>>>> the document, certainly not in Security Considerations, is any mention made
>>>> of this issue. So that's what I'm pointing out.
>>>>
>>>> It is absolutely not the case in practice that all stub resolvers do
>>>> validation. You are making a security decision about trust based on data
>>>> the trustworthiness of which you've not discussed, in a situation where the
>>>> implementor has meaningful choices to make with respect to validating that
>>>> trustworthiness. So it's worth mentioning that if the policy is not to
>>>> validate, this vulnerability exists.
>>>>
>>>> I'm a DNS guy, not a TLS guy, so I don't know the history of this
>>>> work—I'm just making this observation about the document I was asked to
>>>> review. The fact that (apparently) no DNSDIR review ever raised this issue
>>>> about the other documents you mentioned is of no interest to me—I'm not
>>>> reviewing those documents.Whether you take this advice is between you and
>>>> the IESG. I'm not even claiming to be right—just pointing out the issue I
>>>> see.
>>>>
>>>> On Fri, Mar 29, 2024 at 7:21 PM Rob Sayre  wrote:
>>>>
>>>>> I don't think it relates to DNSSEC. You can fail at DNS (DNSSEC
>>>>> failure) or you can fail during ECH (unless you want to use non-ECH, which
>>>>> is not ECH, and not part of this draft).
>>>>>
>>>>> It makes sense to me: one can reject a request unless the requirements
>>>>> embedded in the SVCB are met (the server chooses those, which can include
>>>>> many aspects of the request). I don't understand why one would insert
>>>>> DNSSEC here. That seems to be the whole point--it works without it.
>>>>>
>>>>> thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>> On Fri, Mar 29, 2024 at 3:57 PM Ted Lemon  wrote:
>>>>>
>>>>>> I'm not telling you that you have to require DNSSEC. I'm saying the
>>>>>> document is incomplete if you don't talk about how it relates to DNSSEC. 
>>>>>> I
>>>>>> think EKR got the point, so maybe go with his approach?
>>>>>>
>>>>>> On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre  wrote:
>>>>>>
>>>>>>> It&#x

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon]

Yes, that fully addresses my concern. Thanks!

Op vr 29 mrt 2024 om 22:54 schreef Eric Rescorla 

>
> Hi Ted,
>
> Doesn't this section of RFC 9460 address this case and say what you are
> recommending:
>
> https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1
>
> -Ekr
>
>
>
> On Fri, Mar 29, 2024 at 6:49 PM Ted Lemon  wrote:
>
>> Okay, I think I see the disconnect, maybe. The issue I'm pointing to is
>> that you may or may not be doing DNSSEC validation. And you may or may not
>> be /able/ to do DNSSEC validation if the infrastructure breaks it
>> accidentally or deliberately.
>>
>> The document says: "The SVCB-optional client behavior specified in
>> (Section 3 of [SVCB]) permits clients to fall back to a direct connection
>> if all SVCB options fail. This behavior is not suitable for ECH, because
>> fallback would negate the privacy benefits of ECH."
>>
>> So it's saying that the default handling of SVCB is incorrect and would
>> fail open, and overriding that behavior. Given that this is the case, that
>> implies that it matters whether the data has been validated, but nowhere in
>> the document, certainly not in Security Considerations, is any mention made
>> of this issue. So that's what I'm pointing out.
>>
>> It is absolutely not the case in practice that all stub resolvers do
>> validation. You are making a security decision about trust based on data
>> the trustworthiness of which you've not discussed, in a situation where the
>> implementor has meaningful choices to make with respect to validating that
>> trustworthiness. So it's worth mentioning that if the policy is not to
>> validate, this vulnerability exists.
>>
>> I'm a DNS guy, not a TLS guy, so I don't know the history of this
>> work—I'm just making this observation about the document I was asked to
>> review. The fact that (apparently) no DNSDIR review ever raised this issue
>> about the other documents you mentioned is of no interest to me—I'm not
>> reviewing those documents.Whether you take this advice is between you and
>> the IESG. I'm not even claiming to be right—just pointing out the issue I
>> see.
>>
>> On Fri, Mar 29, 2024 at 7:21 PM Rob Sayre  wrote:
>>
>>> I don't think it relates to DNSSEC. You can fail at DNS (DNSSEC failure)
>>> or you can fail during ECH (unless you want to use non-ECH, which is not
>>> ECH, and not part of this draft).
>>>
>>> It makes sense to me: one can reject a request unless the requirements
>>> embedded in the SVCB are met (the server chooses those, which can include
>>> many aspects of the request). I don't understand why one would insert
>>> DNSSEC here. That seems to be the whole point--it works without it.
>>>
>>> thanks,
>>> Rob
>>>
>>>
>>> On Fri, Mar 29, 2024 at 3:57 PM Ted Lemon  wrote:
>>>
>>>> I'm not telling you that you have to require DNSSEC. I'm saying the
>>>> document is incomplete if you don't talk about how it relates to DNSSEC. I
>>>> think EKR got the point, so maybe go with his approach?
>>>>
>>>> On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre  wrote:
>>>>
>>>>> It's a policy choice, though, right? I think ekr hinted at this issue
>>>>> as well.
>>>>>
>>>>> It's that one might also view requests that reveal the SNI as
>>>>> insecure. If that's the case, DNSSEC doesn't help. There will certainly be
>>>>> a transition period where that will be impractical for many servers. I
>>>>> think these are separate problems, though.
>>>>>
>>>>> thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>> On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon  wrote:
>>>>>
>>>>>> It looks like if you can't get the SCVB you're going to fail
>>>>>> insecure, so being able to use DNSSEC to prevent that for signed domains
>>>>>> seems worthwhile.
>>>>>>
>>>>>> On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:
>>>>>>
>>>>>>> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
>>>>>>> nore...@ietf.org> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I don't think it's reasonable to specify the privacy properties of
>>>>&g

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon]

Okay, I think I see the disconnect, maybe. The issue I'm pointing to is
that you may or may not be doing DNSSEC validation. And you may or may not
be /able/ to do DNSSEC validation if the infrastructure breaks it
accidentally or deliberately.

The document says: "The SVCB-optional client behavior specified in (Section
3 of [SVCB]) permits clients to fall back to a direct connection if all
SVCB options fail. This behavior is not suitable for ECH, because fallback
would negate the privacy benefits of ECH."

So it's saying that the default handling of SVCB is incorrect and would
fail open, and overriding that behavior. Given that this is the case, that
implies that it matters whether the data has been validated, but nowhere in
the document, certainly not in Security Considerations, is any mention made
of this issue. So that's what I'm pointing out.

It is absolutely not the case in practice that all stub resolvers do
validation. You are making a security decision about trust based on data
the trustworthiness of which you've not discussed, in a situation where the
implementor has meaningful choices to make with respect to validating that
trustworthiness. So it's worth mentioning that if the policy is not to
validate, this vulnerability exists.

I'm a DNS guy, not a TLS guy, so I don't know the history of this work—I'm
just making this observation about the document I was asked to review. The
fact that (apparently) no DNSDIR review ever raised this issue about the
other documents you mentioned is of no interest to me—I'm not reviewing
those documents.Whether you take this advice is between you and the IESG.
I'm not even claiming to be right—just pointing out the issue I see.

On Fri, Mar 29, 2024 at 7:21 PM Rob Sayre  wrote:

> I don't think it relates to DNSSEC. You can fail at DNS (DNSSEC failure)
> or you can fail during ECH (unless you want to use non-ECH, which is not
> ECH, and not part of this draft).
>
> It makes sense to me: one can reject a request unless the requirements
> embedded in the SVCB are met (the server chooses those, which can include
> many aspects of the request). I don't understand why one would insert
> DNSSEC here. That seems to be the whole point--it works without it.
>
> thanks,
> Rob
>
>
> On Fri, Mar 29, 2024 at 3:57 PM Ted Lemon  wrote:
>
>> I'm not telling you that you have to require DNSSEC. I'm saying the
>> document is incomplete if you don't talk about how it relates to DNSSEC. I
>> think EKR got the point, so maybe go with his approach?
>>
>> On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre  wrote:
>>
>>> It's a policy choice, though, right? I think ekr hinted at this issue as
>>> well.
>>>
>>> It's that one might also view requests that reveal the SNI as insecure.
>>> If that's the case, DNSSEC doesn't help. There will certainly be a
>>> transition period where that will be impractical for many servers. I think
>>> these are separate problems, though.
>>>
>>> thanks,
>>> Rob
>>>
>>>
>>> On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon  wrote:
>>>
>>>> It looks like if you can't get the SCVB you're going to fail insecure,
>>>> so being able to use DNSSEC to prevent that for signed domains seems
>>>> worthwhile.
>>>>
>>>> On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:
>>>>
>>>>> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
>>>>> nore...@ietf.org> wrote:
>>>>>
>>>>>>
>>>>>> I don't think it's reasonable to specify the privacy properties of
>>>>>> SVCB and
>>>>>> /not/ talk about DNSSEC validation.
>>>>>>
>>>>>
>>>>> Could you explain more about this part? I think DNSSEC doesn't add
>>>>> much here, unless you want to accept non-ECH traffic. For example, many of
>>>>> the test servers will bounce you to some other site if you don't send ECH
>>>>> or screw it up in some way (speaking as someone who has screwed it up many
>>>>> times...).
>>>>>
>>>>> I think there might be a DoS attack here, where someone messes with
>>>>> the response, but they can also turn off the DNSSEC bit unless it's
>>>>> DoT/DoH/DoQ etc. So, if using those, it's just the trustworthiness of the
>>>>> DNS server itself, right? Sorry if I'm missing something.
>>>>>
>>>>> thanks,
>>>>> Rob
>>>>>
>>>>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon]

I'm not telling you that you have to require DNSSEC. I'm saying the
document is incomplete if you don't talk about how it relates to DNSSEC. I
think EKR got the point, so maybe go with his approach?

On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre  wrote:

> It's a policy choice, though, right? I think ekr hinted at this issue as
> well.
>
> It's that one might also view requests that reveal the SNI as insecure. If
> that's the case, DNSSEC doesn't help. There will certainly be a transition
> period where that will be impractical for many servers. I think these are
> separate problems, though.
>
> thanks,
> Rob
>
>
> On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon  wrote:
>
>> It looks like if you can't get the SCVB you're going to fail insecure, so
>> being able to use DNSSEC to prevent that for signed domains seems
>> worthwhile.
>>
>> On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:
>>
>>> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
>>> nore...@ietf.org> wrote:
>>>
>>>>
>>>> I don't think it's reasonable to specify the privacy properties of SVCB
>>>> and
>>>> /not/ talk about DNSSEC validation.
>>>>
>>>
>>> Could you explain more about this part? I think DNSSEC doesn't add much
>>> here, unless you want to accept non-ECH traffic. For example, many of the
>>> test servers will bounce you to some other site if you don't send ECH or
>>> screw it up in some way (speaking as someone who has screwed it up many
>>> times...).
>>>
>>> I think there might be a DoS attack here, where someone messes with the
>>> response, but they can also turn off the DNSSEC bit unless it's DoT/DoH/DoQ
>>> etc. So, if using those, it's just the trustworthiness of the DNS server
>>> itself, right? Sorry if I'm missing something.
>>>
>>> thanks,
>>> Rob
>>>
>>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon]

It looks like if you can't get the SCVB you're going to fail insecure, so
being able to use DNSSEC to prevent that for signed domains seems
worthwhile.

On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:

> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
> nore...@ietf.org> wrote:
>
>>
>> I don't think it's reasonable to specify the privacy properties of SVCB
>> and
>> /not/ talk about DNSSEC validation.
>>
>
> Could you explain more about this part? I think DNSSEC doesn't add much
> here, unless you want to accept non-ECH traffic. For example, many of the
> test servers will bounce you to some other site if you don't send ECH or
> screw it up in some way (speaking as someone who has screwed it up many
> times...).
>
> I think there might be a DoS attack here, where someone messes with the
> response, but they can also turn off the DNSSEC bit unless it's DoT/DoH/DoQ
> etc. So, if using those, it's just the trustworthiness of the DNS server
> itself, right? Sorry if I'm missing something.
>
> thanks,
> Rob
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon]

That seems okay. Would be good to document in the security considerations.

On Fri, Mar 29, 2024 at 4:41 PM Eric Rescorla  wrote:

>
>
> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
> nore...@ietf.org> wrote:
>
>> Reviewer: Ted Lemon
>> Review result: Almost Ready
>>
>> This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01.
>>
>> Section 4.1 advises disabling fallback, but does not talk about DNSSEC,
>> which
>> is surprising given that the draft proposes privacy properties for SVCB
>> responses containing ECH data. I would think that it would make sense to
>> say
>> that the SVCB querier should attempt to validate the response, and then
>> talk
>> about what to do for bogus, insecure and valid positive and negative
>> responses.
>>
>> For example, I would think that a /bogus/ response should be taken to
>> mean that
>> the SVCB record must be assumed to exist and should be treated the same
>> as if
>> the list of destinations were not reachable. An /insecure/ NXDOMAIN or
>> NODATA
>> response would not provide this assurance, and so what is currently
>> described
>> in the document makes sense for this case. A /valid/ NXDOMAIN would
>> assure that
>> no SVCB record existed, and hence ECH is not available.
>>
>> I don't think it's reasonable to specify the privacy properties of SVCB
>> and
>> /not/ talk about DNSSEC validation.
>>
>
> I could see that there might be an objection that if DNSSEC isn't working
>> at a
>> particular site because of a broken DNS resolver, this would prevent
>> connecting
>> to perfectly acceptable destinations simply because of general DNSSEC
>> breakage,
>> not a specific attack on this specific domain. The problem is that
>> there's no
>> way to distinguish this from an attack. So if this exception is allowed,
>> the
>> security considerations section should talk about what the risks are of
>> allowing it. E.g. if we succeed in validing the root and com, but can't
>> validate the zone containing the SVCB (or determine that it's not
>> signed), that
>> would be a clear indication of an attack, but if we can't validate the
>> root, it
>> could just be brokenness, and an attacker would do well to just prevent
>> all
>> validation so that we can't distinguish.
>
>
> Thanks for your comments.
>
> While I agree that SVCB being bogus deserves some consideration. I don't
> think this
> resolutions is *quite* correct. In general, TLS and HTTP don't take a
> position
> on what if any DNSSEC validation is to be done or what to do in response to
> failures.
>
> The new angle here is that there are two queries, and so it is possible
> for the
> A/ queries to produce a valid response but the SVCB to produce a bogus
> one, which might be used by an attacker to disable ECH. What I would say
> here
> is that a bogus SVCB should be handled in the same way as if A/ were
> bogus.
> So if you would normally fail the resolution, you should do that, but if
> you would
> normally log and move on, then you should do that.
>
> -Ekr
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon via Datatracker]

Reviewer: Ted Lemon
Review result: Almost Ready

This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01.

Section 4.1 advises disabling fallback, but does not talk about DNSSEC, which
is surprising given that the draft proposes privacy properties for SVCB
responses containing ECH data. I would think that it would make sense to say
that the SVCB querier should attempt to validate the response, and then talk
about what to do for bogus, insecure and valid positive and negative responses.

For example, I would think that a /bogus/ response should be taken to mean that
the SVCB record must be assumed to exist and should be treated the same as if
the list of destinations were not reachable. An /insecure/ NXDOMAIN or NODATA
response would not provide this assurance, and so what is currently described
in the document makes sense for this case. A /valid/ NXDOMAIN would assure that
no SVCB record existed, and hence ECH is not available.

I don't think it's reasonable to specify the privacy properties of SVCB and
/not/ talk about DNSSEC validation.

I could see that there might be an objection that if DNSSEC isn't working at a
particular site because of a broken DNS resolver, this would prevent connecting
to perfectly acceptable destinations simply because of general DNSSEC breakage,
not a specific attack on this specific domain. The problem is that there's no
way to distinguish this from an attack. So if this exception is allowed, the
security considerations section should talk about what the risks are of
allowing it. E.g. if we succeed in validing the root and com, but can't
validate the zone containing the SVCB (or determine that it's not signed), that
would be a clear indication of an attack, but if we can't validate the root, it
could just be brokenness, and an attacker would do well to just prevent all
validation so that we can't distinguish.


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

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

[Ted Lemon]

On Dec 4, 2020, at 19:17, Nick Hilliard  wrote:
> people don't necessarily buy stuff that's not ungradeable.  They buy stuff 
> which has a support lifetime of finite duration.

Same thing. If you’re serious about business continuity, you have an 
arrangement with the vendor about what happens if they go out of business, and 
you have an agreement about how long support will last and what it consists of.

Of course no product has infinite lifetime, but lots of iot stuff is expected 
to be in the walls for 30 years. Radiology equipment lasts decades. Etc. 

It’s really natural to think of stuff you buy as being stable and solid, but 
when there’s software in it, this cognitive bias requires serious systems 
thinking to avoid. 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ted Lemon]

On Dec 4, 2020, at 5:29 PM, Ackermann, Michael  wrote:
> Regards to the 12 years vs 1-2.12 years is probably too long for just 
> about anything, once it is determined to be a business need.   But that is 
> the key first step.   Then it will likely be a minimum of 1-2 years to get 
> the identified need in the budget and then into planning cycles and actual 
> project plans.  For example, if you tell me to do a major conversion 
> right now,  it is tool late at this point for me to even request that for the 
> 2021 budget.I could request this in 2021, for the 2022 budget.   Hence 
> the typical minimum 1-2 years. 

But isn’t this the crux of the matter? How do we get to a place where when a 
new version of the protocol comes out, the planning starts? Should the IETF 
have deprecated TLS 1.1 in 2008? That would certainly have given you more lead 
time! I suspect there’s a happy medium.

Why do people buy stuff that’s not upgradeable? Probably because the 
manufacturer doesn’t give them a choice, and there’s no way to force the 
choice. The recent discussions about legally requiring firmware-upgradeable IoT 
devices (e.g. in Singapore) is definitely a step in the right direction. For 
medical devices and medical infrastructure, this should have been required, but 
as far as I know still is not.

I realize that this isn’t your specific problem, but it’s the one that really 
worries me.

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

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

[Ted Lemon]

On Dec 4, 2020, at 3:00 PM, Ackermann, Michael  wrote:
> 1. Enterprises do not expect nor want IETF to be responsible for their 
> planning for changes in technology.But when IETF decides to change 
> protocols or deprecate existing technology of any sort,  it would be 
> beneficial to all if our needs were considered and we were aware of related 
> developments, in an effective and timely fashion.   

So by this do you mean something like the ops doc Elliot just outlined? If so, 
we agree that this is at least in principle worth doing, although I don’t know 
if it’s practical.

> 2. No one at any enterprise I am aware even remotely thinks that IETF is 
> making changes to cause us or anyone else trouble.   Not even sure why you 
> would say this.The IETF is not as well understood by enterprises as many 
> of us would like,  but in no way is it considered a troublemaker, adversary 
> or any of the other things you say below that would make us seem at odds.   
> This area of understanding and communication is another area I hope we can 
> collectively improve, by getting enterprises more engaged,  in some fashion 
> or another.  

I think you misunderstood what I was saying.

> 3. No one I am aware of is saying do not deprecate protocols that are 
> obsolete..Not TLS or any others.We understand and recognize 
> this need and support it.My comments in this thread were in regards to 
> related timing and the realization that large organizations cannot always be 
> as nimble as most of us technicians would like.   And to a small degree I 
> described WHY most enterprises require more time for changes in many cases. 

This clarifies it a bit. TLS 1.1 was superseded by TLS 1.2 in 2008. This is the 
12 years. The process of moving to TLS 1.2 should have started at least when 
the TLS 1.2 RFC was published, if not before. Not necessarily installing 
software updates, but there should have been a rollout plan with at most a five 
year horizon at that point. Clearly there was not; this is what I’m saying 
needs to change. The time to start planning is not when the protocol is 
declared "obsolete, do not implement." You should have completed your rollout 
of the new protocol by this milestone, _at the very latest_.

> 4.  I don't think I or anyone else has said such changes will take 12 years 
> as you stated.   However, 1-2 is usually a base due to budget and planning 
> cycles at large orgs. 

That’s quite a bit more aggressive than I recall you being in the past, which 
is good.

> 5. I appreciate your advice on which vendors to deal with and how, but I do 
> not view this as a vendor issue and do not have any current issues with any 
> vendors on any related issues.But I do agree, as stated several times in 
> this Email chain,  that I would like to see enterprise requirements and 
> engagement much earlier on in IETF processes.You mention 12 years once 
> again referring to how late we are and I am again not sure where that comes 
> from, but I very much hope for earlier on involvement, in the future. 

What I mean by vendor involvement is that if you have devices that can’t be 
upgrade, that’s a planning failure. I don’t say that to point fingers, I’m just 
saying “next time, don’t buy products like that.” Maybe that’s not your issue, 
but it’s definitely an issue for hospitals, where much of their essential 
equipment runs Windows 7 or earlier and can’t be upgraded. Expensive equipment, 
where Windows is a tiny part of the delivered solution. This is disastrous.

> 6. Once again, in NO way am I or anyone else saying that the IETF should back 
> off and not say these protocols or any others are not obsolete, not 
> problematic or should not be deprecated. 
> 
> I hope the above makes sense and clarifies much of what I was trying to say.  
>IMHO we have taken this as far as we can or should on this list topic,  
> but hopefully improving enterprise and IETF communication/involvement 
> discussions can be continued on other lists or in other fashions, as has been 
> suggested by Barbara and Deborah.Assuming this occurs, and I hope it 
> does,  I hope you can be involved, as you are a greatly respected member of 
> the IETF community and could add a lot to that discussion.  

I think Elliot has probably done a better job of zeroing in on what you are 
asking for than anyone in this conversation. The one thing that I hear you 
saying that I still find problematic is that you think the timing of the 
deprecation is too soon. Am I correct in thinking that’s what I heard?

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

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

[Ted Lemon]

Michael, fundamentally the disconnect here seems to be that the IETF could ever 
be responsible for helping businesses to figure out how to plan for changes in 
technology _other_ than by doing work like this. Deprecating old versions of 
protocols is exactly what the IETF should be doing. This is how the signal 
burbles up through your vendors to you.

I think it’s useful for folks from enterprises to show up and pay attention to 
this, but it’s important to recognize that the reason we are making these 
changes is not to cause you trouble. It’s to try to help you to avoid trouble. 
If you come to the IETF with the goal in mind to get us to not deprecate 
protocols that are obsolete and have known attacks that the newer version of 
the protocol fixes, that’s just not the right model. We aren’t the adversary 
here. The IETF is not causing the protocol to be obsolete. The IETF is simply 
observing that the protocol is in fact obsolete, and it’s past time to stop 
using it. That is, we are observing a fait accompli over which we have no 
control.

The reason we do this is in the hope that you will do what you need to do to 
protect your customers from this fait accompli. The only thing that we could do 
differently is to not try to alert you to this problem.

When it takes twelve years for (some) enterprises to upgrade to the new version 
of a protocol, that’s an indication of some kind of systemic problem. It’s not 
a problem the IETF can solve. What I heard you saying at the beginning of this 
problem was that the IETF needed to understand your operational realities. But 
the implication is that we don’t understand your operational realities. That’s 
not what’s going on here. What’s going on here is that we simply can’t do 
anything about your operational realities.

The fact that we can’t do anything about them does not mean that TLS 1.1 
shouldn’t be deprecated. It just means that you, not the IETF, need to take the 
next step: now that we have told you TLS 1.1 is so obsolete that nobody should 
be using it anymore, you need to integrate that into your planning. You need to 
communicate with your vendors. You need to budget for whatever your plan of 
action is going to be. If you find yourself in an untenable situation because 
of this, you need to learn from that and change your planning methodology so 
that you aren’t caught up short next time a protocol needs to be obsoleted.

Don’t do business with vendors who do not have a plan for how to deal with this 
problem. Get it in the purchasing agreements. Get it in the service provider 
contracts. Begin planning your transition to the new protocol the day it’s 
published, or ideally as soon as you become aware that it’s going to be 
published. Don’t wait until we publish a document twelve years later saying 
that it’s now officially obsolete.

This is a very important problem, and I’m sorry if my previous note made it 
seem like I don’t take it seriously. I do. But it’s not a problem that the IETF 
can solve. If the IETF were to decide not to say that the protocol is obsolete, 
that wouldn’t solve it.  You have the problem whether we tell you you have the 
problem or not.

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

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

[Ted Lemon]

On Dec 2, 2020, at 1:51 PM, STARK, BARBARA H  wrote:
> The final version of this was published over a year ago (August 2019). The 
> first draft was in 2017.
> You said enterprises needed 1-2 years (or more) lead time. In the US, I think 
> they've had at least 3 years lead time, so far.

Actually, when we had this conversation in Prague in 2017 (admittedly, at the 
time we were talking about the TLS 1.3 transition), Michael mentioned that he’d 
been asking for extensions for PCI compliance in the transition to TLS 1.2. 
IIRC the requirements had been announced at least five years prior, although I 
don’t remember the precise details.

So the point is, this was something that any industry that processes credit 
cards has known about and had as a burning issue for much longer than 1-2 years.

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

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

[Ted Lemon]

On Dec 2, 2020, at 11:22 AM, Bill Frantz  wrote:
> One I think I can address are heart pacemakers. These are imbedded in the 
> patients chests. Upgrading them requires surgery. However, they have a 
> limited lifespan due to their batteries running down, I think we're talking 
> about 10 years or so, so there is a time where upgrade is practical.

This is a perfect example of reductio ad absurdum. Not that it’s a wrong 
example—for this use case, I think continued use of TLS 1.0 might be a 
requirement, if in fact there are pacemakers that use it. However, this is a 
situation where a subject matter expert skilled in the art should be designing 
a specific approach to the problem. It is not a case where no action should be 
taken—quite the opposite. It is quite likely that in this situation, 
operational practices could be undertaken that would limit the attack surface 
significantly.

The point is that you can’t argue with physics. If lives depend on winning that 
argument, you need to stop arguing and find a different approach to protecting 
those lives. If peoples’ personal privacy or financial privacy depends on them, 
perhaps this is a slightly less serious situation, but it’s still quite 
important. An enterprise that fails to plan for addressing these problems 
should be held liable for the damage that results from that failure. 

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

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

[Ted Lemon]

On Dec 2, 2020, at 11:00 AM, Ted Lemon  wrote:
> The situation right now is that it’s been known for a long time that RC4 and 
> MD5 are not safe to use. Your vendors have known about this for a long time. 
> If they do not have a roll-out plan for software that corrects the problem, 
> you have chosen the wrong vendors. Look at your agreements with them. Are 
> they honoring them? If not, you have recourse. If you didn’t contract with 
> them to anticipate change, it’s time to go fix that.

Sorry, I was talking about the wrong document. But the point is the same. If 
you are using TLS 1.0 or TLS 1.1, your vendors should long since have offered 
you an upgrade path. If they haven’t, you chose the wrong vendors. Get to work 
on fixing that now, rather than complaining to us. A failure to plan on your 
part does not constitute an emergency on our part.


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

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

[Ted Lemon]

On Dec 2, 2020, at 9:58 AM, Ackermann, Michael  wrote:
> As an Enterprise person I can say we are not well equipped to be aware of nor 
> react "Nimbly" to changes such as this.  Wide scope and security related 
> changes can require major changes to core Business systems.  This can mean 
> significant time, effort and/or $$$. 
> The biggest barrier is that this topic is not currently on the Planning or 
> Budget radar at all, and usually takes 1-2 years (or more) to achieve either. 
> 
> On one side of such issues, I don't think IETF understands the above and on 
> the other side Enterprises are unaware of developments at IETF and other 
> SDO's.Bridging that important gap is not unique to this topic. 

It’s important not to catastrophize this. The IETF understands perfectly well 
how this process works. We write and publish RFCs, and industry (we hope!) 
follows. It’s a pipeline: an event happens in the IETF, it trickles out through 
your service providers and network product vendors, and ultimately, at some 
time usually quite long after the RFC is published, you have to take action.

The situation right now is that it’s been known for a long time that RC4 and 
MD5 are not safe to use. Your vendors have known about this for a long time. If 
they do not have a roll-out plan for software that corrects the problem, you 
have chosen the wrong vendors. Look at your agreements with them. Are they 
honoring them? If not, you have recourse. If you didn’t contract with them to 
anticipate change, it’s time to go fix that.

Stop pretending that we live in a world where we can ignore advances in 
technology. We don’t. If your current plans don’t assume that every bit of tech 
gear you have in every rack in every machine room and every hospital room will 
have to be upgraded at least every five years or so, hopefully in software, 
then change your plans now. Stop arguing with us and go do that.

Because even if browser vendors don’t follow this change quickly, you can be 
sure that malware writers will. Hospital after hospital keeps getting taken 
down with the same malware. Lives are on the line. People have died because of 
this.

You should be working to fix that, not trying to get us to stop asking you to 
fix it.

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

Re: [TLS] Intdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Ted Lemon]

FWIW my nit was simply that algorithms aren’t getting weaker: attacks are 
getting stronger. Sorry if I worded the suggested text badly. 

> On Nov 1, 2020, at 13:09, Benjamin Kaduk  wrote:
> 
> Hi Ted,
> 
> Thanks for the review, especially for thinking about the point that Éric
> requested.
> 
> I don't really agree with your nit, though, as there have been improved
> crypanalysis and correspondingly improved cryptographic attacks on both
> algorithms over time (SHA1 more recently than MD5).  Increased
> computational power to take advantage of those cryptographic weaknesses is
> certainly a factor in moving to deprecate the vulnerable algorithms, but it
> is not the only factor.
> 
> -Ben
> 
>> On Wed, Oct 28, 2020 at 08:56:13AM -0700, Ted Lemon via Datatracker wrote:
>> Reviewer: Ted Lemon
>> Review result: Ready with Nits
>> 
>> This document is ready for publication, with one minor nit, which is included
>> at the end.
>> 
>> Éric additionally made the following request:
>>  As those hash algorithms were 'cheap' for TLS, I would appreciate a review 
>> of
>>  the impact if those algorithms are deprecated in TLS 1.2.
>> 
>> I am not in a position to do any practical tests, but I will point out 
>> several
>> things. First, deprecating MD5 is not going to cause a performance problem
>> because it's slower than SHA1, so we really only need to worry about whether
>> deprecating SHA1 will cause a problem. This document only deprecates SHA1 for
>> use in digital signatures. It "does not deprecate SHA-1 in HMAC for record
>> protection." Given the way TLS uses digital signatures, this should not be a
>> serious concern. At worst case, SHA256 is about 24% slower than SHA1. Best 
>> case
>> (shorter text) it is less than 16% slower. It's reasonable to expect that in
>> common use in TLS, the texts being digested will be shorter, not longer.
>> Further, the bulk of the computational burden of TLS is not in the generation
>> of digests for digital signatures. Therefore it seems reasonable to expect 
>> that
>> the performance impact of this change is vastly overshadowed by one of the 
>> very
>> factors that motivates it: the increased speed of hash computation over 
>> time. 
>> Even assuming constant speed legacy hardware, the performance impact is not
>> sufficient to cause concern when considering it as part of the total system
>> that would be using TLS 1.2.
>> 
>> Nit:
>> 
>> In the abstract:
>>   The MD5 and SHA-1 hashing algorithms are steadily weakening in
>>   strength and their deprecation process should begin for their use in
>>   TLS 1.2 digital signatures.
>> 
>> Technically, the strength of these algorithms hasn't changed. What's changed 
>> is
>> that their strength is no longer sufficient to prevent realistic attacks. So 
>> it
>> might be better to say something like "The vulnerability of MD5 and SHA-1
>> algorithms to practical attacks is steadly increasing and ..."
>> 
>> 
>> 

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

[TLS] Intdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Ted Lemon via Datatracker]

Reviewer: Ted Lemon
Review result: Ready with Nits

This document is ready for publication, with one minor nit, which is included
at the end.

Éric additionally made the following request:
  As those hash algorithms were 'cheap' for TLS, I would appreciate a review of
  the impact if those algorithms are deprecated in TLS 1.2.

I am not in a position to do any practical tests, but I will point out several
things. First, deprecating MD5 is not going to cause a performance problem
because it's slower than SHA1, so we really only need to worry about whether
deprecating SHA1 will cause a problem. This document only deprecates SHA1 for
use in digital signatures. It "does not deprecate SHA-1 in HMAC for record
protection." Given the way TLS uses digital signatures, this should not be a
serious concern. At worst case, SHA256 is about 24% slower than SHA1. Best case
(shorter text) it is less than 16% slower. It's reasonable to expect that in
common use in TLS, the texts being digested will be shorter, not longer.
Further, the bulk of the computational burden of TLS is not in the generation
of digests for digital signatures. Therefore it seems reasonable to expect that
the performance impact of this change is vastly overshadowed by one of the very
factors that motivates it: the increased speed of hash computation over time. 
Even assuming constant speed legacy hardware, the performance impact is not
sufficient to cause concern when considering it as part of the total system
that would be using TLS 1.2.

Nit:

In the abstract:
   The MD5 and SHA-1 hashing algorithms are steadily weakening in
   strength and their deprecation process should begin for their use in
   TLS 1.2 digital signatures.

Technically, the strength of these algorithms hasn't changed. What's changed is
that their strength is no longer sufficient to prevent realistic attacks. So it
might be better to say something like "The vulnerability of MD5 and SHA-1
algorithms to practical attacks is steadly increasing and ..."



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

Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS

[Ted Lemon]

Can you provide a citation for that statement?   Not doubting you,
particularly, but this is news to me, and probably to some others on this
list, if true.

On Tue, Oct 16, 2018 at 4:01 PM Rene 'Renne' Bartsch, B.Sc. Informatics
 wrote:

> Unjust certificates can be bought for 150,- $ in the darknet which makes
> TLS snake-oil. And you never know if the internet provider is hostile or
> hacked.
> So we should act in the favor of end-users. If we don't have the position
> to make DANE mandatory, yet, we should at least try to encourage browser
> vendors
> to support DANE. Just think about all the online-banking websites without
> DNSSEC/DANE protection.
>
>
> Am 15.10.18 um 22:49 schrieb Viktor Dukhovni:
> > Though I am generally an advocate for DANE, and have done much work to
> > further its adoption, this is not a realistic proposal.  DANE adoption
> > in TLS will be incremental and will not be accomplished via a mandate.
> >
> >> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics
>  wrote:
> >>
> >> TLS is prone to Man-In-The-Middle attacks with unjustly obtained
> intermediate certificates (e.g. firewall appliances).
> >> The DNSSEC KSK-rollover worked like a charm.
> >>
> >> So I suggest to make DANE-TLS mandatory for TLS to prevent
> Man-In-The-Middle attacks with unjustly obtained intermediate certificates.
> >
> > If you want to see more DANE deployment, work on tooling to ease
> > DNSSEC deployment, convince registries to support CDS and CDS0,
> > simplify zone signing and key rollover interfaces in nameserver
> > implementations, develop monitoring tools, ...  Get efforts to
> > improve the tools funded, ...
> >
> > There is much work to be done, before we can expect ubiquitous
> > DNSSEC support, let alone DANE.  DNSSEC deployment is concentrated
> > at domains hosted by providers who have invested in automating it.
> > To bring it to the masses, it must be something that works out of
> > the box.
> >
> > Until then it should be possible to use DNSSEC and DANE with TLS,
> > but we're quite far from being in a position to mandate their use.
> >
>
> ___
> 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] Make DANE-TLS (RFC 6698) mandatory for TLS

[Ted Lemon]

Not an argument in favor of the proposal, but the issue with firewall certs
is not that we would want to override local security policy, but that
firewall certs *can* in principle override local security policy, and in
principle DANE could be used to prevent that.   What is meant by a firewall
cert is a cert that's able to sign for any domain; such certs can in
principle be obtained by entities other than the operator of the local
firewall.   We're calling them firewall certs because that's the ostensible
reason for their existence, but we shouldn't assume that the name has any
power to restrict how they are used. :)

On Tue, Oct 16, 2018 at 3:45 AM Ryan Sleevi  wrote:

>
>
> On Mon, Oct 15, 2018 at 4:50 PM Viktor Dukhovni 
> wrote:
>
>> Though I am generally an advocate for DANE, and have done much work to
>> further its adoption, this is not a realistic proposal.  DANE adoption
>> in TLS will be incremental and will not be accomplished via a mandate.
>>
>> > On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics
>>  wrote:
>> >
>> > TLS is prone to Man-In-The-Middle attacks with unjustly obtained
>> intermediate certificates (e.g. firewall appliances).
>> > The DNSSEC KSK-rollover worked like a charm.
>> >
>> > So I suggest to make DANE-TLS mandatory for TLS to prevent
>> Man-In-The-Middle attacks with unjustly obtained intermediate certificates.
>>
>
> I think there's another criticism to be leveled at this proposal, and it's
> suitability for this WG - the motivation stated (firewall appliances) is a
> question about local policy. I admit my own ignorance here, in that I'm not
> sure how https://tools.ietf.org/html/draft-nottingham-for-the-users has
> been progressing as a comparable alternative to the HTML Priority of
> Constituencies. However, as engineers, we need to recognize that no matter
> what is memorialized by the IETF, if you have control over the machine - as
> these enterprises inevitably do to install their firewall appliance - all
> bets are off. We should not pretend we will prevent that, nor should we
> increase costs for the ecosystem in pursuit of that effort.
> ___
> 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] EXTERNAL: Re: integrity only ciphersuites

[Ted Lemon]

What kind of bandwidth are we talking about here?   Also, could you answer
my question about IPsec?

On Tue, Aug 21, 2018 at 1:53 PM, Jack Visoky 
wrote:

> Hi Ted,
>
>
>
> A few points:
>
>
>
> 1.   Don’t assume there is any browser involved.  There is often no
> browser.
>
> 2.   Even if there is a browser (and see point 1 before assuming) any
> HTTP communication would be at a much much slower rate than machine to
> machine I/O
>
>
>
> Hope that clears it up.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* Ted Lemon [mailto:mel...@fugue.com]
> *Sent:* Tuesday, August 21, 2018 1:39 PM
> *To:* Jack Visoky 
> *Cc:* Salz, Rich ; Fries, Steffen <
> steffen.fr...@siemens.com>; ncamwing=40cisco@dmarc.ietf.org;
> tls@ietf.org
> *Subject:* Re: [TLS] EXTERNAL: Re: integrity only ciphersuites
>
>
>
> If the device implements the cipher so as to talk to the browser, it's
> clearly capable of implementing the cipher...
>
>
>
> On Tue, Aug 21, 2018 at 1:34 PM, Jack Visoky 
> wrote:
>
> Hi Rich,
>
>
>
> I’m not sure if I’m following the question, but what was meant was that
> these ciphers are generally NOT used for browser access.  Machine to
> machine communication usually does not involve a browser.  Apologies if
> I’ve misunderstood the question.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Salz, Rich
> *Sent:* Tuesday, August 21, 2018 1:12 PM
> *To:* Fries, Steffen 
> *Cc:* ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
> *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites
>
>
>
> [Use caution with links & attachments]
>
>
>
> Now I think I am as confused as Stephen and others.
>
>
>
> One justification was “small footprint.”  But now you’re saying that for
> debugging encryption (standard?) ciphers are used for browser access?
>
>
>
>
> ___
> 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] EXTERNAL: Re: integrity only ciphersuites

[Ted Lemon]

If the device implements the cipher so as to talk to the browser, it's
clearly capable of implementing the cipher...

On Tue, Aug 21, 2018 at 1:34 PM, Jack Visoky 
wrote:

> Hi Rich,
>
>
>
> I’m not sure if I’m following the question, but what was meant was that
> these ciphers are generally NOT used for browser access.  Machine to
> machine communication usually does not involve a browser.  Apologies if
> I’ve misunderstood the question.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Salz, Rich
> *Sent:* Tuesday, August 21, 2018 1:12 PM
> *To:* Fries, Steffen 
> *Cc:* ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
> *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites
>
>
>
> [Use caution with links & attachments]
>
>
>
> Now I think I am as confused as Stephen and others.
>
>
>
> One justification was “small footprint.”  But now you’re saying that for
> debugging encryption (standard?) ciphers are used for browser access?
>
>
>
> ___
> 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] EXTERNAL: Re: integrity only ciphersuites

[Ted Lemon]

So rather than upgrading to TLS 1.3, why not just upgrade to IPsec?
 You're going to have to change what you do anyway—rather than arguing with
us why not bypass us entirely?

On Tue, Aug 21, 2018 at 1:06 PM, Jack Visoky 
wrote:

> Just to pile on what Steffen is saying, the motivation for this is mainly
> around device communication that happens at high speeds (sub millisecond is
> not uncommon for an update rate).  The communications is generally not
> HTTP, but rather industrial protocols built on TCP and UDP.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Fries, Steffen
> *Sent:* Tuesday, August 21, 2018 12:54 PM
> *To:* Salz, Rich 
> *Cc:* ncamwing=40cisco@dmarc.ietf.org; tls@ietf.org
> *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites
>
>
>
> [Use caution with links & attachments]
>
>
>
>
>
> On 21. Aug 2018, at 18:13, Salz, Rich  wrote:
>
> ?  If there would be support for integrity ciphers in TLS 1.3 it would
> enable the straight forward switch from TLS 1.2 also in these environments
> by keeping existing monitoring options.
>
>
>
> Why do you want to move to TLS 1.3?  Why isn’t your existing solution good
> enough?
>
>
>
> ?  [stf] Currently it is sufficient to use TLS 1.2- For certain use cases
> the utilized components have a rather long lifetime. One assumption is that
> TLS 1.3 will exist longer that TLS 1.2 and that certain software tools
> (also browsers) may not support TLS 1.2 in the future  …
>
>
>
> Most browsers already do not support NULL encryption, and it is highly
> unlikely that any will add it for 1.3.  Have you any indication otherwise?
> If you’re not going to use the algorithms in general use on the public
> Internet, then you should expect that standard clients such as browsers,
> will not work.  PeterG can attest to this. :)
>
>
>
> True. I was more referring to an embedded device, which currently supports
> TLS 1.2 (for using integrity only) for machine to machine communication  If
> this device is accessed by a service technician, it will also use today
> cipher suites with encryption. If a browser provider decides to deprecate
> TLS 1.2 in the future, access by standard software would be hindered. This
> would end up in a device supporting TLS 1.3 for service technicians access
> and 1.2 for machine to machine communication to (still) have integrity
> only.
>
> ___
> 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] EXTERNAL: Re: integrity only ciphersuites

[Ted Lemon]

I asked you if you have any specific devices for which this is an issue.
 Do you?   How did you determine that it was an issue?   Do you have A/B
testing results on power consumption and/or performance of a null cipher
suite versus encryption?

On Tue, Aug 21, 2018 at 11:20 AM, Jack Visoky 
wrote:

> Hi Ted,
>
>
>
> My apologies for being opaque.  There are many different
> device/applications/installations so I am sorry if I am mixing ideas
> here.  Generally the NULL ciphers have the benefit around allowing higher
> performance for devices that are lower horsepower.  Code space can
> certainly be a concern, but I think for industrial applications it’s more
> around throughput of high speed I/O, combined with the use cases that
> derive little benefit from the confidentiality of this data.  “Horsepower”
> is of course a vague term in of itself, so here I’m talking about things
> that would impact packet processing; this includes processor speed,
> available high speed RAM, presence of/lack of crypto acceleration (not in
> many Industrial Ethernet devices but growing).  I wouldn’t put the
> executable code size as high on the list of concerns as these items,
> although there are certainly devices that are limited in this.  This
> horsepower limitation is directly related to the fact that these devices
> are expected to function for many years.
>
>
>
> I’m happy to clarify any of these points further if needed.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* Ted Lemon [mailto:mel...@fugue.com]
> *Sent:* Tuesday, August 21, 2018 10:58 AM
> *To:* Jack Visoky 
> *Cc:* Andreas Walz ; tls@ietf.org; ncamwing=
> 40cisco@dmarc.ietf.org
> *Subject:* Re: [TLS] EXTERNAL: Re: integrity only ciphersuites
>
>
>
> Thanks, Jack, but could you respond to the specific questions that we
> asked you?   Earlier you were saying that your motivation for using NULL
> ciphers was that you had specific hardware that couldn't implement
> encryption due to lack of horsepower or memory.   Now you seem to be saying
> something completely different.   It's going to be difficult for us to
> understand your requirements if you talk about different things in each
> message.
>
>
>
> On Tue, Aug 21, 2018 at 10:27 AM, Jack Visoky 
> wrote:
>
> (I’m responding  a few different points made here)
>
>
>
> In general, although this seems like a niche application, there are
> actually millions of Industrial Ethernet nodes, with the numbers trending
> upward.  As mentioned, many of these are relying on older protocols
> designed without security in mind.  Our industry has had a debate around
> using TLS vs. creating something specific.  Many of us prefer to rely on
> the security benefits of TLS.  To another point, although I work for
> Rockwell Automation, here I am working in my capacity within ODVA, a
> standards group for Industrial Communications that has several large
> vendors as members.  We have adopted TLS to protect our industrial Ethernet
> traffic, and one of the selling points of TLS 1.2 was the ability to use
> NULL encryption.
>
>
>
> NULL encryption is not really as much about code size but capability of
> the devices.  The TLS handshake of course contains some “heavyweight”
> operations, although handshakes are pretty infrequent as these connections
> are often quite long-lived.  Once the handshake is over, the I/O data that
> is transferred is often quite sensitive to latency, and although the
> encryption overhead might not seem like much when the HMAC is considered,
> it is still a case where in many applications every bit counts.  Regarding
> older hardware that exists for many years, some hardware does have
> cryptographic acceleration although may not have AES-GCM, rather SHA-256
> HMAC.  Alternatively, the hardware might not have any crypto acceleration
> as it was designed without TLS in mind.  At the same time we’d like to
> secure this traffic via a firmware upgrade.  Despite this, if using
> encryption drops performance enough users will simply not use it, which is
> a net worse outcome.  Users will likely not upgrade hardware for many years
> due to a variety of industry factors.
>
>
>
> Kathleen’s comment about defining NULL encryption but being clear about
> the risks resonates with me.  I’m certainly not suggesting that NULL
> encryption is needed in all cases, but there are times (as discussed here
> and in the RFC draft) where it could be quite beneficial.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Andreas Walz
> *Sent:* Tuesday, August 21, 2018 9:37 AM
> *To:* tls@ietf.org
> *Cc:* ncamw

Re: [TLS] integrity only ciphersuites

[Ted Lemon]

This is a situation where there is a clear alternative: use IPsec.   IPsec
is ideal for the problem space you are in.   TLS is actually really not
ideal.   You are trying to cram a round peg into a square hole.

On Tue, Aug 21, 2018 at 12:00 PM, Fries, Steffen 
wrote:

>
>
>
>
> Ø  If there would be support for integrity ciphers in TLS 1.3 it would
> enable the straight forward switch from TLS 1.2 also in these environments
> by keeping existing monitoring options.
>
>
>
> Why do you want to move to TLS 1.3?  Why isn’t your existing solution good
> enough?
>
> [stf] Currently it is sufficient to use TLS 1.2- For certain use cases the
> utilized components have a rather long lifetime. One assumption is that TLS
> 1.3 will exist longer that TLS 1.2 and that certain software tools (also
> browsers) may not support TLS 1.2 in the future (I know there is currently
> not intention for a deprecation of 1.2, but if a component is in the field
> for 20 years, it may become more likely). Having the option to also support
> TLS 1.3 on such devices now, may ensure that there are accessible by
> standard software also in the more distant future.
>
> ___
> 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] EXTERNAL: Re: integrity only ciphersuites

[Ted Lemon]

Thanks, Jack, but could you respond to the specific questions that we asked
you?   Earlier you were saying that your motivation for using NULL ciphers
was that you had specific hardware that couldn't implement encryption due
to lack of horsepower or memory.   Now you seem to be saying something
completely different.   It's going to be difficult for us to understand
your requirements if you talk about different things in each message.

On Tue, Aug 21, 2018 at 10:27 AM, Jack Visoky 
wrote:

> (I’m responding  a few different points made here)
>
>
>
> In general, although this seems like a niche application, there are
> actually millions of Industrial Ethernet nodes, with the numbers trending
> upward.  As mentioned, many of these are relying on older protocols
> designed without security in mind.  Our industry has had a debate around
> using TLS vs. creating something specific.  Many of us prefer to rely on
> the security benefits of TLS.  To another point, although I work for
> Rockwell Automation, here I am working in my capacity within ODVA, a
> standards group for Industrial Communications that has several large
> vendors as members.  We have adopted TLS to protect our industrial Ethernet
> traffic, and one of the selling points of TLS 1.2 was the ability to use
> NULL encryption.
>
>
>
> NULL encryption is not really as much about code size but capability of
> the devices.  The TLS handshake of course contains some “heavyweight”
> operations, although handshakes are pretty infrequent as these connections
> are often quite long-lived.  Once the handshake is over, the I/O data that
> is transferred is often quite sensitive to latency, and although the
> encryption overhead might not seem like much when the HMAC is considered,
> it is still a case where in many applications every bit counts.  Regarding
> older hardware that exists for many years, some hardware does have
> cryptographic acceleration although may not have AES-GCM, rather SHA-256
> HMAC.  Alternatively, the hardware might not have any crypto acceleration
> as it was designed without TLS in mind.  At the same time we’d like to
> secure this traffic via a firmware upgrade.  Despite this, if using
> encryption drops performance enough users will simply not use it, which is
> a net worse outcome.  Users will likely not upgrade hardware for many years
> due to a variety of industry factors.
>
>
>
> Kathleen’s comment about defining NULL encryption but being clear about
> the risks resonates with me.  I’m certainly not suggesting that NULL
> encryption is needed in all cases, but there are times (as discussed here
> and in the RFC draft) where it could be quite beneficial.
>
>
>
> Thanks and Best Regards,
>
>
>
> --Jack
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Andreas Walz
> *Sent:* Tuesday, August 21, 2018 9:37 AM
> *To:* tls@ietf.org
> *Cc:* ncamwing=40cisco@dmarc.ietf.org
> *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites
>
>
>
> [Use caution with links & attachments]
>
>
>
> +1
>
> I fully understand the pursuit of minimizing complexity in TLS. However,
> banning from TLS all provisions to serve non-internet cases seems
> suboptimal to me.
>
> I think there is a whole universe of systems and applications that are
> just at the very beginning of being armed with security features: think of
> communication systems driving, e.g., industrial automation and critical
> infrastructures. These are quite different from the internet and the web
> (different threats, security requirements, architectures, networks,
> resources, etc.). Still, IMHO it's not a niche at all; it's just not as
> visible to most of us.
>
> I strongly believe it is *not* a good idea to hold back all the valuable
> experience condensed in TLS and entail the design of customized security
> protocols for such systems. TLS is state-of-the-art and its benefits should
> be accessible to as many systems as possible.
>
>
>
> Cheers,
> Andi Walz
>
>
>
>
> >>> Kathleen Moriarty  08/21/18 3:20 PM
> >>>
>
>
> Sent from my mobile device
>
> > On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
> >
> > "Vulnerable-by-design ciphersuites"? Vulnerable to what?
> >
> > Suck sites are designed to provide end-point authentication and traffic
> integrity. Care to explain/show how these properties would not hold?
> >
> > Besides, it's been explained several times that some use cases do not
> require confidentiality, and in some use cases confidentiality is forbidden.
>
> I agree with Uri here, flexibility to cover these use cases to accommodate
> the actual security requirements may result in them using something instead
> of nothing. It could be defined and not listed as Recommended as well. This
> comes down to risk management and options, where the risk can be clearly
> explained and the lack of recommendation can also be explained.
>
> Best regards,
> Kathleen
>
> >
> > Regards,
> > Uri
> >
> > Sent from my iPhone
> >
> >> O

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

[Ted Lemon]

On Mon, Aug 20, 2018 at 5:36 PM, Jack Visoky 
wrote:

> 2. In some cases the code size is quite important.  It’s not uncommon for
> hardware to be in the field in Industrial Automation for 15 or more years,
> so in some cases the hardware is already stretched pretty thin and might
> not be able to handle the demands of encryption.  At the same time it is
> hugely beneficial to take advantage of the security of TLS for many of
> these installations.
>

Given that you work for Rockwell, I'm assuming that you have specific
devices in mind, that these devices are already in the field, and that you
intend to upgrade their firmware to support CORE or something like that.
 Is this the use case you're talking about?


> 3. Another use case for these NULL encryption suites is around inspection
> of data.  I think this has been discussed in this forum already, but these
> cipher suites could support that as well.
>

I would really encourage you to take a look at MUD (Manufacturer Usage
Description)  as a
way to configure these devices.   I presume that the use case here is that
you have a device that could be pwned, and you want to be able to see what
it is sending.   But really it shouldn't even be having the conversation,
right?   MUD lets you configure your firewall automatically, preventing the
device, if it's pwned, from talking to the controlling botnet.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Doubts about a solution or new service/protocol

[Ted Lemon]

Why do you need to extend tls to do this?  Why not just use it for
encapsulation?  What you are describing sounds more like pgp than tls.

On Mon, Jul 16, 2018 at 12:15 PM Walter Neto 
wrote:

> Hi IETF tls list,
>
> I have some problem to solve I believe it is good to make my questions and
> proposals here.
>
> I'm from Brazil, here we need to use X.509 certificates to sign electronic
> invoices XMLs and to communicate this XMLs through https.
>
> The problem is that the most of emitters pass their certificates (with
> private
> and public keys) to the software companies that communicate this invoices,
> what
> in my point of view it is so insecure, the other problem is that generate a
> certificate to the software company authorized to emmit the invoice is so
> bureaucratic.
>
> My proposal is to create a service that generates tokens to third
> applications
> use this service to sign, and encrypt data without the certificate, and
> introduce an option in the tls protocol to pass the token and the service
> address to use it when don't have local cert files.
>
> Does it make sense?
>
> --
> Walter Neto
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

[Ted Lemon]

I have no pony in this race, but FWIW ~5 people on each side represents a
lack of consensus.   A lack of consensus means that the work doesn't happen
in the working group.

Thomas, your response (sorry to pick on you!) illustrates another consensus
issue: consensus exists when all technical objections have been addressed.
  Melinda made a pretty serious technical objection.  Your response is not
responsive to her objection.   She explicitly said that her objection was
not the two bytes.   So from the perspective of consensus, it's as if you
hadn't sent an email message—an accurate evaluation of consensus would not
take what you said into account at all.

On Wed, May 16, 2018 at 7:32 AM, Thomas Lund 
wrote:

> FWIW: I support the changes proposed by Viktor and others. In particular, I
> support reserving 2 bytes for which the semantics will be defined in a
> separate draft.
> For me, the advantages of this proposal outweighs the disadvantage of
> having to reserve 2 bytes that might, in worst case, never get used.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

My responses for today are all in this message, including a response to Ralph.  
I'm going to try not to engage on this again until tomorrow.

On Mar 14, 2018, at 6:52 PM, nalini elkins  wrote:
> 1.  Multiple standards are likely to diverge.

We don't need multiple standards, so this isn't an issue.   What you need is to 
define the behavior that you need from your TLS implementation to give you the 
visibility that you want.

> 2.  The TLS WG of the IETF has many of the world's experts in defining such 
> protocols.  The years of collective expertise is remarkable.   We want to 
> work with the TLS group not try to recreate it.

Of course, it would be ideal for you if you could get the TLS working group to 
do this work for you.

> 3.   The reason I support the enterprises and their voice in TLS is because I 
> am naive enough to actually believe in the IETF.  I believe that technical 
> truth matters.  That it is not actually the Vendor Engineering Task Force.  
> That is a group of the vendors, by the vendors and for the vendors.   I could 
> see when this whole thing with taking away RSA was happening that correct 
> though it may be, it was going to cause enormous disruption for many, many 
> people in the commercial world.  You may not believe it, but I am actually 
> doing this because I really believe that we need one set of standards that 
> everyone can use.  I want it to be in the TLS WG.  I want the TLS WG to be 
> credible and succeed and I want the IETF to succeed.  I believe that the 
> Internet needs it.

The problem isn't that we don't believe that it will involve significant work 
for you to secure your customer's data.

> 4.  Again, believe it or not, the TLS WG needs the enterprises.  Of course, 
> this is all my opinion only.   These enterprises are a huge group of users of 
> the IETF protocols and TLS in particular.   The feedback of users is 
> irreplaceable.  Who are we building the protocols for if not the users?  
> Sure, there are multiple sets, but these are a very large group.  

This is the crux of the question: who are the users whose needs the TLS working 
group is serving?   Any discussion that doesn't begin by answering this 
question is going to be non-terminal.   I believe it's your position that the 
"user" is the large corporation; an alternate view, which appears to be shared 
by quite a few participants here, is that the user is the end user: the person 
who, if their data security is compromised, will wind up bearing the cost of 
that compromise.

> Enterprises value security and privacy.   They have a different job to do.  
> What they are trying to do is to protect against leakage of data, do fraud 
> monitoring, protect against malware and many other things.   When this gets 
> into the medical arena, it can even be lives.  I don't even see how you can 
> say what you are saying.

None of these applications require changes to TLS 1.3.   If you think they do, 
you need to walk us through your reasoning.  The reason we can say what we are 
saying is that we understand that none of what you have mentioned here requires 
that TLS 1.3 be weakened.

> But, it is a very difficult issue.   If I can use a different analogy, if the 
> City of Monterey built a new sewer system and told me that to connect to it, 
> I had to build a new house, I would scream!

That's a great analogy, but we are talking about software, not houses.   There 
is no technical reason why switching to TLS 1.3 requires you to build a new 
house.   It does require you to update your software, and there is no doubt a 
real cost to that.  There may even be software that you will have to stop 
using.  But any software that you would have to stop using is software you 
already should not be using, because it's not supported.

> I would not agree with that.  People understand that sometimes they have to 
> pay when there are protocol and other changes.  It is a question of if you 
> could do everything that you needed to do to protect your customers even if 
> you re-built your network from the ground up.

I don't think there's any question that if you rebuilt your network from the 
ground up, you could use TLS 1.3.   If you think this is not the case, it would 
help if you could say what precisely stands in the way.

On Mar 14, 2018, at 10:32 PM, Ralph Droms  wrote:
> And there is a name for this sort of labeling - it's called an "ad hominem 
> attack".  I don't believe anyone is employing "consensus by exhaustion".  
> Please don't attach unwarranted labels to honest attempts to explain 
> requirements and develop solutions.

Ralph, the problem is not that these attempts to explain requirements are not 
honest.  It is that until we agree on who we are protecting, talking about 
requirements doesn't really help: the requirements of people who are not our 
priority are interesting, but not important.

And because we are discussing requirements before we have agreed as to whether 
or not it is okay to weak

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

Perhaps this would be a good time to put in a plug for additional funding
for openssl et al...

On Mar 14, 2018 14:53, "Russ Housley"  wrote:

>
> > On Mar 14, 2018, at 8:39 AM, Hubert Kario  wrote:
> >
> > On Tuesday, 13 March 2018 23:16:47 CET Russ Housley wrote:
> >> Ted:
> >>> There's an easy way to do this, although as a sometime bank security
> geek
> >>> I would strongly advise you to not do it: keep using TLS 1.2.
> >> This is a bogus argument.  First, staying with an old protocol version
> often
> >> leads to locking in unmaintained versions of old software.
> >
> > this is simply not true, the newest versions of OpenSSL, NSS, GnuTLS and
> > schannel allow you to disable TLS 1.2 and TLS 1.1 protocol support to
> > effectively only support TLS 1.0!
>
> After TLS 1.3 is approved, I have heard a desire from software maintainers
> to drop support for some of the older versions over time. Support for SSL
> 3.0 has been dropped in some cases, and for good reasons.
>
> Russ
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

On Mar 13, 2018, at 11:49 PM, Russ Housley  wrote:
> I was trying to separate these two cases.  If the TLS session is terminated 
> at a load balancer, then the client within the load balancer is (as Ted says) 
> under control of the operator.  The operator can include any extensions that 
> it wishes.  If the TLS session is not terminated at a load balancer, then the 
> client needs to opt-in for decryption points in the enterprise data center to 
> get the needed keying material.

I had thought that we had agreement in Prague that this proposal did not 
require special browsers to be widely available in the wild.   If it does, that 
seems like a mildly stronger argument against it, since if the requirement for 
this behavior successfully infects browsers in the wild, the damage done will 
be to connections in addition to the ones that you are trying to wiretap.

Is there still confusion on the question of whether click-through warnings can 
ever be part of an effective user interface design?

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

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

[Ted Lemon]

On Mar 14, 2018, at 5:01 AM, Stephen Farrell  wrote:
>> I hum in the meeting is a meaningful way to find out what the
>> quiet people are thinking.
> 
> And of course also any people who try pack out the room for any
> reason;-(

As long as the hum is treated as Pete describes in RFC 7282, this shouldn't be 
an issue.   However, I tend to agree with you that we won't learn anything new 
by doing this.  Do we really think that there are people who will hum in favor 
of this who haven't thus far been willing to say why?

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

On Mar 13, 2018, at 6:16 PM, Russ Housley  wrote:
> This is a bogus argument.

I'm pretty sure there's a Monty Python skit about this, so I won't belabor the 
point.

> First, staying with an old protocol version often leads to locking in 
> unmaintained versions of old software.

Right, that's one of the stated goals of this work: to be able to continue to 
use software that the operator can't upgrade.

> Second, using TLS1.2 does not technically address the issue.  If the client 
> were to exclusively offer DHE-based ciphersuites, then the visibility 
> techniques that have been used in the past are thwarted.

The client in this case is under the control of the operator, so this is a 
non-issue.

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

On Mar 13, 2018, at 6:22 PM, Stephen Farrell  wrote:
> I mean, do you *really* think there's any chance of reaching rough
> consensus on the list for this draft? If not, then ISTM you're
> putting meeting attendees and list participants through a bunch
> of pain for no gain.

It's actually worse than that—it costs us time to do this, and those of us who 
are not given free money to work on stuff like this have to choose between 
billing for work our employers want us to do, or participating in conversations 
like this.  Today this has cost me several billable hours.   When the working 
group is allowed to continue discussing issues like this that are never going 
to get consensus, ad infinitum, we have to choose between participating in the 
discussion, which is just a rehash of the previous discussion, or doing work we 
can get paid for.

One strategy that's very effective for overcoming resistance to bad ideas is to 
keep pushing the idea until nobody who's resisting it can afford to continue 
doing so.   So whether or not to allow this conversation to continue is not 
simply a question of propriety or of protecting the working group's real work, 
although those are important considerations as well.  It really is a violation 
of the spirit of the consensus process to allow conversations like this to just 
go on and on and on and on.

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

On Mar 13, 2018, at 3:20 PM, Ackermann, Michael  wrote:
> I think that most Enterprises are not espousing any conversations "how can we 
> avoid making any changes?"

With respect, Michael, when I have conversed with you about this in the past, 
that is precisely what you have asked for.   You do not want to have to change 
your operational methodology, and any change to TLS that forces you to change 
your operational methodology is unacceptable to you.  I understand why that is, 
and I sympathize, but let's please be clear that this is your precise goal.

> But we would seek to avoid unnecessary,  wholesale, infrastructure 
> architectural changes.

There's an easy way to do this, although as a sometime bank security geek I 
would strongly advise you to not do it: keep using TLS 1.2.

Of course, you've also explained why that isn't acceptable to you—you are 
afraid that the payment card industry will eventually force you to use TLS 1.3, 
just as they have, rather ineffectively, tried to insist that you use TLS 1.2.

Now why would they do that?

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

On Mar 13, 2018, at 12:37 PM, nalini elkins  wrote:
> "We" is a consortium of organizations.   I would say over 50 so far.  They 
> operate large data centers.   They are in manufacturing, insurance, finance, 
> and others.  

Nalini, why don't you (the consortium) define the standard, then?

The reason I ask is that you are essentially asking us (the security folks) to 
bless something that is pretty obviously a bad idea, and of course we're 
resisting, and we're going to continue to resist.   I don't think you are ever 
going to get consensus on a document in the IETF that says what you want it to 
say.   And this is perfectly fine.   Your consortium can publish its own 
document that says what you want it to say.

Then when this goes badly wrong, it will be your consortium that is 
responsible, not the IETF.   Or if it doesn't go badly wrong, you can claim the 
credit.   But either way, you aren't going to have to keep arguing with us 
about this.   I don't think there's any reason for you to think that the 
argument is going to end in consensus; this is the reason that some of us are 
asking for it to stop.

Also, if what you produce isn't an IETF standard, then a browser can identify 
whether it implements IETF tls 1.3, or business-consortium-wtls-1.0.   We would 
hope that browsers that implement the latter would not exist, and that this 
would be okay for you because you don't actually need this hack in the browser. 
  That's the value of not doing this work in the IETF.

Also, I just wanted to mention a problem with something you said earlier:

> We feel that there is also an underlying motivation to help the underdog and 
> protect the political dissident. 

This is not a correct description of the situation.   TLS security is needed by 
whose information is communiced information over the network when revealing 
that information to an adversary would put them at risk.   When you make TLS 
security weaker, the set of people who is at risk is everyone, and the risks go 
from "twitter account compromised" all the way up to "teen with 'shameful 
secret' commits suicide when outed" or "my aging mom loses her retirement 
savings."

In addition, you are reducing compartmentalization with your keying strategy—in 
order to make communications easily decryptable, you have to have 
broadly-shared keys, and that reduces the amount of compartmentalization that 
TLS can provide between disparate elements in your networks.

We have seen the result of poor compartmentalization on network security—the 
most recent really egregious example being the Equifax, which would have been a 
lot less bad if Equifax had employed the sort of basic compartmentalization 
precautions that the NIST recommends.   Reducing compartmentalization 
inevitably makes it easier for an adversary to infiltrate your network and 
exfiltrate private user data.   Maybe it will never happen if you are careful 
enough.

The point is that your characterization of our objections as being about a 
certain special corner case is simply not an accurate characterization.   What 
you are proposing to do will weaken your network security too, and this 
weakening is quite likely to result in my personal data being compromised.

It would be really great if we could start talking seriously about ways to 
solve your problem, but that conversation can't take the form "how can we avoid 
making any changes?"   When I've tried to have serious conversations with you 
and others in your consortium about how to solve this problem in the past, any 
solution that requires you to implement new technology is always off the table. 
  That's no good.

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Ted Lemon]

On Mar 6, 2018, at 5:35 PM, Colm MacCárthaigh  wrote:
> There's a general conjecture that the more information that is provided to 
> attackers, the more easily they can leverage into a compromise. Personally I 
> believe that conjecture, and would actually prefer to see fewer signals, 
> ideally as few as one big error code. There is a trade-off against 
> debugability, but I've only seen a handful of people have the skills to debug 
> low level TLS issues and it doesn't seem worth the risk. Others disagree, 
> which is valid, but it's at least an area of reasonable contention.  

This makes perfect sense.   Stuart Cheshire and I were having the same 
discussion a while back about DNS Session Signaling, and he pointed out (I was 
playing Dale's role) that there's an important distinction to be made between 
"buggy implementation" and "actionable notification where no bug exists."   Any 
alert that signals "buggy implementation" is bad, for the reason you've stated, 
and also because such signals are not actionable—if you've run into a bug you 
should probably just give up, and not try to somehow guess in your 
implementation what might work when the bug happens.   The only reason to send 
a signal is if there is a known and clear action to take upon receiving the 
signal, other than "we're borked, give up."

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

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

[Ted Lemon]

We had a conversation about this at a Boston IETF meetup last year; the 
consensus, with which I agree, is that simply adding TLS alerts isn't good 
enough, for (essentially) the reason you stated earlier: we have no way to know 
that the attacker here is a good guy.   E.g., in the case of the OpenDNS 
behavior being described here, we don't know if OpenDNS is protecting us or 
attacking us.

A solution to this problem would require that there be a way for the MITM to 
signal that in this particular case, the connection is being blocked, and to 
sign that assertion with a cert that the application is configured to trust.   
This establishes a trust relationship with the protecting party (the operator 
of the OpenDNS server) that the user can agree to or refuse to agree to, and if 
the UI is done well, the user can be reminded that this intercept is the result 
of them agreeing previously to such intercepts.

This avoids presenting the user with something to click through, but also 
provides a way to attribute the intercept to a specific, authorized entity, so 
that if that entity decides to censor something I didn't agree to have 
censored, there's a way for the service provider to help me to understand why I 
can't access their service.

I'm responding in detail here because I want to make it clear that I am no 
longer a proponent of the original proposal, not because I'm specifically 
advocating what I describe above.   Another way to deal with this problem is to 
simply not provide the "bad cert" popup in the first place—that's a very bad UI 
design, and I've noticed that modern browsers are starting to abandon it (yay).

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

Re: [TLS] TLS@IETF100: Agenda Requests

[Ted Lemon]

On Nov 5, 2017, at 5:09 PM, Salz, Rich  wrote:
> I didn’t say votes.

Sure, but you did say "only the authors are interested" which to me seems to 
imply a comparison of numbers.   Sometimes everybody who's interested in an 
idea is an author; that doesn't mean it's a bad idea.   There have been cases 
when very good ideas have been squashed because the working group chair 
believed that a document needed more than just the authors to support it.   So 
over the years I guess I will admit to having developed a bit of a knee-jerk 
reaction to this argument—sorry about that!

My point here is that that's not the reason to reject the document.   The 
reason in this case is that there already exist better ways to solve the 
problem, and the proposal would clearly make TLS 1.3 worse, even though there 
is disagreement about how much worse it would make it.

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

Re: [TLS] TLS@IETF100: Agenda Requests

[Ted Lemon]

Consensus isn't about number of votes. However, I think we can say that
although there seems to be some interest in making sure this use case is
addressed, there are known ways of addressing it, and little interest in
inventing a new way that weakens a new feature of tls 1.3

On Nov 5, 2017 14:03, "Salz, Rich"  wrote:

> So if the only people in favor of it are the draft authors, then we have
> consensus, right?
>
>
>
> ___
> 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] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 25, 2017, at 3:34 PM, Nick Sullivan  wrote:
> Forward secrecy with respect to other keys, like the session ticket key or 
> other keys that can be generated centrally, are things that need to be looked 
> at more closely for TLS 1.4 (or whatever’s next).

Unless I am very much mistaken, it is literally impossible to prevent a server 
from escrowing a key so that the contents of the communication can be decrypted.

> - having such a system on the internet is a bad idea because it reduces the 
> security of multiple connections down to a single piece of data
> - on the other hand using draft-rhrd is safer than allowing organizations to 
> hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with 
> non-forward-secret cipher suites

There's no question of allowing or not allowing—that's outside of IETF's sphere 
of influence.   But the case has been (to me convincingly) made that making it 
possible for an eavesdropper on the conversation to easily tell whether a 
client is willing to accept key escrow makes things worse, from a security 
perspective.

The main sense in which it makes things worse is that such a feature might be 
added to standard libraries, and thus be available at low cost, and thus might 
become easy to impose as a regulatory requirement.

This is why I have been advocating for simply not using TLS for this use case.  
 There exist solutions to this problem that do not require breaking TLS 1.3, 
that are standard, and that are already allowed for PCI compliance.   It's 
better for everyone if these two domains are kept separate, and I haven't yet 
heard a good argument for not doing so.

> The fundamental assumption of this draft is that that 3) is not feasible for 
> all enterprises because rearchitecting their systems for a multi-key escrow 
> is either too costly or that the requirement for TLS 1.3 will come too soon. 
> Ted Lemon had some convincing arguments earlier about why enterprises should 
> see this coming and invest in migrating to a model closer to 3),

To be clear, I actually don't think that per-session key escrow is feasible in 
the use case that we are talking about here.   From a security perspective I 
think it's a pretty good idea, because it allows for things like rate-limiting 
the number of connections that can be monitored, but from a practical 
perspective, arranging to have the keys available in a timely manner during 
debugging seems to me not to be tractable, since the number of keys involved 
would be substantial, and the timing would be quite exact; indeed, if the 
debugging process requires debugging all active streams in order to find an ID 
in the stream that is actually sought, I think it would be almost impossible, 
and certainly ludicrously expensive.

What I've been arguing for is to switch away from TLS for this use case.

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 24, 2017, at 4:40 PM, David A. Cooper  wrote:
> Also, in the data center case, there is no middlebox. Others, who know much 
> more than I do about operational constraints in data center environments, 
> have already argued that setting up a bunch of middleboxes would not be a 
> viable solution.

I was not actually suggesting this as a solution.   Rather, I was pointing out 
that it's a lousy solution for both use cases.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 24, 2017, at 4:21 PM, David A. Cooper  wrote:
> I'm not suggesting that cash strapped schools would use one of these devices. 
> I'm simply saying that such a solution would be simpler and far more 
> effective than trying to use draft-rhrd-tls-tls13-visibility to snoop on 
> outgoing traffic.

Again, if that were true, then it would also be true that these devices would 
nicely solve the problem that draft-rhrd-tls-tls13-visibility solves.

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 24, 2017, at 3:59 PM, Ted Lemon  wrote:
> On Oct 24, 2017, at 3:54 PM, David A. Cooper  <mailto:david.coo...@nist.gov>> wrote:
>> There are already middleboxes on the market today that do this. They work 
>> for all outgoing connections and don't require any cooperation whatsoever 
>> from the outside servers that the clients are trying to connect to, and only 
>> expert users would notice the presence of the MiTM.
> 
> They are also quite expensive because they have to generate certs on the fly. 
>   If you look at environments where these are in use, they tend to be either 
> high-margin, or else low-use.   So e.g. you only redirect TLS connections 
> that you absolutely need to intercept through the box; other connections are 
> terminated normally.   Practically speaking, I don't see any cash-strapped 
> school spending money on one of these devices.

BTW, if you find this argument unconvincing, consider why these boxes aren't 
being proposed for use as an alternative to draft-rhrd-tls-tls13-visibility-00. 
  :)

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 24, 2017, at 3:54 PM, David A. Cooper  wrote:
> There are already middleboxes on the market today that do this. They work for 
> all outgoing connections and don't require any cooperation whatsoever from 
> the outside servers that the clients are trying to connect to, and only 
> expert users would notice the presence of the MiTM.

They are also quite expensive because they have to generate certs on the fly.   
If you look at environments where these are in use, they tend to be either 
high-margin, or else low-use.   So e.g. you only redirect TLS connections that 
you absolutely need to intercept through the box; other connections are 
terminated normally.   Practically speaking, I don't see any cash-strapped 
school spending money on one of these devices.

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 24, 2017, at 3:24 PM, Ralph Droms  wrote:
> ...with the assumption that a client would automatically revert to trying the 
> connection with the visibility extension if it can't make a connection 
> without the extension.  Why would that assumption be useful?  How is this 
> situation different than the current practice of using HTTP if HTTPS fails?

More likely the client would be failed with one that just automatically 
negotiates the visibility extension, because that's easier and quicker.

> Can you demonstrate how such an attack would work without the assumption that 
> a client (e.g., browser) would, as policy, downgrade to using the extension 
> if it can't connect without the extension.  I understand the general concern.

I don't think it's necessary to demonstrate that, because the browser that 
implements this extension will just automatically negotiate it.

> I still don't see how step 2 is different than forcing a connection without 
> using TLS at all?  Why is the visibility extension more dangerous than only 
> allowing connections with no TLS?

There's no fig leaf of security if you allow connections with no TLS.

The problem with these proposals generally is that they push us in the 
direction of picking and choosing who we will allow to eavesdrop on us, and 
make it non-negotiable in order to access services we want.   You and I are 
smart enough to say "no" when presented with this choice; unfortunately, at 
least at present, many people are not, and see things like browser security 
warnings as annoyances.   This is why UAC failed in Windows Vista, and why 
Vista was widely reviled for its poor usability.

It is demonstrably the case that users will say yes to things that are not in 
their self interest to get to the resources they want.   Every time I visit my 
mom, she has new malware installed on her Chromebook that I removed on my 
previous visit.

So if we do not say no to this, it's likely that ultimately not enough people 
will, and a lot of end users will suffer as a result, some of them operating 
things we'd like to remain secure.   That is the discussion we should be having 
right now.

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 24, 2017, at 12:49 PM, Joseph Salowey  wrote:
> First, we would like to clarify that this discussion isn't delaying TLS 1.3. 
> We've been holding final publication to resolve some middlebox issues as 
> described in a recent message from ekr
> https://mailarchive.ietf.org/arch/msg/tls/yt4otPd5u_6fOzW02TEe2e-W5G0 
>  and 
> expect to discuss this in Singapore. No one and we mean no one should delay 
> submitting a PR related to TLS1.3 or any other WG draft because of this 
> discussion. You’ll note that others have recently, you should follow suit.

Perhaps not.   I don't feel qualified to judge.   But it's delaying other work, 
because people who could be doing useful work in the IETF are engaging on this 
topic instead.   No discussion is without cost, so there is value in cutting 
off useless discussion, and it is very much your job to do so.   E.g., this was 
about a half hour of my time, and I have a bunch of other things to do before 
the draft submission cutoff that I didn't do so that I could respond to this.

> In Prague, we had a discussion of draft-green and there was neither consensus 
> to work in this area nor to decline to work in this area.  In addition to the 
> comments that we should simply decline all such work, the authors received 
> technical comments about their approach and draft-rhrd seems to be an attempt 
> to address some of those comments.  As is normal IETF practice, we will be 
> giving this topic agenda time in Singapore to see if a consensus emerges one 
> way or the other.

The problem with this is that technical comments about a bad idea just improve 
the bad idea.   The discussion we have been trying to have with the proponents 
of this idea is the question of whether or not it is a bad idea, not about the 
technical details.   I say this as someone who has proposed lots of bad ideas 
in the past.   When I propose a bad idea, and for example Dave Oran points out 
something obvious that I missed (true story), my response to this is to 
reconsider what I've proposed to do and to see if there is a better way to 
solve the problem, not to continue pushing for the idea that has been shown to 
be a bad idea.

Our objection here, which I third or fourth, is that this discussion has not 
progressed that way.   This is clearly a bad idea.   Maybe you don't agree.   
But we've said why it's clearly a bad idea, and that is something that could 
have been discussed.   But none of the proponents of this idea have made any 
attempt to address the substantive objections that have been raised about the 
idea itself.

So it's not really fair to say that progress is being made.   Progress is being 
made on refining the bad idea, but no progress has been made in discussing ways 
to solve the problem that aren't a bad idea.   To be clear, I and several 
others have proposed ways of solving this problem that are not bad ideas.   
These have been rejected on non-technical grounds.

> Absolutely no decisions will be made about adoption prior to that time, nor 
> prior to a formal call for adoption. In particular, decisions will not be 
> made based on the volume of messages to the mailing list.  It is unnecessary 
> and unproductive to repeat points you have already made just because someone 
> responds to you. You will not be missing out on the chance to make your 
> argument.

This feels like the Overton window shifting due to a false equivalence.   The 
issue here is not that we feel that we will miss out on the chance to make our 
arguments.   It's that we've been making them, and they've been explicitly 
ignored.

> Finally, we would like to remind WG members to keep their messages 
> professional and civil. We have noted a number of recent messages that do not 
> conform to those standards and we will be reaching out to people personally 
> to address those instances.

I believe that I have been personally chastized by another participant for 
responding in a way that was held by that participant to be 
uncivil/unprofessional.   If you agree with that assessment, please communicate 
with me to that effect privately (or publicly, if you prefer, but this 
conversation has really gone on for too long).

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 24, 2017, at 3:04 PM, David A. Cooper  wrote:
> In order for a middlebox to be able to use this draft to intercept traffic 
> that is TLS protected, it would need to:
> 
> 1) get the server to agree to allow it to intercept the traffic; and
> 
> 2) get the client to include the new extension in its ClientHello.
> 
> How would the middlebox get the client to include the extension.

Block all TLS connections that don't use it.

>> I believe I know why people want this now. They are worried that if TLS 1.3 
>> goes out without something like this, then the market (standard widely 
>> available browsers) will not implement it. Let me assure you that this isn’t 
>> an issue. The extension would *never ever* make it to the MUST state, and 
>> the browsers would be unlikely to ever implement it anyway.
> 
> I partially agree with this and partially disagree. I agree that browsers 
> (and other similar clients) would be unlikely to ever implement it. I 
> disagree with the suggestion that proponents of this draft want for browsers 
> to implement this or want it to be a MUST. Proponents of this draft are 
> interested in visibility within the data center, and have no interest in 
> using this capability in any scenario in which a browser would be the client.

Let's be clear.   While I may have made some statements about the balance of 
concern over who pays for this, nobody is saying that the proponents of this 
draft intend a nefarious use of this extension.   The concern is not that BCBS 
is going to invade my privacy.   It is that if BCBS gets its way, someone 
_else_ will use this technology to invade my privacy, or to trojan horse some 
malware onto my computer, or some other attack.

> So, given your agreement that browsers would be unlikely to ever implement 
> this extension, how would the in-flight WiFi (or other middlebox) be able to 
> get clients to include the extension if the software they are using doesn't 
> support it? It seems that the only way would be to coerce the clients into 
> using a browser (or other client) provided by the attacker (i.e., in order to 
> use the Internet while in flight you must install Evil Airline's 
> browser/app). But then, if the attacker is able to get the client to install 
> and use its own software, then it would easily be able to intercept all 
> traffic from the client, not just traffic to cooperating servers, so why 
> would it bother using this draft at all in this case?

You've inverted the chain of causality here.   The chain is (to the best of my 
ability to explain it, anyway):

1. Standardize this extension
2. Someone with a service people want to use starts blocking connections that 
don't enable it.
3. Browser vendors are forced to implement it, or end users are forced to 
download special browser software.
4. Now an attack surface exists on the user's machine that hadn't previously 
existed.
5. The user's machine is now subject to attack by a larger set of attackers 
than it had been previously, using a larger set of attacks than were available 
previously.

None of this is a smoking gun.   If everybody keeps all the plates spinning, we 
won't have a problem.   The problem is that everybody keeping the plates 
spinning is something that pretty much doesn't happen in the real world, as 
we've seen if we follow the news.   And some of the everybodies in this 
equation are operating infrastructure that we really, really need to be well 
protected.   And others are being stalked.   And still others are trying to do 
secure transactions online.

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 23, 2017, at 2:12 PM, Ackermann, Michael  wrote:
> To suggest that I or my industry does not take security seriously, is 
> inaccurate and immaterial to this discussion. 

I'm sure you take security seriously.   What I'm saying is that you have tunnel 
vision about it, because you are caught between a rock (the IETF) and a hard 
place (management that won't listen).
 
> I would put the comment  that anyone or any industry is attempting to lay 
> costs for anything off on IETF,  in the same unfortunate bucket. 

By "we" I mean users of the Internet, not the IETF.  The IETF doesn't have deep 
pockets.
 
> These types of subjectively negative statements are not at all constructive, 
> germane nor worthy of response.


That's fine.   We would all like for this conversation to end.   My 
"subjectively negative statements" were just explaining to you why you aren't 
making any headway in the working group in trying to get the outcome you seek.

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 23, 2017, at 1:30 PM, Ackermann, Michael  wrote:
> The WHY you ask is in the answer.  
> It is a huge proposition requiring change to virtually every platform and 
> application.Not to mention all the management,  monitoring and security 
> platforms. 
> It would be very expensive and time consuming. 
> And when they ask why this is necessary,  it is because the new version of 
> the existing protocol is not backwards compatible,  which is something we 
> have come to expect. 

I really tried to have sympathy for you about this in Prague.   I know what 
it's like to get unreasonable pushes from management (not based on recent 
experience, fortunately).   But this exact form of reasoning is why we're 
suffering from attacks on the internet like the Mirai botnet and the Reaper 
botnet, the Equifax hack, et cetera.

You have come to a group of people who take these issues extremely seriously 
and asked them to bless you in going forward to create another problem of the 
same magnitude.   I know you don't think that's what you're asking, but that 
really is what you are asking.   It might not be on your network—maybe you will 
operate this technology securely.   But you are asking us to create an attack 
surface, and it will be used.

When you make requests like this, what you are really doing is pushing off 
costs your management doesn't want to pay on the users of the Internet as a 
whole.   130 million Americans are now doomed for life to suffer from attacks 
on their credit because of this kind of thinking.

Stop asking us to take security less seriously, and start taking it more 
seriously.   You work for BCBS: you are responsible for protecting the privacy 
of a similar number of Americans.   I know this is hard, but it's time to stop 
imagining that you can lay costs off on us and start planning how you are going 
to migrate to a more secure architecture.

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 23, 2017, at 12:39 PM, Ackermann, Michael  wrote:
> If staying with TLS 1.2 indefinitely was considered acceptable,  would we 
> even be having these discussions? 

This is a vacuous argument.   Nobody has provided any evidence of any kind that 
"enterprise" installations relying on TLS 1.2 would ever switch to TLS 1.3, 
much less that they would do so in any kind of hurry.   You demonstrate why 
with your very next bullet point:
> Modifying Server,  application and logging infrastructure is a huge, 
> expensive proposition,  that executive management would not be receptive to 
> at all.   Not to mention the logistics to follow if they were.  

If indeed that unmovable mountain, executive management, must be moved in the 
case of switching to TLS 1.3 or in the case of switching to something else, it 
seems obvious to me that it is better to switch to something else.

Can you give me a clear technical reason why that is not preferable?

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 23, 2017, at 12:25 PM, Ralph Droms  wrote:
> Is there running code that demonstrates the IPsec+IKE can be deployed and 
> operated at scale in the sort of environment the enterprise network tips have 
> described to us?

Is there running code that demonstrates that draft-rhrd-tls-tls13-visibility-00 
can be deployed and operated at scale?   :)

In fact, when I went looking at the state of the art for IKE/IPsec after our 
conversation in Prague, I was pleasantly surprised at how usable it is.   I 
don't know if it currently scales up as you suggest, but it certainly can in 
principle.   This is why I'm suggesting that resources be spent doing that, 
rather than in limiting the ability of TLS 1.3 to address its use case, which 
is a different use case.


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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 23, 2017, at 12:22 PM, Ackermann, Michael  wrote:
> My question back to you was WHAT SIMPLIER PROTOCOL?  

This is what I actually wrote, in the message before the one Kathleen sent:

> What they require is visibility into contents of the flow that they are using 
> encryption to protect.   Right now, the protocol they are using is TLS 1.1 or 
> TLS 1.2.   The right thing for them to do if they continue to need this 
> visibility and are no longer permitted to use TLS 1.2 is to use IPsec+IKE, or 
> some protocol that is designed for this use case, not to take a protocol 
> designed specifically for securing flows from on-path eavesdropping and 
> create a mode where it is easier to wiretap.


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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 23, 2017, at 10:35 AM, Ackermann, Michael  wrote:
> I was only asking what your opinion was, based on that statement in your 
> reply. 

With respect, Michael, I gave my opinion in the message to which Kathleen 
replied, so your assertion that you have been reading these messages doesn't 
seem to be reflected in the dialog we are having.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 22, 2017, at 7:16 PM, Ackermann, Michael  wrote:
> And out of curiosity,  what is the simpler protocol you are recommending?
> I say out of curiosity because switching to a whole different protocol is not 
> likely to be feasible from any perspective for large enterprises and the 
> complex, multi-tier protocols that are prevalent. 

Perhaps you should read the article that Kathleen shared earlier today?

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 22, 2017, at 7:26 PM, Steve Fenter  wrote:
> I have been saying to anyone who will listen that the IETF needs a private 
> forum for enterprises, to enable them to come forward and discuss their real 
> requirements. Without this input the IETF is trying to architect and engineer 
> solutions without knowing the complete set of requirements, at least on the 
> enterprise side.  This results in sub-optimal design decisions (from an 
> enterprise perspective), which in this case will break mission critical 
> enterprise monitoring and troubleshooting systems.

The reason we don't have that is that designing secure protocols in secret 
isn't a trustworthy approach.   Of course, you can always get together 
privately.

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 22, 2017, at 4:48 PM, Steve Fenter  wrote:
> The main problem with not addressing the TLS visibility issue now is that no 
> one knows when a vulnerability will be discovered in TLS 1.2 that forces 
> enterprises to upgrade to TLS 1.3. We've had guarantees that TLS 1.2 and the 
> RSA key exchange are going to be fine for 5 to 10 years, but nobody knows 
> that, particularly in today's security environment.

Implicit in this assertion is the claim that these organizations could switch 
quickly to TLS 1.3, but in fact we know that it's been very difficult for them 
to make the switch from 1.1 to 1.2, and in many cases they haven't done it.   
So this isn't really at all persuasive.   But even if it were persuasive, it 
still wouldn't be a good argument.  TLS is a complicated protocol that does far 
more than is required for the use case we are talking about.   It would be 
better to use a simpler protocol with a smaller attack surface.

So why not get started on that now, instead of trying to weaken TLS 1.3?

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 22, 2017, at 1:54 PM, Russ Housley  wrote:
> No one is requiring TLS 1.3 that I know about.  However, there are places 
> that require visibility into TLS.  I will let one of the people that works in 
> a regulated industry offer pointers to the documents.

What they require is visibility into contents of the flow that they are using 
encryption to protect.   Right now, the protocol they are using is TLS 1.1 or 
TLS 1.2.   The right thing for them to do if they continue to need this 
visibility and are no longer permitted to use TLS 1.2 is to use IPsec+IKE, or 
some protocol that is designed for this use case, not to take a protocol 
designed specifically for securing flows from on-path eavesdropping and create 
a mode where it is easier to wiretap.

There is no reason other than momentum for them to switch to TLS 1.3 when it 
doesn't address their use case.

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 20, 2017, at 9:54 AM, Stephen Farrell  wrote:
> Others did
> comment that the lack of client opt-in was a
> bad aspect of draft-green, but I'm not sure
> that anyone clearly said "I do want draft-green
> snooping, but with client opt-in."

I can say for myself that there was a really strong hard sell on the notion of 
doing this in Prague.   Not being sufficiently paranoid, my general sympathy 
for people facing hard problems led me to consider what they were proposing, 
but each time they came up with something, someone with more paranoia fu than I 
have pointed out a hole in it.   During that period there were several periods 
when I was reluctantly willing to consider some less-bad version of 
draft-green.   This is a long way from "want," and even a pretty long way from 
"support."

My personal feeling having been peeled off the herd and hard-sold like this is 
that there is some really powerful motivated reasoning going on here, and that 
the working group should just stop entertaining this process.   Weakening TLS 
is not the right way to approach the problem that has been described here.

I hasten to add that I don't think the people doing the hard sell are bad 
people, or that they didn't have good reason for trying to do it.   My point is 
simply that we've been collectively sucked close to a black hole here, and we 
need to take a step back from it.   In the same sense that LEOs who want key 
escrow have good reason for wanting it and are not bad people for wanting it, 
so too with the people pushing this proposal.   But like key escrow, this 
proposal is not beneficial for end-users or for security as a whole.

In order for it to make sense to go forward with this proposal, two things 
would have to be true that I don't think are true.   First, we would have to 
agree that user security is not a primary goal.   And second, we would have to 
agree that overall network security is not a primary goal.   Discussing the 
details of how much security we are willing to give up, what attack surfaces 
that we could remove we are willing to leave in, only makes sense if we are 
willing to drop those two primary goals.

Watching this conversation has been a really good learning experience for me, 
so I don't regret it, but I think we should stop.

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

On Oct 19, 2017, at 1:12 PM, Blumenthal, Uri - 0553 - MITLL  
wrote:
> If those middleboxes already have sufficient alternative options, why do we 
> spend time discussing this draft? Why do we need to add yet another 
> alternative for them?

Indeed, if this proposal were equivalent to CA forcing, then the solution to 
the problem this proposal purports to solve would be CA forcing. The reason 
this proposal is preferred is that it's easier and less apparently invasive 
than CA forcing.  Making less good crypto have an obviously less good UI is a 
good thing.

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

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

[Ted Lemon]

On Aug 11, 2017, at 11:17 AM, Short, Todd  wrote:
> The application can solve this by having its own padding. If it’s going to 
> force all messages to be padded out to 1024 bytes by TLS, why not just make 
> that part of the application protocol? Its not as though it’s trying to save 
> bytes here.

The downside to this is that now you have to get it right in each protocol that 
does it, instead of getting it right once.

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

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Ted Lemon]

On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL  
wrote:
> What I am trying to avoid is the ability to *surreptitiously* subvert a 
> protocol that’s assumed to be secure.

You don't seem to be hearing what I'm trying to say.   What you are proposing 
is physically impossible.   It is always possible to surreptitiously subvert 
the protocol.   This is not an achievable goal.   What you get if you implement 
what you are proposing is a protocol that's easier for an on-path attacker to 
subvert, not a protocol that is harder for an end-point attacker to subvert.

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

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Ted Lemon]

On Jul 23, 2017, at 5:37 PM, Christian Huitema  wrote:
> Speaking of threat model, one of the main threats is the "Lavabit" case: a 
> server is asked to somehow implement a backdoor so existing clients. In that 
> case, it is very useful for clients to detect that something has changed. 
> They can move away and use another server.

Clients cannot detect this backdoor.   They can be informed of it, but they 
can't detect it.

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

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Ted Lemon]

On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL  
wrote:
> I think there's no way the connection can be established if the third party 
> in control of the network does not allow that. 

This is why it’s hard to reason well about this stuff—we tend to get the threat 
models wrong.   The attack that negotiating enables is not that a third party 
can block all connections. They can always block all connections.

What the attack enables is blocking only those connections that don’t negotiate 
a downgrade. So if you negotiate a downgrade, you get to look at your content, 
but if you don’t negotiate the downgrade, you don’t. This allows a MiTM to 
coerce end users into negotiating downgrades.

Of course the far end can just not downgrade, but it may have downgrading 
enabled either for debugging purposes, never intending that all connections be 
downgraded, or because the operator didn’t configure the server correctly.   If 
it’s not in the standard, it can still be enabled by operators who are 
violating the end user’s trust, but won’t happen by accident and won’t be 
possible to coerce with a MiTM attack. ___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Ted Lemon]

I did a little bit of rubber-duck debugging on this proposal with Andrea on the 
way back from Boston this morning.   It's actually better for the server to 
secretly use a static key than to negotiate.   Stephen has already explained 
why: if this is a negotiation, then it's possible for a third party to simply 
block any negotiation that doesn't allow it.   We have no control over evil 
endpoints, and it's silly to pretend otherwise.   Pretending otherwise makes us 
less secure, not more secure.

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

Re: [TLS] Is there a way forward after today's hum?

[Ted Lemon]

As I said in the previous message, the 3270 was the original web browser.
What I mean by that is that the 3270 transaction model is basically a
primitive version of http: you throw up a page, the user enters some data,
then the user hits send and all the data goes to the server at once.   The
reason the 3270 is no longer widely used is because it's been replaced by
web browsers.

Mentioning that in passing probably made my message less clear; the point
is that the 3270<->mainframe model of operation comes with very different
assumptions than the web browser<->service provider model, and one of the
problems you have is that what you are doing is really the former and not
the latter.


On Fri, Jul 21, 2017 at 12:00 PM, Ackermann, Michael 
wrote:

> Ted
>
> You may be aware that most enterprises have been migrating away from 3270
> for 20 years or more.  Very little still exists.  What little does
> exist is usually implemented via tn3270.   In the browser scenario you
> describe I would expect the Server side to be a tn3270 server,  but you
> will have to fill in the details of the use case you are describing,  to be
> sure.
>
>
>
> I hope the above helps,  but my real question is why would this be special
> or even relevant to the TLS1.3 discussion.
>
>
>
> Attempting to address specific applications or implementations would seem
> only add confusion IMHO.
>
>
>
> Thanks
>
>
>
> Mike
>
>
>
>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 10:48 AM
> *To:* Tom Ritter 
> *Cc:* IETF TLS 
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> The problem is that one of the applications for web browsers is as a
> replacement for 3270s (the first web browser).   That use case is said to
> require this functionality.
>
>
>
> On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter  wrote:
>
> On 20 July 2017 at 01:53, Yoav Nir  wrote:
> >
> > On 20 Jul 2017, at 8:01, Russ Housley  wrote:
> >
> > Ted, if we use a new extension, then the server cannot include it unless
> the
> > client offered it first.  I am thinking of an approach where the server
> > would include information needed by the decryptor in the response.  So,
> if
> > the client did not offer the extension, it would be a TLS protocol
> violation
> > for the server to include it.
> >
> >
> > So we also add an alert called “key-export-needed” in case the client
> does
> > not include it.
> >
> > That way a browser (as an example) can show the user why the connection
> was
> > broken (“server requires wiretapping to be enabled. Go to about:config if
> > that is OK and change the allow-wiretap setting to True”)
>
> I previously expressed that I could support the extension mechanism -
> I'm sympathetic to regulatory requirements and unhappy with, although
> understanding of, what has become the 'standard mechanism' (breaking
> crypto) to achieve them. I've looked at more than one 'end to end'
> encrypted messenger that tosses in the 'third end' of key escrow.
>
> But to suggest such a mechanism might ever be implemented in a web
> browser throws my hackles up. The discussion has always been about
> datacenter - the people concerned say "We don't want your datacenter
> stuff in our protocol and the proponents say "No really, we only care
> about the datacenter."
>
> The concerns around some future government-mandated key escrow is very
> real and very concerning.
>
> -tom
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Is there a way forward after today's hum?

[Ted Lemon]

The problem is that one of the applications for web browsers is as a
replacement for 3270s (the first web browser).   That use case is said to
require this functionality.

On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter  wrote:

> On 20 July 2017 at 01:53, Yoav Nir  wrote:
> >
> > On 20 Jul 2017, at 8:01, Russ Housley  wrote:
> >
> > Ted, if we use a new extension, then the server cannot include it unless
> the
> > client offered it first.  I am thinking of an approach where the server
> > would include information needed by the decryptor in the response.  So,
> if
> > the client did not offer the extension, it would be a TLS protocol
> violation
> > for the server to include it.
> >
> >
> > So we also add an alert called “key-export-needed” in case the client
> does
> > not include it.
> >
> > That way a browser (as an example) can show the user why the connection
> was
> > broken (“server requires wiretapping to be enabled. Go to about:config if
> > that is OK and change the allow-wiretap setting to True”)
>
>
> I previously expressed that I could support the extension mechanism -
> I'm sympathetic to regulatory requirements and unhappy with, although
> understanding of, what has become the 'standard mechanism' (breaking
> crypto) to achieve them. I've looked at more than one 'end to end'
> encrypted messenger that tosses in the 'third end' of key escrow.
>
> But to suggest such a mechanism might ever be implemented in a web
> browser throws my hackles up. The discussion has always been about
> datacenter - the people concerned say "We don't want your datacenter
> stuff in our protocol and the proponents say "No really, we only care
> about the datacenter."
>
> The concerns around some future government-mandated key escrow is very
> real and very concerning.
>
> -tom
>
> ___
> 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] Is there a way forward after today's hum?

[Ted Lemon]

It's a variant of (3).

What your threat models do not take into account is how these attacks
relate to the problem they are proposed to solve.   The reason we're even
having this discussion is because some data center operators feel that
having ephemeral keys is too onerous, and that they would like the IETF to
weaken TLS 1.3 to no longer require this.

So if you just consider this problem in the abstract as a serious of
potential threat models, you're somewhat missing the point.   From my
perspective, the problem here is that to address this use case, we are
being asked to make a change to TLS which will make every existing
implementation of TLS that conforms to the change weaker.

It is certainly true that TLS 1.3 isn't resistant to the threats you've
described; that's not the point.   The point is that TLS 1.3 makes each of
these threats substantially more expensive to pull off, with more moving
parts and more people with a need to know.   It does not make the attacks
impossible, or even impossible to do in secret.  It makes them harder, and
harder to do in secret.

On Thu, Jul 20, 2017 at 1:58 PM, Paul Turner  wrote:

>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 07:51
> *To:* Paul Turner 
> *Cc:* Robin Wilton ;  
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Paul, the reason to use the MiTM approach rather than simply hacking the
> endpoint the attacker controls is that it may be much more convenient to be
> running out-of-the-box software on the endpoint.   The MiTM isn't an
> attacker from the perspective of the controlled endpoint; it is simply a
> convenient way to conceal what is being done.
>
>
>
> To make sure I understand your reference to MiTM, is that different than
> the third party in #2 and #3 below?
>
>
>
> Having thought about it some more, as Russ points out, it might be too
> expensive to be worth doing, because you'd have to hack the whole stream.
> It would not, for example, be a useful passive attack, obviously.
>
>
>
> That said, suppose this extension were added to everyone's TLS libraries.
>   Now the number of lines of code I'd have to #ifdef out to avoid setting
> the evil bit would be much less than if it weren't.
>
>
>
>
>
> On Thu, Jul 20, 2017 at 1:44 PM, Paul Turner 
> wrote:
>
>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 07:25
> *To:* Paul Turner 
> *Cc:* Robin Wilton ;  
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Paul, it would be trivial to normal that exchange to conceal from the
> client that a static key is being used. No software mods required on either
> end: just in the middle.
>
>
>
> Thanks, Ted. Can you expand on this?
>
>
>
> Also, can you also put it in the context of a threat model as Robin
> suggested? I’ve suggested some things below but may not have it right. Why
> would the attacker take this approach versus some of the readily available
> methods?
>
>
>
> Paul
>
>
>
> On Jul 20, 2017 1:04 PM, "Paul Turner"  wrote:
>
>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Robin Wilton
> *Sent:* Thursday, July 20, 2017 05:58
> *To:* tls@ietf.org
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Apologies for not replying "in thread" on this occasion, for noob
> reasons... but here's the specific comment from Russ that I wanted to
> respond to:
>
>
> --
>
> The hum told us that the room was roughly evenly split.  In hind sight, I 
> wish the chairs had asked a second question.  If the split in the room was 
> different for the second question, then I think we might have learned a bit 
> more about what people are thinking.
>
>
>
> If a specification were available that used an extension that involved both 
> the client and the server, would the working group adopt it, work on it, and 
> publish it as an RFC?
>
>
>
> I was listening very carefully to the comments made by people in line.  
> Clearly some people would hum for "no" to the above question, but it sounded 
> like many felt that this would be a significant difference.  It would ensure 
> that both server and client explicitly opt-in, and any party observing the 
> handshake could see the extension was included or not.
>
>
>
> Russ
>
> 
>
>
>
> Stephen Farrell articulated a concern with that approach - namely, that if
> we are relying on a setting that is meant to ensure both p

Re: [TLS] Is there a way forward after today's hum?

[Ted Lemon]

Paul, the reason to use the MiTM approach rather than simply hacking the
endpoint the attacker controls is that it may be much more convenient to be
running out-of-the-box software on the endpoint.   The MiTM isn't an
attacker from the perspective of the controlled endpoint; it is simply a
convenient way to conceal what is being done.

Having thought about it some more, as Russ points out, it might be too
expensive to be worth doing, because you'd have to hack the whole stream.
It would not, for example, be a useful passive attack, obviously.

That said, suppose this extension were added to everyone's TLS libraries.
Now the number of lines of code I'd have to #ifdef out to avoid setting the
evil bit would be much less than if it weren't.


On Thu, Jul 20, 2017 at 1:44 PM, Paul Turner  wrote:

>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 07:25
> *To:* Paul Turner 
> *Cc:* Robin Wilton ;  
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Paul, it would be trivial to normal that exchange to conceal from the
> client that a static key is being used. No software mods required on either
> end: just in the middle.
>
>
>
> Thanks, Ted. Can you expand on this?
>
>
>
> Also, can you also put it in the context of a threat model as Robin
> suggested? I’ve suggested some things below but may not have it right. Why
> would the attacker take this approach versus some of the readily available
> methods?
>
>
>
> Paul
>
>
>
> On Jul 20, 2017 1:04 PM, "Paul Turner"  wrote:
>
>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Robin Wilton
> *Sent:* Thursday, July 20, 2017 05:58
> *To:* tls@ietf.org
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Apologies for not replying "in thread" on this occasion, for noob
> reasons... but here's the specific comment from Russ that I wanted to
> respond to:
>
>
> --
>
> The hum told us that the room was roughly evenly split.  In hind sight, I 
> wish the chairs had asked a second question.  If the split in the room was 
> different for the second question, then I think we might have learned a bit 
> more about what people are thinking.
>
>
>
> If a specification were available that used an extension that involved both 
> the client and the server, would the working group adopt it, work on it, and 
> publish it as an RFC?
>
>
>
> I was listening very carefully to the comments made by people in line.  
> Clearly some people would hum for "no" to the above question, but it sounded 
> like many felt that this would be a significant difference.  It would ensure 
> that both server and client explicitly opt-in, and any party observing the 
> handshake could see the extension was included or not.
>
>
>
> Russ
>
> 
>
>
>
> Stephen Farrell articulated a concern with that approach - namely, that if
> we are relying on a setting that is meant to ensure both parties must be
> aware that static DH is in use, then a bad actor would find ways to
> suppress that notification. In your proposal, Russ, the notification
> mechanism would take the form of an extension... so I think we would need
> to understand what the failsafe is, for instance if that extension is
> disabled, or not present, in a given deployment of TLS.
>
>
>
> There's an implicit assumption about the threat model, too, which I just
> want to call out. The assumption is that a bad actor would suppress the
> notification so that the client is not aware that static DH is in use. For
> completeness, should we also consider whether there are attacks in which
> it's the *server* whose notification is suppressed? (I can't think of such
> an attack, off the top of my head, but then, that's probably why I'm not a
> hacker. ;^, )
>
>
>
> Best wishes,
>
> Robin
>
>
>
> Robin,
>
>
>
> With respect to your threat concerns, can you be more clear about the
> threats you’re considering? Here are a few things that come to mind:
>
>
>
> 1. TLS Server has all of the decrypted data and can provide that to a
> third party (whether compelled or otherwise) without any indication to the
> TLS client. This seems true TLS 1.3 today.
>
> 2. TLS Server has their ephemeral DH keys and session keys and can
> provide them to a third party without any indication to the TLS client.
> This seems true with TLS 1.3 today.
>
> 3. TLS Server can create a TLS server implementation that uses static
> DH keys and provide them to a third party.

Re: [TLS] Is there a way forward after today's hum?

[Ted Lemon]

Paul, it would be trivial to normal that exchange to conceal from the
client that a static key is being used. No software mods required on either
end: just in the middle.

On Jul 20, 2017 1:04 PM, "Paul Turner"  wrote:

>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Robin Wilton
> *Sent:* Thursday, July 20, 2017 05:58
> *To:* tls@ietf.org
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Apologies for not replying "in thread" on this occasion, for noob
> reasons... but here's the specific comment from Russ that I wanted to
> respond to:
>
>
> --
>
> The hum told us that the room was roughly evenly split.  In hind sight, I 
> wish the chairs had asked a second question.  If the split in the room was 
> different for the second question, then I think we might have learned a bit 
> more about what people are thinking.
>
>
>
> If a specification were available that used an extension that involved both 
> the client and the server, would the working group adopt it, work on it, and 
> publish it as an RFC?
>
>
>
> I was listening very carefully to the comments made by people in line.  
> Clearly some people would hum for "no" to the above question, but it sounded 
> like many felt that this would be a significant difference.  It would ensure 
> that both server and client explicitly opt-in, and any party observing the 
> handshake could see the extension was included or not.
>
>
>
> Russ
>
> 
>
>
>
> Stephen Farrell articulated a concern with that approach - namely, that if
> we are relying on a setting that is meant to ensure both parties must be
> aware that static DH is in use, then a bad actor would find ways to
> suppress that notification. In your proposal, Russ, the notification
> mechanism would take the form of an extension... so I think we would need
> to understand what the failsafe is, for instance if that extension is
> disabled, or not present, in a given deployment of TLS.
>
>
>
> There's an implicit assumption about the threat model, too, which I just
> want to call out. The assumption is that a bad actor would suppress the
> notification so that the client is not aware that static DH is in use. For
> completeness, should we also consider whether there are attacks in which
> it's the *server* whose notification is suppressed? (I can't think of such
> an attack, off the top of my head, but then, that's probably why I'm not a
> hacker. ;^, )
>
>
>
> Best wishes,
>
> Robin
>
>
>
> Robin,
>
>
>
> With respect to your threat concerns, can you be more clear about the
> threats you’re considering? Here are a few things that come to mind:
>
>
>
>1. TLS Server has all of the decrypted data and can provide that to a
>third party (whether compelled or otherwise) without any indication to the
>TLS client. This seems true TLS 1.3 today.
>2. TLS Server has their ephemeral DH keys and session keys and can
>provide them to a third party without any indication to the TLS client.
>This seems true with TLS 1.3 today.
>3. TLS Server can create a TLS server implementation that uses static
>DH keys and provide them to a third party. The client can use methods to
>detect this (though there are measures and countermeasures here). This is
>true seems TLS 1.3 today.
>4. TLS Client has all of the decrypted data and can provide that to a
>third party (whether compelled or otherwise) without any indication to the
>TLS server. This seems true in TLS 1.3 today.
>5. TLS Client has their ephemeral DH keys and session keys and can
>provide them to a third party without any indication to the TLS server.
>This seems true with TLS 1.3 today.
>
>
>
> I believe Russ was outlining a method where an extension would be added to
> TLS 1.3 that would provide for delivery of a decryption key to a third
> party during the handshake (correct me if I got that wrong, Russ). Because
> it would be during the handshake, it would seem to be visible to the TLS
> Client—in fact, the client would have to include the extension to begin
> with. If the TLS client saw the extension and did not consent, it could
> abort the connection. If the TLS Server were attempting to provide access
> to the exchanged data to a third party, it would seem they could use 1, 2,
> or 3 above and not have to go to the trouble of attempting to subvert the
> mechanism that Russ proposes (and others have previously proposed).
>
>
>
> Can you clarify?
>
>
>
> Paul
>
> ___
> 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] Is there a way forward after today's hum?

[Ted Lemon]

I think that's okay, since this is only for use in applications where both
parties are in on the deal. But the problem with the static ecdh proposal
is the the server is not compelled to reveal that it is doing it.

On Jul 20, 2017 8:01 AM, "Russ Housley"  wrote:

> Ted, if we use a new extension, then the server cannot include it unless
> the client offered it first.  I am thinking of an approach where the server
> would include information needed by the decryptor in the response.  So, if
> the client did not offer the extension, it would be a TLS protocol
> violation for the server to include it.
>
> Russ
>
>
> On Jul 19, 2017, at 1:14 PM, Ted Lemon  wrote:
>
> Provably involved, or involved setting an evil bit?
>
> On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley 
> wrote:
>
>> The hum told us that the room was roughly evenly split.  In hind sight, I
>> wish the chairs had asked a second question.  If the split in the room was
>> different for the second question, then I think we might have learned a bit
>> more about what people are thinking.
>>
>> If a specification were available that used an extension that involved
>> both the client and the server, would the working group adopt it, work on
>> it, and publish it as an RFC?
>>
>> I was listening very carefully to the comments made by people in line.
>> Clearly some people would hum for "no" to the above question, but it
>> sounded like many felt that this would be a significant difference.  It
>> would ensure that both server and client explicitly opt-in, and any party
>> observing the handshake could see the extension was included or not.
>>
>> Russ
>>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Ted Lemon]

So is it an accurate assessment that the reason you aren't using ipsec fur
this use case is that the APIs suck and your engines don't support them?

On Jul 19, 2017 8:41 PM, "Roland Dobbins"  wrote:

> On 19 Jul 2017, at 20:37, Blumenthal, Uri - 0553 - MITLL wrote:
>
> I keep telling that this pool is drying up.
>>
>
> The organizations who need this the most are already working in all-crypto
> environments.  Nothing about that pool is going to change.
>
> ---
> Roland Dobbins 
>
> ___
> 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] datacenter TLS decryption as a three-party protocol

[Ted Lemon]

Sorry, the more I think about how to do this in a way that doesn't make
things worse, the less faith I have that it is possible.   But if you know
of a way to do it, I certainly don't oppose you doing it.   I'm not an
expert: the fact that I don't see how to do it doesn't mean it can't be
done.

On Wed, Jul 19, 2017 at 7:45 PM, Colm MacCárthaigh 
wrote:

>
>
> On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon  wrote:
>
>> The problem is that the actual solution to this problem is to accept that
>> you aren't going to be able to decrypt the streams, and then figure out
>> what to do instead.   Which is work the proponents of not doing that are
>> not interested in doing, understandably, and which is also not the work of
>> this working group.
>>
>> I'm skeptical that there is a way for this working group to solve the
>> proposed problem, but if there is, it involves figuring out a way to do
>> this that doesn't make it easy to MiTM *my* connections, or, say, those
>> of activists in dangerous places.
>>
>
> I find this a very bizarre outcome that works against our collective
> goals. If there is no mechanism at all, then it is quite likely that
> organizations will use static-DH or stay on TLS1.2. Those are bad options,
> in my opinion, because there's no signaling or opt-in to the client. We can
> do much better than that.  Client opt-ins are far from academic. For
> example, browser's incognito modes may refuse to support such sessions, if
> they knew what was going on.
>
> It's also bad if organizations end up deploying static-DH and that means
> we can't do things like checking for changing DH parameters.
>
> It seems like we would be rejecting a good opportunity to make what the
> network operators want work in a better and more secure way, while making
> it harder for passive observers and coercive authorities, to use the same
> mechanism for other purposes. What do we gain? beyond a hollow moral
> victory.
>
> --
> Colm
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Ted Lemon]

The problem is that the actual solution to this problem is to accept that
you aren't going to be able to decrypt the streams, and then figure out
what to do instead.   Which is work the proponents of not doing that are
not interested in doing, understandably, and which is also not the work of
this working group.

I'm skeptical that there is a way for this working group to solve the
proposed problem, but if there is, it involves figuring out a way to do
this that doesn't make it easy to MiTM *my* connections, or, say, those of
activists in dangerous places.

On Wed, Jul 19, 2017 at 7:33 PM, Stephen Farrell 
wrote:

>
>
> On 19/07/17 17:58, Benjamin Kaduk wrote:
> > On 07/19/2017 11:49 AM, Stephen Farrell wrote:
> >>
> >> On 19/07/17 14:09, Benjamin Kaduk wrote:
> >>> As Stephen noted in his presentation, a lot of the proposals for
> passive
> >>> decryption can be seen as trying to turn TLS from a two-party protocol
> >>> into a three-party protocol.  Which is probably the right way to think
> >>> about it, even when all (three) parties are within the same
> >>> administrative domain.
> >>>
> >>> Stephen also said something about it being hard to shoehorn a
> >>> three-party protocol into the API for a two party protocol.  But
> >>> depending on the specifics, maybe it's not so bad.  For example, if the
> >>> only semantics you need are a new API for "this is the list of third
> >>> parties I authorize to wiretap this connection", the scope seems fairly
> >>> limited.
> >> I would question the size of the set of applications for which the
> >> semantics of such a list/interface could make sense. For example,
> >> asking a person if they're ok with some random IPv6 address spying
> >> on a TLS session makes zero sense for example.
> >>
> >
> > Sure, some random IPv6 address makes no sense, and is not
> > cryptographically bound to anything.
> > On the other hand, "this (semi-)static DH key is one currently used by
> > my enterprise's network monitoring system, and is allowed to read my
> > traffic" seems closer to what is being asked for.
>
> I don't know how that kind of identifier can be made meaningful
> for almost any application where the identifier is not already
> meaningful, and in many such cases I would guess there are
> already hop-by-hop behaviours where TLS is not e2e for the
> application layer (MTAs etc.) But sure, someone could do the
> work to describe some applications that might have a need for
> a multiparty security protocol like that I guess. As I said,
> my guess is that the size of that set of applications is small.
>
> >
> > As has been said downthread, the recommendation is not "you should
> > always use this thing", it's "you should do TLS 1.3 without backdoors,
> > but if you really need to, this is a way to do so with known and limited
> > properties".
>
> I can see why people might consider that some kind of compromise
> that's less bad, but I think searching for "less bad" is not at all
> the right approach. I don't mean that we oughtn't investigate
> possible scenarios, but searching for a compromise is not in itself
> a good goal here.
>
> Cheers,
> S.
>
> >
> > -Ben
> >
> > -Ben
> >
>
>
> ___
> 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] Is there a way forward after today's hum?

[Ted Lemon]

Provably involved, or involved setting an evil bit?

On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley  wrote:

> The hum told us that the room was roughly evenly split.  In hind sight, I
> wish the chairs had asked a second question.  If the split in the room was
> different for the second question, then I think we might have learned a bit
> more about what people are thinking.
>
> If a specification were available that used an extension that involved
> both the client and the server, would the working group adopt it, work on
> it, and publish it as an RFC?
>
> I was listening very carefully to the comments made by people in line.
> Clearly some people would hum for "no" to the above question, but it
> sounded like many felt that this would be a significant difference.  It
> would ensure that both server and client explicitly opt-in, and any party
> observing the handshake could see the extension was included or not.
>
> Russ
> ___
> 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] datacenter TLS decryption as a three-party protocol

[Ted Lemon]

Bear in mind that what we (or at least I) want out of not publishing a spec
is that this technology not be present by default in TLS implementations.
If someone wants to maintain a set of patches, there's not much we can do
about it, and I don't honestly care *because* there isn't much that we can
do about it.   What I do not want to see is *the IETF* recommending this
solution.

It would be very nice if the people who are hot on a solution to this
problem were willing to do the work to do the three-way protocol.   But the
purpose of pointing out that that is the right solution is to say "if you
want to solve this problem in the IETF, here is what we could do that might
get IETF consensus."

On Wed, Jul 19, 2017 at 3:51 PM, Kyle Rose  wrote:

> On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon  wrote:
>
>> This is exactly right.   We have a *real* problem here.   We should
>> *really* solve it.   We should do the math.   :)
>>
>
> Is there appetite to do this work? If we restrict this to two paths, one
> of which is spending years designing and implementing a new multi-party
> security protocol, the other of which is silently and undetectably (at
> least on private networks) modifying the standardized protocol for which
> lots of well-tested code already exists... my money is on the latter
> happening.
>
> In every decision we make with respect to the static DH approach, we have
> to keep in mind that this change can be implemented unilaterally, i.e.,
> without any modifications for interop. Consequently, I think the work we
> really need to do is to design and implement a FS-breakage detector so we
> can at least tell when this is happening on the public internet. Beyond
> that, the best we can really do is ask implementors to be polite and
> intentionally make their implementations not interoperate silently with TLS
> 1.3.
>
> Kyle
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Ted Lemon]

This is exactly right.   We have a *real* problem here.   We should *really*
solve it.   We should do the math.   :)

On Wed, Jul 19, 2017 at 3:09 PM, Benjamin Kaduk  wrote:

> As Stephen noted in his presentation, a lot of the proposals for passive
> decryption can be seen as trying to turn TLS from a two-party protocol into
> a three-party protocol.  Which is probably the right way to think about it,
> even when all (three) parties are within the same administrative domain.
>
> Stephen also said something about it being hard to shoehorn a three-party
> protocol into the API for a two party protocol.  But depending on the
> specifics, maybe it's not so bad.  For example, if the only semantics you
> need are a new API for "this is the list of third parties I authorize to
> wiretap this connection", the scope seems fairly limited.
>
> Another thought spawned from today's session is that, given concerns about
> preventing/noticing if schemes intended for the datacenter leak out onto
> the internet, it's not really clear that "minimizes changes to the wire
> protocol" should be considered a benefit of proposals in this space.  If
> there are clear changes to the wire protocol, that makes it easy to detect
> when the scheme is in use.
>
> -Ben
>
> ___
> 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] draft-green-tls-static-dh-in-tls13-01

[Ted Lemon]

What it means for users to be denied the benefits of TLS 1.3 is that they
don't get, for example, perfect forward secrecy.  Since the proposal was to
do away with that anyway, but for all users, not just some users, that
doesn't seem like it is better than just continuing to use TLS 1.2.  It's
already possible to configure both TLS 1.2 clients and servers to not use
obsolete encryption algorithms.  Most of the other improvements in TLS 1.3
probably don't apply to the use cases you are talking about.

So no, it's not self-defeating to say "continue using TLS 1.2 for now in
your use case while we study this issue and try to figure out if there's a
way forward that doesn't break TLS 1.3."

On Sun, Jul 16, 2017 at 11:04 AM, Colm MacCárthaigh 
wrote:

>
>
> On Sun, Jul 16, 2017 at 1:52 AM, Salz, Rich  wrote:
>
>> I would also like to understand why TLS 1.2 is not sufficient for, say,
>> the next five years.
>>
>
> It probably is ... but isn't that the problem? If the answer is "Just let
> them stay on TLS1.2", I find it very hard to interpret the arguments
> against all of this as resulting in anything other than grand-standing.
> Clearly the users would be no better off, and also end up denied the other
> benefits of TLS1.3.
>
> This seems self-defeating, when there is so easy a path that may improve
> things for all cases (forbid static-DH, add an opt-in mechanism instead).
>
> --
> Colm
>
> ___
> 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] draft-green-tls-static-dh-in-tls13-01

[Ted Lemon]

On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael 
wrote:

> Your first sentence illustrates the disconnect between the Enterprise
> perspective and what many at IETF are saying.
>
> That being the unencrypted stream is available to the endpoints.   IT IS
> NOT. When you run a packet trace at the endpoint,  you will see
> encrypted payloads and will need the keys to decrypt.
>
> So you can collect packet trace information at thousands or nodes,  or you
> can collect packet traces from network taps.   You still need the keys to
> derive meaningful diagnostic and monitoring information.
>

I agree that we have illustrated the disconnect here, in some sense.
However, from my perspective, what I see is that there is a problem: you
need to be able to look inside the stream.   I think we agree that this is
the problem.

There is a further problem: you have a set of tools that solves this
problem in a particular way, and for the moment, you are stuck with those
tools.   This is where I think the disconnect starts.   I am not
disagreeing with you that, for the moment, you are stuck with these tools.m
  But, I *am* disagreeing with you on the conclusion that this situation
leads to.

To me, it leads to the conclusion that you need two things.   First, you
need a plan for how to survive the situation you're stuck in right now.
Second, you need a plan for how you're going to approach this when next you
upgrade your infrastructure.  If I were in your position, my plan for the
first part would be to use TLS 1.2.   You already have what you want, and
you control the endpoints.   If it ain't broke, why fix it?

What I think is urgent, though, is that you be planning for how you're
going to handle this going forward.   There are a number of ways of doing
it.   One way would be to keep an appropriately-scaled log of keys.  If you
just need to look at active streams, it would be a rolling log, and your
snooping device would, when asked to snoop a stream, get the key.   This is
an improvement over TLS 1.2, because it increases accountability: you have
to ask for a key to decrypt a particular conversation, so it is known that
you decrypted that conversation.   Of course, if you are decrypting _every_
conversation, that's not so great.   Of course, key exfiltration is an
attack surface, but so is the static key.   Better get that right.

The other thing you can do is to do proper tooling on your servers, so that
you *can *access the raw stream.   This would require different tooling
than you have now, but there's no technical barrier to doing it.

Now, it's possible that either of these solutions would be less secure than
using a static key.   But I don't hear you arguing that.   You're still
back on tactics: how do I do what I need to do with the tools I have.   The
answer is, use TLS 1.2 until you upgrade.   Put the time in to shave off
all the attack surfaces from your TLS 1.2 installations that TLS 1.3 shaves
off--disable the deprecated algorithms, for example.  It's your site, you
control the endpoints, this shouldn't be a problem.   But basically, just
keep doing what you are doing for now.

Maybe this is a naive suggestion on my part, but what I haven't been
hearing in this discussion is serious consideration of the tactical problem
and the strategic problem.   What I've been hearing is "forget about
strategy, we want tactics."
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Ted Lemon]

I was at at least one of those presentations recently, and while it
certainly convinced me that there was a problem in the short term, it did
not convince me that the points you are making are inherent problems with
the technology.   That is, the problem is not that there is no way to
achieve what you intend without static keys, but rather that it would be
difficult in the context of some existing deployed architectures to achieve
what you intend without static keys.  I agree that this is a problem.

On Sat, Jul 15, 2017 at 11:16 AM, Dobbins, Roland 
wrote:

>
>
> > On Jul 15, 2017, at 16:05, Dobbins, Roland  wrote:
> >
> > There is plenty of information on these topics available on the Internet
> today.
>
> At the risk of self-replying, it should also be noted that highly
> informative discussions of these challenges, & detailed presentations
> thereof, have taken place in WG meetings at previous IETF meetings.
>
> There has also been ample time since those discussions & presentations to
> gain additional understanding & insight.
>
> ---
> Roland Dobbins 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Ted Lemon]

On Sat, Jul 15, 2017 at 11:05 AM, Dobbins, Roland 
wrote:

> There is plenty of information on these topics available on the Internet
> today.  Search engines exist.  It isn't reasonable to expect a class to be
> held on the basics of network security & troubleshooting tools & techniques
> on this WG list.
>

Roland, the reason that I made that particular comment was to try to show
you that the position you have taken here is untenable.   There is no such
textbook.   There is no consensus that what you have said is true.   I
understand that you believe it is true, and I'm sure it's frustrating that
not everybody believes it.   But if you want everybody to believe it, you
have to make your case, and not just hand-wave when I ask you for specifics.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Ted Lemon]

On Sat, Jul 15, 2017 at 10:22 AM, Dobbins, Roland 
wrote:
>
> I think that your first and third points are actually non-sequiturs: the
> unencrypted stream is available to the entities controlling either
> endpoint, not just the log.
>
> This assertion is both incorrect & incomplete in its scope.
>

Okay.   What did I miss?


> There is no *technical *reason that in-flight capture is required to
> address those two points.
>
> This assertion is factually incorrect.  There are quite frequently reasons
> to have both visibility & the ability to intercede into the traffic in
> question at one or more specific points in the network topology *between*
> endpoints.
>

For example?


> This is network security & troubleshooting 101.
>

Great!   Can you point me to the textbook for that class, because I must
have missed it!


> No - the attempt to denigrate & dismiss real-world technical operational
> requirements is invalid, as is the dismissal of the administrative context
> of actual network operators in the real world.
>

I believe that I merely described the situation.   If you think my
description was not accurate, then it would be great if you could explain
in what way it was not accurate.   I realize that institutional problems of
the sort that I described do exist, are real, and do cause real pain for
ops people--that's not my point.   My point is that what you are describing
sounds like it's a layer 9 problem.   If it's not, I'm genuinely not seeing
it.   Rather than being offended at what you say is my mischaracterization
of the situation, could you just point out where the mischaracterization
lies?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Ted Lemon]

I think that your first and third points are actually non-sequiturs: the
unencrypted stream is available to the entities controlling either
endpoint, not just the log.   There is no *technical *reason that in-flight
capture is required to address those two points.

Regarding your second point, this seems to be the real key that is
motivating you to make the first and third points.   If I may paraphrase,
the problem you are attempting to address is that in some situations two
sub-organizations both of which are in principle responsible to a larger
organization nonetheless are unable to cooperate due essentially to a
failure by one sub-organization to take seriously the responsibilities of
the other sub-organization, and the failure of the organization to which
they are both subordinate to successfully encourage cooperation on the part
of the intransigent sub-organization.   Did I paraphrase that correctly?

On Sat, Jul 15, 2017 at 9:54 AM, Dobbins, Roland  wrote:

>
>
> > On Jul 15, 2017, at 14:48, Ted Lemon  wrote:
> >
> > In the event that it is not feasible for an operator to obtain the
> plaintext of a message without the key, isn't that because they don't
> control either endpoint?
>
> First of all, what goes on the wire is often contextually different  (and
> probatively so) from what's recorded in abstract log files.
>
> Secondly, administrative divisions within a single organization often
> impede cooperation between those tasked with securing & troubleshooting
> communications and those who 'own' the assets in question.
>
> Thirdly, for both security & troubleshooting applications, the hard
> requirement is for real-time visibility & possible intercession, not ex
> post facto analysis.
>
> ---
> Roland Dobbins 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Ted Lemon]

In the event that it is not feasible for an operator to obtain the
plaintext of a message without the key, isn't that because they don't
control either endpoint?   If so, why would it be their responsibility to
obtain the plaintext?   It should be the responsibility of the controller
of one of the endpoints.

If they do control one of the endpoints, then they don't need the key, or
rather, they have it.   So it is not our problem to provide them with a way
to change it less frequently, which is really what this proposal boils down
to.

Can you give an example of a use case for this proposal where what I just
said is not true, and explain why it is not true for that use case?   Sorry
if I am being dense, but I just don't understand why this is an issue.

On Sat, Jul 15, 2017 at 9:42 AM, Dobbins, Roland  wrote:

>
>
> > On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor 
> wrote:
> >
> > Could you point to an example of any regulation that requires plaintext
> > from network capture specifically?
>
> It often isn't feasible to obtain the plaintext any other way in a given
> circumstance.
>
> Not to mention the security & troubleshooting applications which require
> insight into the cryptostream on the wire.
>
> ---
> Roland Dobbins 
> ___
> 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] draft-green-tls-static-dh-in-tls13-01

[Ted Lemon]

It seems to me that all the use cases you just described require the
*client* to have a static key, since the client is the thing that the
operator controls. If the client uses an unknown key, is malware or
unauthorized.

On Jul 14, 2017 20:42, "Roland Dobbins"  wrote:

> On 15 Jul 2017, at 1:01, Melinda Shore wrote:
>
> It might make sense to kick it over to ops for a discussion with people
>> whose meat and potatoes is monitoring, management, and
>> measurement.
>>
>
> As someone who is ops-focused, I think this is an excellent suggestion!
>
> There have been several assertions posted to the list recently regarding
> various aspects of security and their intersection with encryption.  It may
> be useful to take a moment and clarify a few of them.
>
> With regards to DDoS mitigation as it relates to encrypted attack traffic,
> only a subset of attacks in a subset of situations can actually be
> adequately mitigated without full visibility into (and often the ability to
> interact with) the traffic within the cryptostream.  There are various ways
> to approach this issue, including full session termination and
> 'transparent' detection/classification, the latter of which isn't of course
> feasible in a PFS scenario.  Each of these general approaches has its
> advantages and drawbacks.
>
> Very specifically, fingerprints of encrypted streams are not in fact
> adequate for DDoS defense; again, they're only useful for a subset of
> attack types in a subset of situations.
>
> In the case of detecting and classifying hostile activity within a given
> network - which isn't limited to malware spreading, but includes data
> extraction, attempts at unauthorized access, attempts at subverting
> additional devices, et. al. - the same basic caveats apply.  It is not in
> fact possible to adequately detect and classify all, or even a large
> subset, of hostile network traffic without visibility into the
> cryptostream.  There are some gross behaviors which can be
> detected/classified whilst standing outside the tunnel, but assertions to
> the effect that all or most of what's required in this arena is possible
> without visibility (one way or another) into the relevant encrypted traffic
> are incorrect.
>
> It's also important to understand that inserting proxies into multiple
> points of a network topology is not cost-free, nor an unalloyed good.  It
> is impractical in many circumstances, and has highly unwelcome side-effects
> in many more, including a negative impact on reliability, performance, and
> availability, as well as broadening the potential attack surface.  Endpoint
> monitoring does not scale well, is often impossible to implement due to
> both technical and administrative challenges - and one can't really trust
> endpoints to self-report, anyways, as they can be subverted.
>
> In many scenarios, one form or another of network-based visibility into
> encrypted traffic streams within the span of administrative control of a
> single organization is legitimate, vital and necessary.  It is not
> 'wiretapping', any more than tools such as tcpdump or telemetry formats
> such as IPFIX and PSAMP can be categorized as 'wiretapping'.  The fact is,
> the availability, confidentiality, and integrity of systems, applications,
> and networks that everyone on this list relies upon is highly dependent
> upon the ability of organizations to have visibility into encrypted traffic
> streams within their own networks, for purposes of security as well as
> testing and troubleshooting.
>
> How this can be accomplished is a matter for further discussion.  But it's
> important that everyone focused on this topic understands that it is simply
> not possible to successfully defend against many forms of DDoS attacks nor
> to detect and classify hostile network traffic in the context of encrypted
> communications without visibility into the traffic in question, via some
> mechanism.  The same goes for troubleshooting complex problems.
>
> Those with operational experience at scale will likely recognize and
> acknowledge the difficulties and challenges noted above; others may wish to
> consider these factors and their impact on the operational community and
> the networks, services, and applications for which they are responsible,
> and upon which we all depend, every day.
>
> ---
> Roland Dobbins 
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

[Ted Lemon]

I have two working groups already in the monday slot.   I doubt I'm unique
in this.   It seems like you should put the important business in the slot
that was previously scheduled, and the overflow into the Monday slot.
It's hard to imagine how a discussion of the wiretapping thing could be
anything other than a dance at the mic, full of sound and fury, signifying
nothing.

On Fri, Jul 14, 2017 at 5:13 PM, Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> +1
>
> Current agenda does look backwards. IMHO, do as Stephen suggested.
>
> Regards,
> Uri
>
> Sent from my iPhone
>
> > On Jul 14, 2017, at 11:10, Stephen Farrell 
> wrote:
> >
> >
> > Hiya,
> >
> >> On 14/07/17 15:51, Sean Turner wrote:
> >> Please let us know your thoughts.
> >
> > 80 minutes for wiretapping is too much. Zero would
> > be better. But if not...
> >
> > I'd suggest: 10 minutes for draft-green, 10 minutes
> > to describe issues with that (i.e. the slot for which
> > I continue to ask) and then 10 minutes discussion. If
> > we assume the folks in the room have read the list and
> > the draft that should be plenty.
> >
> > If we assume they haven't read the list, then it's more
> > important that the counter-arguments be given sufficient
> > time.
> >
> > So your draft agenda seems to get that backwards to me,
> > in that it allocates 40 minutes for a sales-pitch and
> > then 40 minutes where we bitch about that at the mic
> > interspersed with proponents repeating bits of the sales
> > pitch. That might be more amusing for us all, but seems
> > like a worse use of time to me.
> >
> > Cheers,
> > S.
> >
> >
> >
> > ___
> > 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] chairs - please shutdown wiretapping discussion...

[Ted Lemon]

On Jul 12, 2017, at 10:35 AM, Kyle Rose  wrote:
> Which will have zero impact on pervasive surveillance until some government 
> decides they want to use this mechanism or something like it and mandates 
> that it be implemented universally within their borders. Then it will appear 
> in short order, even if the government has to hire their own code monkeys to 
> do it, at which point it will continue to have zero impact on pervasive 
> surveillance.

Right, and then there will have to be a public debate.   I expect that exactly 
what you describe will happen or be attempted in various jurisdictions.   
That's okay.   Requiring this stuff to be done publicly is better than it 
happening in secret.

(Is this conversation still really useful?   I don't think I'm saying anything 
you don't already know, so I don't know why you made this point.)

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

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

[Ted Lemon]

On Jul 12, 2017, at 10:32 AM, Richard Barnes  wrote:
> Oh, come on.  You've never seen code in a library that implements something 
> that's not in an IETF RFC?  

Of course I have.   I think that putting a warning in the TLS 1.3 spec as 
Christian suggested will mean that the code won't appear in places where there 
isn't a strong use case for it.   It may well appear in places where there is a 
strong use case, but anything open source is going to face a stiff headwind in 
terms of implementing this, and that's what I'm suggesting we encourage.   If 
it doesn't show up in openssl, gnutls or boringssl, it's a much smaller 
problem.   We can't actually stop it happening—I'm just arguing for not making 
it convenient.

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

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

[Ted Lemon]

On Jul 12, 2017, at 10:18 AM, Kyle Rose  wrote:
> We need to dispel the myth that mere inaction on our part will on its own 
> prevent implementation of these mechanisms, if for no other reason but to 
> redirect energy to the political arena where the pervasive monitoring battles 
> *are* actually fought.

Inaction on our part will prevent the code from going into the common 
distributions.   That's not worthless.

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

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

[Ted Lemon]

On Jul 12, 2017, at 8:24 AM, Kyle Rose  wrote:
> Much of this conversation seems to conflate wiretapping with collaboration. 
> 2804 has a clear definition of wiretapping:

The problem is that in modern times we can't assume that collaboration is 
consensual, so the rules in RFC2804 aren't as applicable as they were.   
There's no way to have the consensual collaboration use case without enabling 
the non-consensual use case.   Anything we do that makes it easier to enable 
the non-consensual use case is a bad idea.   So in my mind RFC 7258 is more 
applicable here than RFC 2804.

The problem with arguing this on the basis of whether or not there is a 
non-wiretapping operational use case for this is that there is a legitimate 
non-wiretapping operational use case here.   As I understand it, the motivation 
for doing this is to be able to avoid deploying different pieces of DPI 
hardware differently in data centers.   That's a legitimate motivation.   The 
problem is that (IMHO) it's not a good enough reason to standardize this.

I would much rather see people who have this operational use case continue to 
use TLS 1.2 until the custom DPI hardware that they are depending on is 
sufficiently obsolete that they are going to remove it anyway; at that point 
they can retool and switch to TLS 1.3 without needing support for static keys.  
 The advantage of this is that simply using TLS 1.2 signals to the client that 
the privacy protections of TLS 1.3 are not available, so you get the consensual 
aspect that Tim was arguing for without having to modify TLS 1.3.

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Ted Lemon]

To paraphrase (and forgive me for being a bit brutal here), you have no
basis for what you said other than handwaves and something from a Cisco
marketing presentation?

That is, "the odds are better if..." is a handwave, and not clearly true.
"Malware could be caught ... with multiple inspection points..." is only
true if those inspection points are able to detect the malware.   Phoning
home is actually pretty detectable using DNS snooping--you don't need deep
packet inspection, and it's orders of magnitude cheaper.

On Tue, Jul 11, 2017 at 7:59 PM, Steve Fenter 
wrote:

>
>
> > On Jul 11, 2017, at 2:15 PM, Stephen Farrell 
> wrote:
> >
> >
> > To add to Ted's clarification requests:
> >
> >> On 11/07/17 19:39, Steve Fenter wrote:
> >> Network security monitoring is not just monitoring traffic that
> >> results from communications with customers and partners.  All it
> >> takes is for one user to click on a phishing email and there is
> >> malware inside the enterprise.  Once this happens, TLS becomes the
> >> enemy, because 30% of malware is TLS encrypted, and any TLS features
> >> intended to thwart payload inspection work against the enterprise.
> >
> > I'd appreciate a citation for that 30% figure.
>
> 30% came from Cisco Systems at a recent Cisco Live conference.  Their
> numbers indicated 10% in 2015 and 30% today
> >
> > And if you had one an estimate for how much malware does it's own
> > obfuscation or home-grown crypto in addition or instead of using TLS.
> > The reason to ask is that as soon as malware does that then you
> > are back to analysis based on ciphertext only. From descriptions
> > of advanced attack schemes, they do seem to do both when calling
> > home or exfiltrating data. In which case I think your argument
> > falls.
>
> I don't have any numbers for home-grown crypto.  I would think the odds
> are better for the enterprise if they can decrypt and inspect whatever
> portion is TLS.
> >
> >> Malware does not always phone home out to the Internet on day 1 of
> >> infection.
> >
> > In what circumstance will malware phone home to a TLS server that
> > is playing your wiretap game? That seems utterly illogical but
> > maybe I'm missing a reason why someone's malware will use TLS to
> > talk to a server that is controlled by the victim network as part
> > of phoning home. Please clarify.
>
> Phone home would have to be caught by an inline solution on the way out
> the Internet.  I was just suggesting that malware could be caught earlier
> in the process with multiple inspection points throughout the enterprise.
> >
> > S.
> >
>
> ___
> 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] chairs - please shutdown wiretapping discussion...

[Ted Lemon]

On Jul 11, 2017, at 4:58 PM, Ted Lemon  wrote:
> On Jul 11, 2017, at 4:31 PM, Stephen Farrell  <mailto:stephen.farr...@cs.tcd.ie>> wrote:
>> I'd bet folks would invent proprietary
>> ways of avoiding detection, that deviate from the "standard"
>> and that perhaps make crypto worse all around. Say by deriving
>> secrets from some function f(exfiltrated-secret, time, count)
>> for a small counter or some such and having the decryptor of
>> the wiretapped packets hunt a bit for the right key.
> 
> Hm, well, but that would be catnip for security researchers, particularly if 
> it weakened the key.   But yeah, you're right, that does make detecting the 
> attack possibly impractical aside from as a large research project.

On second thought, this suffers from the same problem as the many-static-keys 
problem: there are too many moving parts.   This requires all clocks on all 
servers and interceptors to be in perfect sync, not just close, or else 
potentially halves the performance during clock skew  overlap periods.   It 
requires every server and interceptor to implement the same algorithm.   And 
you still have to distribute the information from which the key is derived.

So again, yes, you can do this particular mitigation strategy.   But it's 
expensive, and so nobody's going to do it if they have a better choice.   It's 
cheaper to just re-tool to support TLS 1.3.   As long as the solution isn't 
standard, it's only going to appeal to a _very_ limited audience, if there's 
any audience for it at all.   E.g., consider trying to deploy something like 
this on a country-wide scale.   You're just going to exfiltrate every key 
instead—it's cheaper.

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

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

[Ted Lemon]

On Jul 11, 2017, at 4:31 PM, Stephen Farrell  wrote:
> I'd bet folks would invent proprietary
> ways of avoiding detection, that deviate from the "standard"
> and that perhaps make crypto worse all around. Say by deriving
> secrets from some function f(exfiltrated-secret, time, count)
> for a small counter or some such and having the decryptor of
> the wiretapped packets hunt a bit for the right key.

Hm, well, but that would be catnip for security researchers, particularly if it 
weakened the key.   But yeah, you're right, that does make detecting the attack 
possibly impractical aside from as a large research project.

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

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

[Ted Lemon]

On Jul 11, 2017, at 3:59 PM, Stephen Farrell  wrote:
> I can't see that happening. Once the first example.com  
> is called
> out for using this, others will make their list longer or take
> other approaches, e.g. use one exfiltrated private value as a
> seed for others via some proprietary mechanism.

Ah, you mean the first time the attack happens in the wild.   Sure, I can see 
that, but that gains the attacker no real advantage over just exfiltrating all 
the keys.   Once you make the number of keys large enough to be hard to detect, 
you have a really big key management problem.   Might as well just make it a 
logging problem.   So we've forced them to do the thing that makes pervasive 
monitoring hard and point monitoring easy.   I call that a win.

Note that if we took a distributed approach to discovering key reuse, it would 
be almost impossible for any large site to conceal.

> Actually, that calls out another reason to not standardise or
> further develop this - any such standard is either undetectable
> or leads to deployments deviating from the standard to become less
> detectable - both undesirable outcomes. That latter case also
> destroys the "but we should scrutinise it" argument IMO as the
> "it" will change to be undetectable and not the "it" that was
> ostensibly scrutinised.

I'm not arguing in favor of standardizing this.   I think it's an attack, and 
there is a countermeasure which is worth documenting, and possibly worth 
deploying.   If the working group does a CFA on the draft, I will argue against 
adoption.   I like Christian's approach—document this in an appendix, _as an 
attack_.


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

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

[Ted Lemon]

On Jul 11, 2017, at 3:40 PM, Stephen Farrell  wrote:
> It'd seem possible for a server to hold a rather long
> list of re-used static DH values and unlikely for normal
> clients to detect those.

Bearing in mind that the current proposal is intended to perpetuate a 
well-established use model so as to avoid having to re-tool, I don’t think this 
is a real concern. In practice I expect that the number of keys used in such a 
system will be small because the operational burden of making it large will be 
enough to motivate re-tooling. 

So in practice I would expect a client to be able to cache enough keys to 
notice this attack, if the user were motivated, or the client vendor considered 
this to be a credible threat worth addressing. 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Ted Lemon]

On Jul 11, 2017, at 2:39 PM, Steve Fenter  wrote:
> Network security monitoring is not just monitoring traffic that results from 
> communications with customers and partners.  All it takes is for one user to 
> click on a phishing email and there is malware inside the enterprise.  Once 
> this happens, TLS becomes the enemy, because 30% of malware is TLS encrypted, 
> and any TLS features intended to thwart payload inspection work against the 
> enterprise.

I realize that you are making a substantive comment here and might not welcome 
a sales pitch, but FWIW there are ways of addressing this that don't involve 
examining each stream, and are likely as effective.   E.g., malicious domain 
redirect based on the domain name in the URL.   This is a lot cheaper than 
doing decryption and inspection of the contents of every TLS stream.   It also 
allows for other methods than payload analysis for detecting probably 
malware—e.g., pattern analysis.   I'm pretty sure that Stephen will tell you 
that this is an attack as well, and he's not wrong, but it has the virtue of 
not requiring that TLS be broken.

Also, please note that the proposal you are referring to does not solve this 
problem at all, unless the malware is already on a server on your network 
(which is the scenario you are describing).   If that's the case, why is TLS 
intercept the most cost effective way to detect this malware?   It seems to me 
that it would be a lot easier to just scan the file on the server before making 
it available for download.

Can you explain why that's not the right solution for this particular use case?

Also, although there was a lot of talk about how you need to do 
decryption-and-inspection rather than using proxies for performance, that 
actually just doesn't make sense.   Is it because the proxy is too close to the 
edge, resulting in trombone routes?   Otherwise I don't see how it could 
possibly be more efficient to decrypt and eavesdrop than to proxy.   Can you 
explain?

Sorry to hold your feet to the fire, but what you are saying here just doesn't 
make sense to me.

As for threat detection, again I'm not seeing how decryption and packet 
analysis is a win here.   Can you explain?

I see why it's helpful for troubleshooting, although again a proxy would take 
care of that.   But in any case, for the other two examples, it doesn't make 
sense even from a performance perspective.

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

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

[Ted Lemon]

What the draft actually says is that you can install a fixed key on the server 
rather than generating new keys every time, and then that fixed key can also be 
installed on monitoring software.   This is, I believe, the actual intended use 
of the proposal.

It’s also true that you can just exfiltrate every key as it’s generated, but 
that’s not what’s being proposed and would not, I think, suit the needs of the 
operators who are making this proposal.

I don’t see how you could mitigate against deliberate key exfiltration.   At 
some point you really are relying on the security of the endpoint.   But being 
able to detect repeated keys is useful for preventing pervasive monitoring: it 
requires the monitored either to have access to the key generation stream in 
realtime, or to request the key for a particular conversation.

So I think there is some value in defending against this attack.  I look 
forward to seeing a defense that uses perfect forward secrecy and protects 
against key exfiltration.

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

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

[Ted Lemon]

On Jul 10, 2017, at 5:35 PM, Stephen Farrell  wrote:
> Consider SMTP/TLS. Where one MTA on the path supports this.
> Say it's one operated by an anti-spam company for example.
> That is clearly not the sender nor recipient.
> 
> That meets all 4 points in 2804, right?

I don't buy this, Stephen.   The anti-spam company is not an eavesdropper.

What I don't understand about your approach to this draft is that it seems to 
me that the draft is obviously describing an exploit in TLS 1.3, for which a 
mitigation exists: remember keys, and refuse to communicate with an endpoint 
that presents a key you've seen before.

So rather than opposing the publication of the static keys draft, why not work 
on mitigating the attack it describes?   This attack exists whether the static 
keys draft is published or not.

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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Ted Lemon]

On Dec 2, 2016, at 4:10 PM, Peter Gutmann  wrote:
> Ugh, how very geeky,

Really?

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