Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Arnaud.Taddei.IETF]

I appreciate this answer, thank you


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Friday 7 December 2018 23:48, Sean Turner  wrote:

> There is no WG consensus to adopt this draft as no WG adoption call has been 
> made. draft-dkg-tls-reject-static-dh is an individual draft that is currently 
> being discussed on this list; in much the same way 
> draft-green-tls-static-dh-in-tls13 and draft-rhrd-tls-tls13-visibility were 
> individual drafts that were discussed on this list; there was no WG consensus 
> to adopt draft-rhrd-tls-tls13-visibility and there was never a call to adopt 
> draft-green-tls-static-dh-in-tls13.
>
> The chairs have been debating whether draft-dkg-tls-reject-static-dh is in 
> scope or whether the discussion should be moved elsewhere. Parts of this 
> draft we believe are in scope, e.g., providing guidance on handling key share 
> re-use and pitfalls for not following this guidance. (Note that how to handle 
> key share re-use is not the same thing as explicitly prohibiting re-use of 
> keys.) Other parts of the draft contain material for which we did not reach 
> consensus to address, such as Section 3.3 on prohibiting key-share reuse. We 
> are not the protocol police and have recently gotten out of that business, 
> e.g., by removing barriers for cipher suite code points. We do not want to 
> get back in that business.
>
> In order to ensure a focused discussion and avoid rehashing the previous 
> debate regarding draft-rhrd-tls-tls13-visibility, parts of this draft should 
> be rescoped or removed. Authors are free to take this material to an AD and 
> seek sponsorship, or to the ISE/IAB for further guidance.
>
> Cheers,
> Joe, Chris, and Sean
>
> > On Dec 6, 2018, at 21:19, Arnaud.Taddei.IETF 
> > Arnaud.Taddei.IETF=40protonmail@dmarc.ietf.org wrote:
> > I am really surprised how the answers you don't like are systematically put 
> > on denial. Can you explain me what leads you to think that some people here 
> > are not concerned by the list of people you list? this is an assumption and 
> > the wrong assumption.
> > Perhaps on the contrary we are concerned BOTH by what these people endure 
> > but too by what other consistencies are basically removed rights to defend 
> > themselves.
> > As to the marketing aspect frankly this is an invention here and again I 
> > don't see what allows you to paint the answers you don't like because you 
> > don't like.
> > So I could on the contrary hightight the dogmatism that reins here, with a 
> > smell of intimidation, and to some degree the sectarianism back to the 
> > latin roots of the word
> > Regarding Human Rights, we DO care about Human Rights too and fact is that 
> > I had the chance to make more progress in 2 hours than I did in 2 years at 
> > IET and I had the chance to contribute to a magic moment with a Chinese 
> > Organization to comply a technical solution to Human Rights requirements. 
> > You know why? Because we took the time to TALK properly to each other, 
> > understand each other, learn from each other with no intimidation and no 
> > wrong assumptions that 'because we LOOK to be on the wrong side' we are 
> > foolish people, and respect to the fact that not everyone speaks and writes 
> > a proper English and sometimes words are dangerous when we don't know 
> > exactly the semantics in the right context
> > The assumption that you are the only one who cares is tiresome.
> > This group was offered a chance to control the development of a 360 degree 
> > solution for all parties and it was rejected. Fine. The ETSI took it and is 
> > taking its responsibly.
> > I don't know what leads you to think that a model where security resides 
> > only on the 2 ends of the communication IS the answer to all the problems.
> > The recent continuous scandals that are affecting a number of platforms and 
> > destroying trust, privacy and security is leading me to think about why 
> > should I trust this model. By analogy when I see how my body defends itself 
> > against bad stuff, it is using a battery of models, not one model.
> > In any negotiation you can look for what is the right battle, and those who 
> > understand that point will know that the right battle (and the one which is 
> > harder for the opposition) is on providing guarantees. This would have been 
> > a better battle to pick and would have given a chance to work more 
> > collaboratively and not by confrontation.
> > Now I don't understand what leads this group to try now to block the ETSI, 
> > can someone tell me and in particular the chairs if we have a consensus 
> > here?
> > Finally I am calling on the chairs of this group. It was very interesting 
> > to observe the many comments at the last IETF103 about the vile and toxic 
> > atmosphere that prevails here. I have all my time to work in these 
> > conditions but perhaps the chair could try to think about a more positive 
> > atmosphere of work.
> > A bon entendeur 

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Ryan Sleevi]

On Tue, Dec 11, 2018 at 6:58 AM Daniel Kahn Gillmor 
wrote:

> On Sun 2018-12-09 18:35:20 +0100, Kurt Roeckx wrote:
> > On Wed, Dec 05, 2018 at 07:07:30AM +0300, Daniel Kahn Gillmor wrote:
> >> One mitigating factor of the ETSI standard, i suppose, is that the
> >> CABForum's Baseline Requirements forbid issuance of a certificate with
> >> any subjectAltName other than dNSName or iPAddress, so otherName looks
> >> like it must not be issued by standard public CAs.
> >>
> >> top of p. 44 of
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.1.pdf
> >>
> >> Has anyone set up tools to monitor the CT logs for such a sAN to see
> >> whether that element of the BR is being honored?
> >
> > All the linters will give an error about that, see for instance:
> > https://crt.sh/?id=1009623020=x509lint,cablint,zlint
>
> right, so what is to be done about that, when some of these CAs are
> clearly violating the BRs?  Transparency is only as useful as the
> actions we can take once violations are uncovered.  Unactionable
> transparency just sounds like despair to me.  So what's the action?


The same as it is for any misissuance:
1) Report to the CA’s problem reporting mechanism. The  Baseline
Requirements require they provide one in Section 1.5.2 of their CPS (BRs
Section 4.9.3). The CA is obligated to revoke such certificates and,
according to various root policies, report and/or disclose to the root
programs they participate in or publicly.

If you are unsatisfied with the answer you get from the CA, or want to
ensure greater transparency, you can/should also
2) Report to any root programs that trust those CAs.

The example from Kurt is from a CA that is ONLY trusted by Microsoft, and
which other programs have, sometimes explicitly, declined to trust. If CAs
are violating the contractual or public requirements of Microsoft’s root
program, such as the one demonstrated (although notably, it is NOT
displaying the use of this ETSI MITM extension), then that is an
enforcement action for Microsoft, or something for their customers to
respond to if Microsoft is shipping insecure CAs to them.

Your best-best-case is that publicly trusted CAs never issue such
certificates. Your worst-best-case is that the CA has to revoke within 24
hours/5 days of issuance, and that the root program takes the violation
into consideration when evaluating whether to trust that CA. Your
worst-worst case is that the CA ignores the revocation requirements, as
they did the issuance requirements, and that root programs that trust those
CAs fail to take action to ensure consistency among the CAs they trust and
with the requirements.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Salz, Rich]

> All the linters will give an error about that, see for instance:
> https://crt.sh/?id=1009623020=x509lint,cablint,zlint

right, so what is to be done about that, when some of these CAs are
clearly violating the BRs?  Transparency is only as useful as the
actions we can take once violations are uncovered.  Unactionable
transparency just sounds like despair to me.  So what's the action?

The IETF is not the protocol police, nor are we the data-format police as you 
well know.  All we can do is name-and-shame when interop fails.

What are these BRs of which you speak?  Not an IETF spec.  Go report violations 
to the place that wrote them I guess.

I've also heard tell of an anyone-can-join discussion group, 
https://groups.google.com/forum/#!forum/mozilla.dev.security.policy, where 
these kinds of things are discussed.

/r$, yes I know all this.  So does dkg I believe.


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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Daniel Kahn Gillmor]

On Sun 2018-12-09 18:35:20 +0100, Kurt Roeckx wrote:
> On Wed, Dec 05, 2018 at 07:07:30AM +0300, Daniel Kahn Gillmor wrote:
>> One mitigating factor of the ETSI standard, i suppose, is that the
>> CABForum's Baseline Requirements forbid issuance of a certificate with
>> any subjectAltName other than dNSName or iPAddress, so otherName looks
>> like it must not be issued by standard public CAs.
>> 
>> top of p. 44 of 
>> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.1.pdf
>> 
>> Has anyone set up tools to monitor the CT logs for such a sAN to see
>> whether that element of the BR is being honored?
>
> All the linters will give an error about that, see for instance:
> https://crt.sh/?id=1009623020=x509lint,cablint,zlint

right, so what is to be done about that, when some of these CAs are
clearly violating the BRs?  Transparency is only as useful as the
actions we can take once violations are uncovered.  Unactionable
transparency just sounds like despair to me.  So what's the action?

  --dkg

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Kurt Roeckx]

On Wed, Dec 05, 2018 at 07:07:30AM +0300, Daniel Kahn Gillmor wrote:
> One mitigating factor of the ETSI standard, i suppose, is that the
> CABForum's Baseline Requirements forbid issuance of a certificate with
> any subjectAltName other than dNSName or iPAddress, so otherName looks
> like it must not be issued by standard public CAs.
> 
> top of p. 44 of 
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.1.pdf
> 
> Has anyone set up tools to monitor the CT logs for such a sAN to see
> whether that element of the BR is being honored?

All the linters will give an error about that, see for instance:
https://crt.sh/?id=1009623020=x509lint,cablint,zlint


Kurt

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Sean Turner]

There is no WG consensus to adopt this draft as no WG adoption call has been 
made.  draft-dkg-tls-reject-static-dh is an individual draft that is currently 
being discussed on this list; in much the same way 
draft-green-tls-static-dh-in-tls13 and draft-rhrd-tls-tls13-visibility were 
individual drafts that were discussed on this list; there was no WG consensus 
to adopt draft-rhrd-tls-tls13-visibility and there was never a call to adopt 
draft-green-tls-static-dh-in-tls13.  

The chairs have been debating whether draft-dkg-tls-reject-static-dh is in 
scope or whether the discussion should be moved elsewhere.  Parts of this draft 
we believe are in scope, e.g., providing guidance on handling key share re-use 
and pitfalls for not following this guidance.  (Note that how to handle key 
share re-use is not the same thing as explicitly prohibiting re-use of keys.)  
Other parts of the draft contain material for which we did not reach consensus 
to address, such as Section 3.3 on prohibiting key-share reuse.  We are not the 
protocol police and have recently gotten out of that business, e.g., by 
removing barriers for cipher suite code points. We do not want to get back in 
that business.

In order to ensure a focused discussion and avoid rehashing the previous debate 
regarding draft-rhrd-tls-tls13-visibility, parts of this draft should be 
rescoped or removed.  Authors are free to take this material to an AD and seek 
sponsorship, or to the ISE/IAB for further guidance.

Cheers,
Joe, Chris, and Sean

> On Dec 6, 2018, at 21:19, Arnaud.Taddei.IETF 
>  wrote:
> 
> I am really surprised how the answers you don't like are systematically put 
> on denial. Can you explain me what leads you to think that some people here 
> are not concerned by the list of people you list? this is an assumption and 
> the wrong assumption.
> 
> Perhaps on the contrary we are concerned BOTH by what these people endure but 
> too by what other consistencies are basically removed rights to defend 
> themselves.
> 
> As to the marketing aspect frankly this is an invention here and again I 
> don't see what allows you to paint the answers you don't like because you 
> don't like.
> 
> So I could on the contrary hightight the dogmatism that reins here, with a 
> smell of intimidation, and to some degree the sectarianism back to the latin 
> roots of the word
> 
> Regarding Human Rights, we DO care about Human Rights too and fact is that I 
> had the chance to make more progress in 2 hours than I did in 2 years at IET 
> and I had the chance to contribute to a magic moment with a Chinese 
> Organization to comply a technical solution to Human Rights requirements. You 
> know why? Because we took the time to TALK properly to each other, understand 
> each other, learn from each other with no intimidation and no wrong 
> assumptions that 'because we LOOK to be on the wrong side' we are foolish 
> people, and respect to the fact that not everyone speaks and writes a proper 
> English and sometimes words are dangerous when we don't know exactly the 
> semantics in the right context
> 
> The assumption that you are the only one who cares is tiresome.
> 
> This group was offered a chance to control the development of a 360 degree 
> solution for all parties and it was rejected. Fine. The ETSI took it and is 
> taking its responsibly.
> 
> I don't know what leads you to think that a model where security resides only 
> on the 2 ends of the communication IS the answer to all the problems.
> 
> The recent continuous scandals that are affecting a number of platforms and 
> destroying trust, privacy and security is leading me to think about why 
> should I trust this model. By analogy when I see how my body defends itself 
> against bad stuff, it is using a battery of models, not one model.
> 
> In any negotiation you can look for what is the right battle, and those who 
> understand that point will know that the right battle (and the one which is 
> harder for the opposition) is on providing guarantees. This would have been a 
> better battle to pick and would have given a chance to work more 
> collaboratively and not by confrontation.
> 
> Now I don't understand what leads this group to try now to block the ETSI, 
> can someone tell me and in particular the chairs if we have a consensus here?
> 
> Finally I am calling on the chairs of this group. It was very interesting to 
> observe the many comments at the last IETF103 about the vile and toxic 
> atmosphere that prevails here. I have all my time to work in these conditions 
> but perhaps the chair could try to think about a more positive atmosphere of 
> work.
> 
> A bon entendeur salut
> 
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
> On Wednesday 5 December 2018 21:36, Daniel Kahn Gillmor 
>  wrote:
> 
>> On Wed 2018-12-05 20:15:08 +0900, Bret Jordan wrote:
>> 
 On Dec 5, 2018, at 7:33 PM, Stephen Farrell stephen.farr...@cs.tcd.ie 
 wrote:
 

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Eric Rescorla]

The Security ADs sent the following liaison statement to ETSI on this topic:
https://datatracker.ietf.org/liaison/1616/

On Sat, Dec 1, 2018 at 1:11 AM Dmitry Belyavsky  wrote:

> Dear All,
>
> JFYI. Via Feisti Duck nerwsletter.
>
>
> https://www..etsi.org/news-events/news/1358-2018-11-press-etsi-releases-standards-for-enterprise-security-and-data-centre-management
> 
>
> The eTLS key exchange shall use exactly the same messages and procedures
> to establish a set of session keys as a
> TLS 1.3 ephemeral Diffie-Hellman key exchange, except for two differences
> [2].
> 1) the server shall use a static public/private key pair at Step 2 in
> clause 4.3.1; and
> 2) the server's certificate at Step 5 shall contain visibility information
> as defined in clause 4.3.3 to indicate to the
> client that eTLS is in use.
> NOTE: Neither the static public key nor the visibility information affects
> the operation of a TLS 1.3 compliant
> client, so an eTLS server is therefore fully interoperable with TLS 1.3
> compliant clients.
>
> --
> SY, Dmitry Belyavsky
> ___
> 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] ETSI releases standards for enterprise security and data centre management

[Sean Turner]

Please stand by.

The chairs (Joe, Chris, and myself) have been discussing whether this draft is 
in scope.  We are meeting later today to wrap up the discussion and get message 
out to the WG.

spt

> On Dec 6, 2018, at 21:19, Arnaud.Taddei.IETF 
>  wrote:
> 
> I am really surprised how the answers you don't like are systematically put 
> on denial. Can you explain me what leads you to think that some people here 
> are not concerned by the list of people you list? this is an assumption and 
> the wrong assumption.
> 
> Perhaps on the contrary we are concerned BOTH by what these people endure but 
> too by what other consistencies are basically removed rights to defend 
> themselves.
> 
> As to the marketing aspect frankly this is an invention here and again I 
> don't see what allows you to paint the answers you don't like because you 
> don't like.
> 
> So I could on the contrary hightight the dogmatism that reins here, with a 
> smell of intimidation, and to some degree the sectarianism back to the latin 
> roots of the word
> 
> Regarding Human Rights, we DO care about Human Rights too and fact is that I 
> had the chance to make more progress in 2 hours than I did in 2 years at IET 
> and I had the chance to contribute to a magic moment with a Chinese 
> Organization to comply a technical solution to Human Rights requirements. You 
> know why? Because we took the time to TALK properly to each other, understand 
> each other, learn from each other with no intimidation and no wrong 
> assumptions that 'because we LOOK to be on the wrong side' we are foolish 
> people, and respect to the fact that not everyone speaks and writes a proper 
> English and sometimes words are dangerous when we don't know exactly the 
> semantics in the right context
> 
> The assumption that you are the only one who cares is tiresome.
> 
> This group was offered a chance to control the development of a 360 degree 
> solution for all parties and it was rejected. Fine. The ETSI took it and is 
> taking its responsibly.
> 
> I don't know what leads you to think that a model where security resides only 
> on the 2 ends of the communication IS the answer to all the problems.
> 
> The recent continuous scandals that are affecting a number of platforms and 
> destroying trust, privacy and security is leading me to think about why 
> should I trust this model. By analogy when I see how my body defends itself 
> against bad stuff, it is using a battery of models, not one model.
> 
> In any negotiation you can look for what is the right battle, and those who 
> understand that point will know that the right battle (and the one which is 
> harder for the opposition) is on providing guarantees. This would have been a 
> better battle to pick and would have given a chance to work more 
> collaboratively and not by confrontation.
> 
> Now I don't understand what leads this group to try now to block the ETSI, 
> can someone tell me and in particular the chairs if we have a consensus here?
> 
> Finally I am calling on the chairs of this group. It was very interesting to 
> observe the many comments at the last IETF103 about the vile and toxic 
> atmosphere that prevails here. I have all my time to work in these conditions 
> but perhaps the chair could try to think about a more positive atmosphere of 
> work.
> 
> A bon entendeur salut
> 
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
> On Wednesday 5 December 2018 21:36, Daniel Kahn Gillmor 
>  wrote:
> 
>> On Wed 2018-12-05 20:15:08 +0900, Bret Jordan wrote:
>> 
 On Dec 5, 2018, at 7:33 PM, Stephen Farrell stephen.farr...@cs.tcd.ie 
 wrote:
 
> On 05/12/2018 10:22, Bret Jordan wrote:
> I think we should be more open minded and look at the needs from a
> 360 degree deployment perspective.
 
 I think we should avoid marketing speak.
>>> 
>>> This is not marketing speak. This is understanding how these solutions
>>> need to be deployed end to end in all of their scenarios from
>>> consumer, to small business, to enterprise, to service provider, to
>>> content provider, to telco, etc.
>> 
>> Perhaps one of the reasons that this might across as marketing speak to
>> some people is that your list of "all their scenarios" appears to be
>> only business use cases (where the individual people involved are at
>> most consumers of business products). You haven't mentioned
>> journalists, disk jockeys, activists, flat earthers, dissidents,
>> students, medical professionals, juggalos, community organizers, gun
>> nuts, cryptozoologists, whistleblowers, LGBTQ folx, refugees, free
>> software developers, elected officials, religious minorities, senior
>> citizens, or any of the other non-business use cases that may depend on
>> TLS for confidentiality, integrity, authenticity, or any of the other
>> information security guarantees that are put at risk by proposals like
>> this.
>> 
>> One of the concerns the last time we danced this 

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Arnaud.Taddei.IETF]

I am really surprised how the answers you don't like are systematically put on 
denial. Can you explain me what leads you to think that some people here are 
not concerned by the list of people you list? this is an assumption and the 
wrong assumption.

Perhaps on the contrary we are concerned BOTH by what these people endure but 
too by what other consistencies are basically removed rights to defend 
themselves.

As to the marketing aspect frankly this is an invention here and again I don't 
see what allows you to paint the answers you don't like because you don't like.

So I could on the contrary hightight the dogmatism that reins here, with a 
smell of intimidation, and to some degree the sectarianism back to the latin 
roots of the word

Regarding Human Rights, we DO care about Human Rights too and fact is that I 
had the chance to make more progress in 2 hours than I did in 2 years at IET 
and I had the chance to contribute to a magic moment with a Chinese 
Organization to comply a technical solution to Human Rights requirements. You 
know why? Because we took the time to TALK properly to each other, understand 
each other, learn from each other with no intimidation and no wrong assumptions 
that 'because we LOOK to be on the wrong side' we are foolish people, and 
respect to the fact that not everyone speaks and writes a proper English and 
sometimes words are dangerous when we don't know exactly the semantics in the 
right context

The assumption that you are the only one who cares is tiresome.

This group was offered a chance to control the development of a 360 degree 
solution for all parties and it was rejected. Fine. The ETSI took it and is 
taking its responsibly.

I don't know what leads you to think that a model where security resides only 
on the 2 ends of the communication IS the answer to all the problems.

The recent continuous scandals that are affecting a number of platforms and 
destroying trust, privacy and security is leading me to think about why should 
I trust this model. By analogy when I see how my body defends itself against 
bad stuff, it is using a battery of models, not one model.

In any negotiation you can look for what is the right battle, and those who 
understand that point will know that the right battle (and the one which is 
harder for the opposition) is on providing guarantees. This would have been a 
better battle to pick and would have given a chance to work more 
collaboratively and not by confrontation.

Now I don't understand what leads this group to try now to block the ETSI, can 
someone tell me and in particular the chairs if we have a consensus here?

Finally I am calling on the chairs of this group. It was very interesting to 
observe the many comments at the last IETF103 about the vile and toxic 
atmosphere that prevails here. I have all my time to work in these conditions 
but perhaps the chair could try to think about a more positive atmosphere of 
work.

A bon entendeur salut



Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday 5 December 2018 21:36, Daniel Kahn Gillmor 
 wrote:

> On Wed 2018-12-05 20:15:08 +0900, Bret Jordan wrote:
>
> > > On Dec 5, 2018, at 7:33 PM, Stephen Farrell stephen.farr...@cs.tcd.ie 
> > > wrote:
> > >
> > > > On 05/12/2018 10:22, Bret Jordan wrote:
> > > > I think we should be more open minded and look at the needs from a
> > > > 360 degree deployment perspective.
> > >
> > > I think we should avoid marketing speak.
> >
> > This is not marketing speak. This is understanding how these solutions
> > need to be deployed end to end in all of their scenarios from
> > consumer, to small business, to enterprise, to service provider, to
> > content provider, to telco, etc.
>
> Perhaps one of the reasons that this might across as marketing speak to
> some people is that your list of "all their scenarios" appears to be
> only business use cases (where the individual people involved are at
> most consumers of business products). You haven't mentioned
> journalists, disk jockeys, activists, flat earthers, dissidents,
> students, medical professionals, juggalos, community organizers, gun
> nuts, cryptozoologists, whistleblowers, LGBTQ folx, refugees, free
> software developers, elected officials, religious minorities, senior
> citizens, or any of the other non-business use cases that may depend on
> TLS for confidentiality, integrity, authenticity, or any of the other
> information security guarantees that are put at risk by proposals like
> this.
>
> One of the concerns the last time we danced this dance was that the
> proposal claimed to be interested in one use case only: "the enterprise
> data center", and yet offered no meaningful way to effectively limit its
> (ab)use outside the data center. This objection was raised clearly, and
> the proponents of the protocol change failed to address it. And now it
> appears that instead of addressing the concern, they forum-shopped until
> they found a place 

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Tony Arcieri]

On Thu, Dec 6, 2018 at 3:30 PM Viktor Dukhovni 
wrote:

> > On Dec 6, 2018, at 4:08 PM, Andrei Popov  40microsoft@dmarc.ietf.org> wrote:
> >
> > Widespread deployment of draft-dkg-tls-reject-static-dh-01 and failing
> connections to "enterprise TLS" servers would probably qualify as
> "essential circumstances", at least to some operators.
>
> I don't think the TLS WG or IETF can win this skirmish.
>

I think there are very strong technical/security reasons to reject using a
static D-H key in place of an ephemeral D-H key, namely compromise of this
key permits "impersonation" of any previously (passively) observed TLS
sessions by allowing a passive observer holding one of these keys to
recover the resumption master secret.

In as much as people are attempting to build standards around this
approach, based on the conversation earlier in this thread it seems they
were unaware of this security property. I hope this causes the creators of
"eTLS" to reconsider the security implications of their proposal.

I think a protocol which aims to fulfill the specific goals of "eTLS"
should focus on providing a way for a passive observer to recover the
*traffic* secrets, which would provide the ability to passively decrypt
traffic (something I think is a bad idea, but I digress), but *NOT* resume
observed sessions.

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Nico Williams]

On Fri, Dec 07, 2018 at 12:04:02AM +, Andrei Popov wrote:
> > I don't think the TLS WG or IETF can win this skirmish.  
>
> That's what I'm thinking as well, although I agree with the goals of
> draft-dkg-tls-reject-static-dh-01.

Yes.  What we can, and IMO should do, is say that if you must do key
escrow or session recording, to it out-of-band.

Nico
-- 

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Andrei Popov]

> I don't think the TLS WG or IETF can win this skirmish.  
That's what I'm thinking as well, although I agree with the goals of 
draft-dkg-tls-reject-static-dh-01.

Cheers,

Andrei

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Daniel Kahn Gillmor]

On Thu 2018-12-06 21:08:00 +, Andrei Popov wrote:
> In a specific quick test that I did, there was no significant perf
> impact with key reuse time > 1 sec. And I could probably get it down
> to sub-seconds on my HW. But HW specs differ between TLS servers; our
> current "ephemeral" key lifetime is a generous 30 sec., mainly because
> we saw no reason to push for a lower key lifetime.

Is this on both client side and server side?  That is, does SChannel as
a client also use an "ephemeral" key lifetime of a generous 30 seconds?

> "Truly malicious" is perhaps an overstatement for this easy workaround 
> explicitly permitted by the "Enterprise TLS" spec:
> "In some essential circumstances, the visibility information field may be 
> omitted."

The ETSI "Middlebox Security Protocol" explicitly aims to drop Annex A.
They've said that they *want* visibility and that is an explicit goal.

Surely the purpose of visibility is to ensure that both parties involved
are running the significantly weaker eTLS, and not TLS.  Opting for
visibility while expecting clients to not do anything with the knowledge
gained doesn't make much sense to me.

   --dkg


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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Viktor Dukhovni]

> On Dec 6, 2018, at 4:08 PM, Andrei Popov 
>  wrote:
> 
> Widespread deployment of draft-dkg-tls-reject-static-dh-01 and failing 
> connections to "enterprise TLS" servers would probably qualify as "essential 
> circumstances", at least to some operators.

I don't think the TLS WG or IETF can win this skirmish.  If some
operators are set on session recording, they'll find a way, and
the more obstacles they have to overcome the more likely they are
to compromise security along the way.

So while clients should not do anything special to support this,
and the protocol should not change to adapt to the use-case, it
might in fact be more productive to help the operators who need
this arrive at an approach that minimizes risk.  Explicitly
trying to defeat what they're sure to do anyway does look like
a wise approach to me.

The operators could, for example, derive the (EC)DH private key
from an HMAC of the client and server random with a secret
key shared with the wiretap device.  The client would never
know, and the (EC)DH key would not look any different to an
outside observer.

The best we can probably do is publicize the risks, so that
auditors are well aware of them and can highlight poor designs,
and hope that some operators will decide they can do without
such intercepts, or will use an approach that preserves as
much security as possible.

-- 
Viktor.

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Tony Arcieri]

On Thu, Dec 6, 2018 at 12:33 PM Daniel Kahn Gillmor 
wrote:

> So it's conceivable that truly malicious servers would do this, of
> course, but they might also just publish the master secret on twitter
> too, and the client wouldn't know how to detect that inband either.  But
> for the misbehavior that we *can* detect in-band, a responsible client
> should be aware of it and avoid it, right?
>

If nothing else, implementations which reuse ephemeral keys for long
periods of time are buggy and contain a vulnerability which violates the
security assumptions of the protocol.

I think it's reasonable for clients to detect and reject this behavior, as
it's an indicator TLS has been deployed in an insecure way and therefore
the connection should be aborted. I think this could detect a wide range of
"real world" TLS implementation failures which have come up in the past,
including bugs in random number generation and bugs in the code in TLS
stacks responsible for rotating ephemeral keys.

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Daniel Kahn Gillmor]

On Thu 2018-12-06 02:10:06 +, Andrei Popov wrote:
> In our tests, we see significant drop in handshakes/sec on a busy TLS
> server with ephemeral DH share reuse time < 1 sec.

hm, thinking about this optimization approach, i would really like to
know what implementations are doing this.  It occurs to me that client
implementations as well as server implementations could be doing this
"for efficiency reasons".

If both sides do it, and two connections are established within the
window before the "ephemeral" keys are disposed of, then you could end
up in a scenario where you actually have a "Handshake Secret" and
"Master Secret" that are reused across a connection, and this would be
entirely observable by a passive monitor.

That leaves the only defense against direct key reuse for encryption on
the wire the entropy in:

 * ClientHello and ServerHello (for
   {client,server}_handshake_traffic_secret)

 * ClientHello and server Finished (for
   {client,server}_application_traffic_secret_0 and
   exporter_master_secret)

 * ClientHello and client Finished (for
   resumption_master_secret)

Seems like risky business... we're leaning heavily on HKDF-Expand-Label
to keep a passive observer from being able to identify how the actual
traffic keys across sessions are related to one another.  Or am i
missing something?  I'd love for someone to correct me here.

Maybe i'll add a section to the draft explicitly forbidding clients from
ever taking this "optimization" step as well.

  --dkg


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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Daniel Kahn Gillmor]

Hi Andrei--

On Thu 2018-12-06 02:10:06 +, Andrei Popov wrote:
> I like the intent of draft-dkg-tls-reject-static-dh-01, but this part will 
> cost servers some perf:
>
>"Given the concerns in Section 2 and the necessary client mitigations
>in the subsections above, servers need to avoid giving the appearance
>of using non-ephemeral DH.  Servers MUST NOT reuse ephemeral DH
>shares."
>
> In our tests, we see significant drop in handshakes/sec on a busy TLS
> server with ephemeral DH share reuse time < 1 sec.

interesting, i'd love to see more details on those tests if you can
share them.  What kind of load are we talking about?  Which server
implementation?

The cost here is in the fixed-base operation, iiuc, which is the
cheapest part of the handshake -- DH share reuse allows you to skip this
one step per handshake (or rather, to amortize the one step across
multiple handshakes).

You mention a cutoff of 1 second.  If the amortization is spread across,
say, all handshakes within 2 seconds, is the performance impact still
significant?

If the draft's server guidance were to be amended to suggest avoiding DH
reuse for more than 2 seconds, and the guidance for clients to track
added a buffer of 2 seconds before rejection, would that satisfy your
concerns about performance under load?

> Also, won't the "enterprise TLS" server just create a bunch of static
> DH shares and send different ones at different times, thereby avoiding
> detection by most clients?

I don't think that the intent of the ETSI spec is to encourage
non-visible use.  They've specifically stated visibility to clients as a
primary goal, and acknoweldged that "Annex A" servers would be in
violation of their own goals.

So it's conceivable that truly malicious servers would do this, of
course, but they might also just publish the master secret on twitter
too, and the client wouldn't know how to detect that inband either.  But
for the misbehavior that we *can* detect in-band, a responsible client
should be aware of it and avoid it, right?

   --dkg


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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Andrei Popov]

I like the intent of draft-dkg-tls-reject-static-dh-01, but this part will cost 
servers some perf:

   "Given the concerns in Section 2 and the necessary client mitigations
   in the subsections above, servers need to avoid giving the appearance
   of using non-ephemeral DH.  Servers MUST NOT reuse ephemeral DH
   shares."

In our tests, we see significant drop in handshakes/sec on a busy TLS server 
with ephemeral DH share reuse time < 1 sec.

Also, won't the "enterprise TLS" server just create a bunch of static DH shares 
and send different ones at different times, thereby avoiding detection by most 
clients?

Cheers,

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Melinda Shore]

On 12/5/18 7:27 AM, Salz, Rich wrote:
> That’s not the way it works.  When deciding whether or not to adopt
> something as a WG item, unless there is consensus to DO it, then the
> consensus is DO NOT do it.  There is no tie.  A decision was made, and
> by not adopting this work, the WG decided to NOT DO IT.

I'm going to split hairs here, since there are a few participants
in the discussion who aren't experienced in the ways of the IETF:
If there's no consensus then there's no consensus.  However, the
outcome, in this case, is very much the same.

Melinda


-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Christopher Wood]

On Wed, Dec 5, 2018 at 8:28 AM Salz, Rich  wrote:
>
> Or it could be said the TLS WG had no consensus to not work on it.  When 
> there is a tie who wins? It seems like working on a solution that works for 
> the larger community is the right solution.  The use case and need is a valid 
> requirement.
>
> That’s not the way it works.  When deciding whether or not to adopt something 
> as a WG item, unless there is consensus to DO it, then the consensus is DO 
> NOT do it.  There is no tie.  A decision was made, and by not adopting this 
> work, the WG decided to NOT DO IT.

Rich's assessment is correct. This may very well be a legitimate use
case and goal, though we previously concluded via lack of consensus
that it does not align with the goals of WG. Therefore, this
discussion should happen elsewhere, and not in this particular WG. I
recommend contacting the ADs for advice as to where this discussion
should go next.

Best,
Chris (for the chairs)

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[R duToit]

I like the gist of what Tony is saying.  Key escrow (it should be called 
"secret escrow", but I digress) itself is not really the problem in a 
datacenter - those guys struggle to solve the key distribution problem.  If it 
was one-server-to-one-tool then we would not be having this discussion.  eTLS 
looks like an attempt to simplify the key distribution implementation, but at 
the expense of the security attributes of the TLS session. Why don't we provide 
a "sandbox" mechanism that would allow business-solution folks to solve the key 
distribution problem without directly affecting the TLS session?  What I have 
in mind is a TLS extension that would unlock a new TLS record ContentType 
called "foo" (for lack of a name).  All "foo" records will be completely 
ignored by the TLS stack, including not affecting the TLS record sequence 
number or crypto state.  That mechanism can then be used to send in-band 
messages that could be picked up by inline and passive tools along the way.  
Mechanisms that use "foo" records could potentially be designed outside the 
IETF, and the TLS-WG would have no responsibility for insecure implementations 
of multi-party secret sharing mechanisms (although it would be good to point 
those engineers in the right direction). --Roelof  On Wed, 05 Dec 2018 
10:51:26 -0500 Tony Arcieri  wrote  On Wed, Dec 5, 2018 
at 12:09 AM Bret Jordan  wrote: Now this WG is finally 
starting to talk about a solution to a real problem and need.  We can either 
address the use case and need here in the IETF, or we can let the solutions be 
done else where. I would personally prefer we take this work item back and 
solve it here in the IETF. [...] On Dec 5, 2018, at 1:18 AM, Tony Arcieri 
 wrote: [...] It seems like with an out-of-band escrow 
agent, the traffic secrets could be escrowed with no changes to TLS. Note that 
the solution I was proposing here requires no changes to TLS. I am sure that 
there are many in the IETF who would be happy with people exploring solutions 
which don't require changes to TLS. Here are some others: Endpoint agents (OSS 
- commercial options are also available): https://osquery...io/ 
https://www.bro.org/ (now Zeek) https://wazuh.com/ Encrypted traffic analytics: 
https://blogs.cisco.com/security/tls-version-1-3-change-is-here-and-encrypted-traffic-analytics-has-got-your-back
 -- Tony Arcieri ___ 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] ETSI releases standards for enterprise security and data centre management

[Salz, Rich]

  *   Or it could be said the TLS WG had no consensus to not work on it.  When 
there is a tie who wins? It seems like working on a solution that works for the 
larger community is the right solution.  The use case and need is a valid 
requirement.

That’s not the way it works.  When deciding whether or not to adopt something 
as a WG item, unless there is consensus to DO it, then the consensus is DO NOT 
do it.  There is no tie.  A decision was made, and by not adopting this work, 
the WG decided to NOT DO IT.

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Salz, Rich]

>One mitigating factor of the ETSI standard, i suppose, is that the
CABForum's Baseline Requirements forbid issuance of a certificate with
any subjectAltName other than dNSName or iPAddress, so otherName looks
like it must not be issued by standard public CAs.
  
Ooh, good catch.  I bet the ETSI folks didn't know this.

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Tony Arcieri]

On Wed, Dec 5, 2018 at 12:09 AM Bret Jordan  wrote:

> Now this WG is finally starting to talk about a solution to a real problem
> and need.  We can either address the use case and need here in the IETF, or
> we can let the solutions be done else where. I would personally prefer we
> take this work item back and solve it here in the IETF.
> [...]
>
> On Dec 5, 2018, at 1:18 AM, Tony Arcieri  wrote:
> [...]
> It seems like with an out-of-band escrow agent, the traffic secrets could
> be escrowed with no changes to TLS.
>
> Note that the solution I was proposing here requires no changes to TLS. I
am sure that there are many in the IETF who would be happy with people
exploring solutions which don't require changes to TLS.

Here are some others:

   - Endpoint agents (OSS - commercial options are also available):
   - https://osquery.io/
  - https://www.bro.org/ (now Zeek)
  - https://wazuh.com/
  - Encrypted traffic analytics:
   
https://blogs.cisco.com/security/tls-version-1-3-change-is-here-and-encrypted-traffic-analytics-has-got-your-back

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Daniel Kahn Gillmor]

On Wed 2018-12-05 20:15:08 +0900, Bret Jordan wrote:
>> On Dec 5, 2018, at 7:33 PM, Stephen Farrell  
>> wrote:
>>> On 05/12/2018 10:22, Bret Jordan wrote:
>>> I think we should be more open minded and look at the needs from a
>>> 360 degree deployment perspective. 
>> 
>> I think we should avoid marketing speak.
>
> This is not marketing speak. This is understanding how these solutions
> need to be deployed end to end in all of their scenarios from
> consumer, to small business, to enterprise, to service provider, to
> content provider, to telco, etc.

Perhaps one of the reasons that this might across as marketing speak to
some people is that your list of "all their scenarios" appears to be
only business use cases (where the individual people involved are at
most consumers of business products).  You haven't mentioned
journalists, disk jockeys, activists, flat earthers, dissidents,
students, medical professionals, juggalos, community organizers, gun
nuts, cryptozoologists, whistleblowers, LGBTQ folx, refugees, free
software developers, elected officials, religious minorities, senior
citizens, or any of the other non-business use cases that may depend on
TLS for confidentiality, integrity, authenticity, or any of the other
information security guarantees that are put at risk by proposals like
this.

One of the concerns the last time we danced this dance was that the
proposal claimed to be interested in one use case only: "the enterprise
data center", and yet offered no meaningful way to effectively limit its
(ab)use outside the data center.  This objection was raised clearly, and
the proponents of the protocol change failed to address it.  And now it
appears that instead of addressing the concern, they forum-shopped until
they found a place to publish the same approach without even
acknowledging the concern that this could have an impact beyond the data
center.

A full 360 degree view might acknowledge that doing harm to the core
priniciples of a security protocol that everyone relies on for the sake
of one particular use case out of many might not be an appropriate step
to take.  (and that one use case might have other solutions, albeit
perhaps more expensive or inconveient ones for people who have already
made certain investments)

I'm pretty sure we don't want TLS to be all things to all people, right?
What are the core goals or guarantees of TLS that you would like to see
preserved?

--dkg


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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Bret Jordan]

Comments inline 

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

> On Dec 5, 2018, at 7:33 PM, Stephen Farrell  wrote:
> 
> 
> 
>> On 05/12/2018 10:22, Bret Jordan wrote:
>> I think we should be more open minded and look at the needs from a
>> 360 degree deployment perspective. 
> 
> I think we should avoid marketing speak.

This is not marketing speak. This is understanding how these solutions need to 
be deployed end to end in all of their scenarios from consumer, to small 
business, to enterprise, to service provider, to content provider, to telco, 
etc.  


> 
>> The real power of the IETF is in
>> looking at all the needs and requirements and designing solutions for
>> them.
> 
> The IETF is sometimes at it's best when it says "no." This
> is one of those cases.


I disagree.



>> We should flesh this out. It seems like several people on this list
>> so far have proposed options that might work. If we spent half as
>> much time looking for a solution as we have trying to prevent a
>> solution, we would probably be done by now.
> 
> All of the above was done, at length, and we got a result.
> The TLS WG had no consensus to work on this topic.

Or it could be said the TLS WG had no consensus to not work on it.  When there 
is a tie who wins? It seems like working on a solution that works for the 
larger community is the right solution.  The use case and need is a valid 
requirement.

Bret 



> S.
> 
> 
>> 
>> Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8
>> ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however,
>> the only thing that can not be unscrambled is an egg."
>> 
>>> On Dec 5, 2018, at 6:12 PM, Stephen Farrell
>>>  wrote:
>>> 
>>> 
>>> 
 On 05/12/2018 08:08, Bret Jordan wrote:
 Now this WG is finally starting to talk about a solution to a
 real problem and need.  We can either address the use case and
 need here in the IETF, or we can let the solutions be done else
 where. I would personally prefer we take this work item back and
 solve it here in the IETF.
>>> 
>>> #include 
>>> 
>>> I would hope the WG not revisit this topic and see no new facts to
>>> justify distracting the WG again. Forum shopping is not new -
>>> rubber-stamping by ETSI or ANSI was explicitly proposed as a
>>> putative reason to adopt draft-green and that did not result in
>>> consensus to work on this topic despite the significant effort put
>>> in by proponents. I'm also happy to say that I see no evidence that
>>> the WG would reach a different conclusion as to lack of consensus.
>>> 
>>> FWIW, I view this discussion as being analogous to scratching an
>>> itchy scab - despite our knowing it is unproductive to do so, some
>>> IETF participants apparently can't resist poking at the wound:-(
>>> 
>>> S.
>>> 
 
 Finally, remember, you may not like the use case or need, but
 that does not mean the use case is not valid and needed.
 
 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0
 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw,
 however, the only thing that can not be unscrambled is an egg."
 
> On Dec 5, 2018, at 1:18 AM, Tony Arcieri  
> wrote:
> 
> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams
> mailto:n...@cryptonector.com>> wrote:
>> I'm not a fan of systems like this, but I believe for
>> security reasons they should be designed in such a way that
>> only the confidentiality of traffic is impacted, and a
>> "visibility" system isn't able to leverage the decrypted
>> traffic to resume decrypted sessions and thereby impersonate
>> clients.
> 
> Any key escrow system will have this property.  Given the
> session keys (or a way to recover them) you can resume
> decrypted sessions.
> 
> Wouldn't escrowing only the client/server application traffic 
> secrets (instead of keys higher in the schedule) avoid this 
> problem? These keys would permit the one capability
> "visibility" appliance vendors allege to care about: traffic
> decryption, without permitting others like session resumption.
> 
> The most obvious escrow design requiring no changes to the
> clients is to use a static eDH key on the server-side.  The
> next most obvious such design is to have the server talk to the
> escrow agent.
> 
> It seems like with an out-of-band escrow agent, the traffic
> secrets could be escrowed with no changes to TLS.
> 
> -- Tony Arcieri ___
> 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
 
>>> <0x5AB2FAF17B172BEA.asc>
>> 
>> 
> <0x5AB2FAF17B172BEA.asc>
___
TLS mailing 

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Bret Jordan]

I think we should be more open minded and look at the needs from a 360 degree 
deployment perspective. The real power of the IETF is in looking at all the 
needs and requirements and designing solutions for them.

We should flesh this out. It seems like several people on this list so far have 
proposed options that might work. If we spent half as much time looking for a 
solution as we have trying to prevent a solution, we would probably be done by 
now. 

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

> On Dec 5, 2018, at 6:12 PM, Stephen Farrell  wrote:
> 
> 
> 
> On 05/12/2018 08:08, Bret Jordan wrote:
>> Now this WG is finally starting to talk about a solution to a real
>> problem and need.  We can either address the use case and need here
>> in the IETF, or we can let the solutions be done else where. I would
>> personally prefer we take this work item back and solve it here in
>> the IETF.
> 
> #include 
> 
> I would hope the WG not revisit this topic and see no new
> facts to justify distracting the WG again. Forum shopping
> is not new - rubber-stamping by ETSI or ANSI was explicitly
> proposed as a putative reason to adopt draft-green and that
> did not result in consensus to work on this topic despite
> the significant effort put in by proponents. I'm also happy
> to say that I see no evidence that the WG would reach a
> different conclusion as to lack of consensus.
> 
> FWIW, I view this discussion as being analogous to scratching
> an itchy scab - despite our knowing it is unproductive to do
> so, some IETF participants apparently can't resist poking at
> the wound:-(
> 
> S.
> 
>> 
>> Finally, remember, you may not like the use case or need, but that
>> does not mean the use case is not valid and needed.
>> 
>> Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8
>> ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however,
>> the only thing that can not be unscrambled is an egg."
>> 
>>> On Dec 5, 2018, at 1:18 AM, Tony Arcieri 
>>> wrote:
>>> 
>>> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams >> > wrote:
 I'm not a fan of systems like this, but I believe for security
 reasons they should be designed in such a way that only the
 confidentiality of traffic is impacted, and a "visibility" system
 isn't able to leverage the decrypted traffic to resume decrypted
 sessions and thereby impersonate clients.
>>> 
>>> Any key escrow system will have this property.  Given the session
>>> keys (or a way to recover them) you can resume decrypted sessions.
>>> 
>>> Wouldn't escrowing only the client/server application traffic
>>> secrets (instead of keys higher in the schedule) avoid this
>>> problem? These keys would permit the one capability "visibility"
>>> appliance vendors allege to care about: traffic decryption, without
>>> permitting others like session resumption.
>>> 
>>> The most obvious escrow design requiring no changes to the clients
>>> is to use a static eDH key on the server-side.  The next most
>>> obvious such design is to have the server talk to the escrow
>>> agent.
>>> 
>>> It seems like with an out-of-band escrow agent, the traffic secrets
>>> could be escrowed with no changes to TLS.
>>> 
>>> -- Tony Arcieri ___ 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
>> 
> <0x5AB2FAF17B172BEA.asc>

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Benjamin Beurdouche]

> The WG is chartered to make TLS a fast, secure, confidential transport
> layer.  Let's keep the charter goals in mind.
> 
>--dkg

+ 1

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Daniel Kahn Gillmor]

On Wed 2018-12-05 17:08:44 +0900, Bret Jordan wrote:
> Now this WG is finally starting to talk about a solution to a real
> problem and need.  We can either address the use case and need here in
> the IETF, or we can let the solutions be done else where. I would
> personally prefer we take this work item back and solve it here in the
> IETF.

Or, the IETF can say with relative clarity that this kind of information
leakage is inappropriate for and incomaptible with the information
security goals of TLS.

> Finally, remember, you may not like the use case or need, but that
> does not mean the use case is not valid and needed.

Sure, but just because someone says it is, doesn't mean that the use
case is valid or needed within the scope of TLS either.

Throughout the (several years now) discussion of this sort of proposal,
we've repeatedly heard about "legal obligations" which somehow evaporate
when pressed for details.  And we've heard about "operational
considerations" which typically amount to cost-shifting concerns (they
can come across as: "we've invested a bunch of money in this particular
network architecture/application design, please change the infosec
guarantees provided by TLS for everyone on the global network so that we
don't have to do an expensive re-tooling or staff up on new skills while
i'm responsible for this budget line item").

The WG is chartered to make TLS a fast, secure, confidential transport
layer.  Let's keep the charter goals in mind.

--dkg


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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Stephen Farrell]

On 05/12/2018 08:08, Bret Jordan wrote:
> Now this WG is finally starting to talk about a solution to a real
> problem and need.  We can either address the use case and need here
> in the IETF, or we can let the solutions be done else where. I would
> personally prefer we take this work item back and solve it here in
> the IETF.

#include 

I would hope the WG not revisit this topic and see no new
facts to justify distracting the WG again. Forum shopping
is not new - rubber-stamping by ETSI or ANSI was explicitly
proposed as a putative reason to adopt draft-green and that
did not result in consensus to work on this topic despite
the significant effort put in by proponents. I'm also happy
to say that I see no evidence that the WG would reach a
different conclusion as to lack of consensus.

FWIW, I view this discussion as being analogous to scratching
an itchy scab - despite our knowing it is unproductive to do
so, some IETF participants apparently can't resist poking at
the wound:-(

S.

> 
> Finally, remember, you may not like the use case or need, but that
> does not mean the use case is not valid and needed.
> 
> Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8
> ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however,
> the only thing that can not be unscrambled is an egg."
> 
>> On Dec 5, 2018, at 1:18 AM, Tony Arcieri 
>> wrote:
>> 
>> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams > > wrote:
>>> I'm not a fan of systems like this, but I believe for security
>>> reasons they should be designed in such a way that only the
>>> confidentiality of traffic is impacted, and a "visibility" system
>>> isn't able to leverage the decrypted traffic to resume decrypted
>>> sessions and thereby impersonate clients.
>> 
>> Any key escrow system will have this property.  Given the session
>> keys (or a way to recover them) you can resume decrypted sessions.
>> 
>> Wouldn't escrowing only the client/server application traffic
>> secrets (instead of keys higher in the schedule) avoid this
>> problem? These keys would permit the one capability "visibility"
>> appliance vendors allege to care about: traffic decryption, without
>> permitting others like session resumption.
>> 
>> The most obvious escrow design requiring no changes to the clients
>> is to use a static eDH key on the server-side.  The next most
>> obvious such design is to have the server talk to the escrow
>> agent.
>> 
>> It seems like with an out-of-band escrow agent, the traffic secrets
>> could be escrowed with no changes to TLS.
>> 
>> -- Tony Arcieri ___ 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
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Bret Jordan]

Now this WG is finally starting to talk about a solution to a real problem and 
need.  We can either address the use case and need here in the IETF, or we can 
let the solutions be done else where. I would personally prefer we take this 
work item back and solve it here in the IETF.

Finally, remember, you may not like the use case or need, but that does not 
mean the use case is not valid and needed. 

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

> On Dec 5, 2018, at 1:18 AM, Tony Arcieri  wrote:
> 
> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams  > wrote:
>  > I'm not a fan of systems like this, but I believe for security reasons they
> > should be designed in such a way that only the confidentiality of traffic
> > is impacted, and a "visibility" system isn't able to leverage the decrypted
> > traffic to resume decrypted sessions and thereby impersonate clients.
> 
> Any key escrow system will have this property.  Given the session keys
> (or a way to recover them) you can resume decrypted sessions.
> 
> Wouldn't escrowing only the client/server application traffic secrets 
> (instead of keys higher in the schedule) avoid this problem? These keys would 
> permit the one capability "visibility" appliance vendors allege to care 
> about: traffic decryption, without permitting others like session resumption.
> 
>  The most obvious escrow design requiring no changes to the clients is to
> use a static eDH key on the server-side.  The next most obvious such
> design is to have the server talk to the escrow agent.
> 
> It seems like with an out-of-band escrow agent, the traffic secrets could be 
> escrowed with no changes to TLS.
> 
> --
> Tony Arcieri
> ___
> 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] ETSI releases standards for enterprise security and data centre management

[Daniel Kahn Gillmor]

On Sat 2018-12-01 10:02:44 -0800, Christian Huitema wrote:
> Which is indeed a huge problem. Security conscious implementations of
> TLS should detect the use of such "enhancements", and either abort the
> session or automatically treat it as insecure.

This certainly looks like a case of forum-shopping to do an end-run
around the underlying goals of TLS as a 2-party protocol that
prioritizes confidentiality, integrity, and authenticity between the two
peers.

Even worse, the supposed "VisibilityInformation" mechanism is stuffed
into subjectAltName in the server's certificate, which means that it
can't even depend on the "critical bit" that would have been available
to a standard X.509v3 certificate extension.  This appears to encourage
deployment to unaware clients.

I've just submitted draft-dkg-tls-reject-static-dh-00, which suggests
that responsible TLS clients that observe a server certificate with a
subjectAltName otherName with the VisibilityInformation type-id (OID
0.4.0.3523.3.1 {itu-t(0) identified-organization(4) etsi(0) msp(3523)
etls(3) visibility(1)}) MUST reject the certificate.  I'm open to
feedback on it.

https://datatracker.ietf.org/doc/draft-dkg-tls-reject-static-dh/

One mitigating factor of the ETSI standard, i suppose, is that the
CABForum's Baseline Requirements forbid issuance of a certificate with
any subjectAltName other than dNSName or iPAddress, so otherName looks
like it must not be issued by standard public CAs.

top of p. 44 of 
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.1.pdf

Has anyone set up tools to monitor the CT logs for such a sAN to see
whether that element of the BR is being honored?

--dkg


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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Nico Williams]

On Tue, Dec 04, 2018 at 05:39:30PM +0100, Jonathan Hoyland wrote:
> Isn't there a lower bar at the IETF for defining new cipher suites, as long
> as you're not seeking a "recommended" setting?

Yes, but then you have to get interoperability using them, which means
patching clients and servers.  You can't 100% escrow this way.

Nico
-- 

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Jonathan Hoyland]

Isn't there a lower bar at the IETF for defining new cipher suites, as long
as you're not seeking a "recommended" setting?

I think escrowing lower down keys / not MACing the messages beyond the
handshake means that you lose authenticity and integrity of the message
data, which is unattractive.
How burdensome would the extra few bytes actually be, given that the
alternative is substantially weaker security?

Regards,

Jonathan


On Tue, 4 Dec 2018 at 16:19 Tony Arcieri  wrote:

> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams 
> wrote:
>
>>  > I'm not a fan of systems like this, but I believe for security reasons
>> they
>> > should be designed in such a way that only the confidentiality of
>> traffic
>> > is impacted, and a "visibility" system isn't able to leverage the
>> decrypted
>> > traffic to resume decrypted sessions and thereby impersonate clients.
>>
>> Any key escrow system will have this property.  Given the session keys
>> (or a way to recover them) you can resume decrypted sessions.
>
>
> Wouldn't escrowing only the client/server application traffic secrets
> (instead of keys higher in the schedule) avoid this problem? These keys
> would permit the one capability "visibility" appliance vendors allege to
> care about: traffic decryption, without permitting others like session
> resumption.
>
>  The most obvious escrow design requiring no changes to the clients is to
>> use a static eDH key on the server-side.  The next most obvious such
>> design is to have the server talk to the escrow agent.
>
>
> It seems like with an out-of-band escrow agent, the traffic secrets could
> be escrowed with no changes to TLS.
>
> --
> Tony Arcieri
> ___
> 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] ETSI releases standards for enterprise security and data centre management

[Tony Arcieri]

On Sun, Dec 2, 2018 at 3:36 PM Nico Williams  wrote:

>  > I'm not a fan of systems like this, but I believe for security reasons
> they
> > should be designed in such a way that only the confidentiality of traffic
> > is impacted, and a "visibility" system isn't able to leverage the
> decrypted
> > traffic to resume decrypted sessions and thereby impersonate clients.
>
> Any key escrow system will have this property.  Given the session keys
> (or a way to recover them) you can resume decrypted sessions.


Wouldn't escrowing only the client/server application traffic secrets
(instead of keys higher in the schedule) avoid this problem? These keys
would permit the one capability "visibility" appliance vendors allege to
care about: traffic decryption, without permitting others like session
resumption.

 The most obvious escrow design requiring no changes to the clients is to
> use a static eDH key on the server-side.  The next most obvious such
> design is to have the server talk to the escrow agent.


It seems like with an out-of-band escrow agent, the traffic secrets could
be escrowed with no changes to TLS.

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Nico Williams]

On Tue, Dec 04, 2018 at 04:34:08PM +0100, Jonathan Hoyland wrote:
> Is it necessarily true that any key escrow system must allow resumptions?
> 
> Just to play devil's advocate, consider defining a new cipher suite that
> appended a MAC to each message before applying one of the other cipher
> suites.
> If the MAC is keyed with a key not derived from the master secret, but from
> some other value shared between the client and server, but not the
> middlebox, then the middlebox would be able to read all* the traffic, but
> would not be able to successfully resume the session.

This MAC key would also have to be involved in the session resumption
PSK, but yes.  You don't even need this extra MAC past the handshake,
you just need an extra key not known to the escrow agent for use in the
session resumption PSK.  (The extra MAC on every record would impose too
much overhead.)

> *The middlebox would not be able to verify the tag, so technically it can't
> check /everything/, but it would be able to read the data on the channel
> without being able to modify it.

Oh sure, if you're willing to do such violence to TLS, then yes, it can
be done.

However, a constraint here is that an escrow design can't really require
client-side modifications without the IETF approving of it and the
client implementations accepting the change.

The most obvious escrow design requiring no changes to the clients is to
use a static eDH key on the server-side.  The next most obvious such
design is to have the server talk to the escrow agent.

Nico
-- 

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Salz, Rich]

  *   Just to play devil's advocate, consider defining a new cipher suite that 
appended a MAC to each message before applying one of the other cipher suites.

But that would defeat their purpose, which is on-the-wire compatibility with 
real TLS.

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Jonathan Hoyland]

Is it necessarily true that any key escrow system must allow resumptions?

Just to play devil's advocate, consider defining a new cipher suite that
appended a MAC to each message before applying one of the other cipher
suites.
If the MAC is keyed with a key not derived from the master secret, but from
some other value shared between the client and server, but not the
middlebox, then the middlebox would be able to read all* the traffic, but
would not be able to successfully resume the session.

*The middlebox would not be able to verify the tag, so technically it can't
check /everything/, but it would be able to read the data on the channel
without being able to modify it.

Regards,

Jonathan



On Sun, 2 Dec 2018 at 23:36 Nico Williams  wrote:

> On Sat, Dec 01, 2018 at 07:59:45AM -0800, Tony Arcieri wrote:
> > This does not seem to address a problem which was brought up when the
> > similar draft-green-tls-static-dh-in-tls13-00 was discussed, namely any
> > system in possession of one of the non-ephemeral-ECDHE private keys,
> > ostensibly for the purposes of passive traffic decryption, can
> arbitrarily
> > resume decrypted sessions and therefore impersonate any observed clients.
> >
> > I'm not a fan of systems like this, but I believe for security reasons
> they
> > should be designed in such a way that only the confidentiality of traffic
> > is impacted, and a "visibility" system isn't able to leverage the
> decrypted
> > traffic to resume decrypted sessions and thereby impersonate clients.
>
> Any key escrow system will have this property.  Given the session keys
> (or a way to recover them) you can resume decrypted sessions.
>
> If I had to I would build a corporate TLS 1.3 session key escrow system
> as follows:
>
>  - use a keyed PRF/PRNG to generate the ephemeral DH keys, with two
>inputs, a secret key shared with the escrow third party, and a number
>generated randomly:
>
>edh_key = DH_key_gen(seed = PRF+(escrowed_key, r = getrandom()));
>
>  - log to the escrow third party {connection ID, random} for each
>connection (the connection ID can be a handshake transcript hash).
>
>(it's even safe to log the random number r in the clear, as it alone
>is insufficient for recovering session keys)
>
> This would preserve all the properties of TLS 1.3 and would work for any
> other version of TLS with EDH too, and also for any other protocols that
> use ephemeral key agreement (SSHv2, IKE, ...).
>
> It's more work to integrate this than to use RSA key transport with
> escrowed RSA key orchestration, but it's one-time work (do it for about
> six or so open source implementations and you've got 90+% coverage).
>
> I'm sure upstreams would accept this sort of contribution as it is
> better for everyone outside corporate environments if we can just stop
> the pressure to go back to RSA key transport.  It's also better for
> corporate environments, as insiders are the largest threat there, so
> forward security is still a plus even in corporate environments.
>
> Nico
> --
>
> ___
> 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] ETSI releases standards for enterprise security and data centre management

[Nico Williams]

On Sat, Dec 01, 2018 at 07:59:45AM -0800, Tony Arcieri wrote:
> This does not seem to address a problem which was brought up when the
> similar draft-green-tls-static-dh-in-tls13-00 was discussed, namely any
> system in possession of one of the non-ephemeral-ECDHE private keys,
> ostensibly for the purposes of passive traffic decryption, can arbitrarily
> resume decrypted sessions and therefore impersonate any observed clients.
> 
> I'm not a fan of systems like this, but I believe for security reasons they
> should be designed in such a way that only the confidentiality of traffic
> is impacted, and a "visibility" system isn't able to leverage the decrypted
> traffic to resume decrypted sessions and thereby impersonate clients.

Any key escrow system will have this property.  Given the session keys
(or a way to recover them) you can resume decrypted sessions.

If I had to I would build a corporate TLS 1.3 session key escrow system
as follows:

 - use a keyed PRF/PRNG to generate the ephemeral DH keys, with two
   inputs, a secret key shared with the escrow third party, and a number
   generated randomly:

   edh_key = DH_key_gen(seed = PRF+(escrowed_key, r = getrandom()));

 - log to the escrow third party {connection ID, random} for each
   connection (the connection ID can be a handshake transcript hash).

   (it's even safe to log the random number r in the clear, as it alone
   is insufficient for recovering session keys)

This would preserve all the properties of TLS 1.3 and would work for any
other version of TLS with EDH too, and also for any other protocols that
use ephemeral key agreement (SSHv2, IKE, ...).

It's more work to integrate this than to use RSA key transport with
escrowed RSA key orchestration, but it's one-time work (do it for about
six or so open source implementations and you've got 90+% coverage).

I'm sure upstreams would accept this sort of contribution as it is
better for everyone outside corporate environments if we can just stop
the pressure to go back to RSA key transport.  It's also better for
corporate environments, as insiders are the largest threat there, so
forward security is still a plus even in corporate environments.

Nico
-- 

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Blumenthal, Uri - 0553 - MITLL]

Exactly. I for one am against such "enhancements" and agree that treating them 
as errors is the right way.

Regards,
Uri

Sent from my iPhone

> On Dec 1, 2018, at 20:44, Christian Huitema  wrote:
> 
> 
>> On 12/1/2018 11:14 AM, Tony Rutkowski wrote:
>> 
>> The eTLS use case is an enterprise network or data center that is
>> owned or dedicated and under the control of a company (e.g., a
>> financial institution) or government agency that is subject to
>> compliance obligations that require auditing and traffic monitoring
>> capabilities for their systems and users.  This relatively bounded use
>> case should be kept in mind here.  The associated tutorial is
>> helpful. 
>> https://www.etsi.org/news-events/events/1338-2018-10-webinar-middlebox-security-protocol-explained
>> 
> 
> Which reinforces the idea that these "enhancements" have no legitimate
> reason to be found "in the wild", and hence should be treated as errors
> when detected.
> 
> -- Christian Huitema
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Christian Huitema]

On 12/1/2018 11:14 AM, Tony Rutkowski wrote:
>
> The eTLS use case is an enterprise network or data center that is
> owned or dedicated and under the control of a company (e.g., a
> financial institution) or government agency that is subject to
> compliance obligations that require auditing and traffic monitoring
> capabilities for their systems and users.  This relatively bounded use
> case should be kept in mind here.  The associated tutorial is
> helpful. 
> https://www.etsi.org/news-events/events/1338-2018-10-webinar-middlebox-security-protocol-explained
>

Which reinforces the idea that these "enhancements" have no legitimate
reason to be found "in the wild", and hence should be treated as errors
when detected.

-- Christian Huitema

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Stephen Farrell]

On 01/12/2018 09:10, Dmitry Belyavsky wrote:
> Dear All,
> 
> JFYI. Via Feisti Duck nerwsletter.
> 
> https://www.etsi.org/news-events/news/1358-2018-11-press-etsi-releases-standards-for-enterprise-security-and-data-centre-management

Yes, it is a shame that ETSI's role in transport security
appears to be to stick their noses in the trough of cast-off
proposals that didn't garner IETF consensus due to insecurity.

I hope that that properly (i.e., negatively), influences
people's opinions of ETSI, and of any government or industry
body so easily open to capture. Put another way, the IETF's
imperfect but terrifically open process considered this for
more than a year, (once there were people who raised the
topic, no matter how ineptly) and concluded there was no
consensus to even start such work, whereas ETSI appear to
have picked up those droppings and started and finished their
"standardisation" "process" (ironic quoting intended:-) in
roughly the same amount of time an open process requires to
conclude that such proposals are rubbish.

> 
> The eTLS key exchange shall use exactly the same messages and procedures to

I also hope the IETF aren't shy about enforcing copyright
on the name TLS. (Not that I understand copyright;-)

Cheers,
S.

> establish a set of session keys as a
> TLS 1.3 ephemeral Diffie-Hellman key exchange, except for two differences
> [2].
> 1) the server shall use a static public/private key pair at Step 2 in
> clause 4.3.1; and
> 2) the server's certificate at Step 5 shall contain visibility information
> as defined in clause 4.3.3 to indicate to the
> client that eTLS is in use.
> NOTE: Neither the static public key nor the visibility information affects
> the operation of a TLS 1.3 compliant
> client, so an eTLS server is therefore fully interoperable with TLS 1.3
> compliant clients.
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Christian Huitema]

On 12/1/2018 9:24 AM, Tony Arcieri wrote:
> On Sat, Dec 1, 2018 at 8:12 AM Dmitry Belyavsky  > wrote:
>
> I do not understand why the ETSI solution does not provide ability
> to impersonate clients/servers. 
>
>
> My understanding of this solution is a "visibility" system would have
> access to a not-so-ephemeral ECDHE private key. This gives it access
> (via passive observation) to all session keys ultimately derived from
> ECDHE key agreement, including the resumption master secret.


Which is indeed a huge problem. Security conscious implementations of
TLS should detect the use of such "enhancements", and either abort the
session or automatically treat it as insecure.

-- Christian Huitema

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Tony Arcieri]

On Sat, Dec 1, 2018 at 8:12 AM Dmitry Belyavsky  wrote:

> I do not understand why the ETSI solution does not provide ability to
> impersonate clients/servers.
>

My understanding of this solution is a "visibility" system would have
access to a not-so-ephemeral ECDHE private key. This gives it access (via
passive observation) to all session keys ultimately derived from ECDHE key
agreement, including the resumption master secret.

See RFC 8446, section 7.1: Key Schedule

(EC)DHE -> HKDF-Extract = Handshake Secret
 |
 +-> Derive-Secret(., "c hs traffic",
 | ClientHello...ServerHello)
 | = client_handshake_traffic_secret
 |
 +-> Derive-Secret(., "s hs traffic",
 | ClientHello...ServerHello)
 | = server_handshake_traffic_secret
 v
   Derive-Secret(., "derived", "")
 |
 v
   0 -> HKDF-Extract = Master Secret
 |
 +-> Derive-Secret(., "c ap traffic",
 | ClientHello...server Finished)
 | = client_application_traffic_secret_0
 |
 +-> Derive-Secret(., "s ap traffic",
 | ClientHello...server Finished)
 | = server_application_traffic_secret_0
 |
 +-> Derive-Secret(., "exp master",
 | ClientHello...server Finished)
 | = exporter_master_secret
 |
 +-> Derive-Secret(., "res master",
   ClientHello...client Finished)
   = resumption_master_secret


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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Dmitry Belyavsky]

On Sat, Dec 1, 2018 at 6:59 PM Tony Arcieri  wrote:

> This does not seem to address a problem which was brought up when the
> similar draft-green-tls-static-dh-in-tls13-00 was discussed, namely any
> system in possession of one of the non-ephemeral-ECDHE private keys,
> ostensibly for the purposes of passive traffic decryption, can arbitrarily
> resume decrypted sessions and therefore impersonate any observed clients.
>
> I'm not a fan of systems like this, but I believe for security reasons
> they should be designed in such a way that only the confidentiality of
> traffic is impacted, and a "visibility" system isn't able to leverage the
> decrypted traffic to resume decrypted sessions and thereby impersonate
> clients.
>

I do not understand why the ETSI solution does not provide ability to
impersonate clients/servers.

-- 
SY, Dmitry Belyavsky
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Tony Arcieri]

This does not seem to address a problem which was brought up when the
similar draft-green-tls-static-dh-in-tls13-00 was discussed, namely any
system in possession of one of the non-ephemeral-ECDHE private keys,
ostensibly for the purposes of passive traffic decryption, can arbitrarily
resume decrypted sessions and therefore impersonate any observed clients.

I'm not a fan of systems like this, but I believe for security reasons they
should be designed in such a way that only the confidentiality of traffic
is impacted, and a "visibility" system isn't able to leverage the decrypted
traffic to resume decrypted sessions and thereby impersonate clients.

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

[TLS] ETSI releases standards for enterprise security and data centre management

[Dmitry Belyavsky]

Dear All,

JFYI. Via Feisti Duck nerwsletter.

https://www.etsi.org/news-events/news/1358-2018-11-press-etsi-releases-standards-for-enterprise-security-and-data-centre-management

The eTLS key exchange shall use exactly the same messages and procedures to
establish a set of session keys as a
TLS 1.3 ephemeral Diffie-Hellman key exchange, except for two differences
[2].
1) the server shall use a static public/private key pair at Step 2 in
clause 4.3.1; and
2) the server's certificate at Step 5 shall contain visibility information
as defined in clause 4.3.3 to indicate to the
client that eTLS is in use.
NOTE: Neither the static public key nor the visibility information affects
the operation of a TLS 1.3 compliant
client, so an eTLS server is therefore fully interoperable with TLS 1.3
compliant clients.

-- 
SY, Dmitry Belyavsky
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls