Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)

[Wang Haiguang]

Dear all

Thanks very much for the discussion over the thread. We have learnt a lot from 
the discussion.

Due to the oversea travel, we were not able to send back our reply the comments 
from Ilari. Only yesterday, we got some time to prepare the reply. So in the 
below, we addressed the issue raised by Ilari and highlighted the answer in 
yellow collor.

We will continue our effort to improve the draft and will submit an updated 
draft once we finished.

Regards.

Haiguang


On Tue, Jul 04, 2017 at 08:47:16AM +, Wang Haiguang wrote:
> Dear all,
>
> This Haiguang Wang from Huawei Technology.
>
> I have submitted an IETF draft on using ECCSI public key for
> authentication over TLS protocols. It is the first version, so the
> draft still have a lot of spaces to improve.

Some feedback:

- I see the certificate message has single opaque field. This is the
same as RPK, but isn't trivially mappable to TLS 1.3. See TLS 1.3
draft section 4.4.2 on how TLS 1.3 handles RPK.

[Answer]: In fact, here we want to define a simple structure, and please see 
the definition of subjectIdentityBasedPublicKeyInfo. Thanks a lot for pointing 
to us TLS 1.3 for reference.


- I think you shouldn't duplicate existing arms in TLS structures.
See RFC 4279, section 4 for one example on omitting such arms.
- I think you shouldn't duplicate definitions of ClientCertificateType
and ServerCertificateType. Leave that to RFC 7250 and TLS 1.3 RFC.
You just need the certificate type value.

[Answer]: Thanks a lot for raising these issues and pointing out relevant 
references. We will rectify them in our subsequent versions.


- I think you shouldn't define a new key exchange algorithm, but
use ECDHE_ECDSA instead (like EdDSA does). Then get a new TLS 1.3
signatureScheme value, which decomposes to the corresponding TLS
1.2 values (see RFC4492bis for an example). However, this requires
TLS 1.2 or newer, but that should not be a problem.

[Answer]: Yes, exactly. Our intention is to use existing key exchange 
algorithm, but with a different signature scheme (just like EdDSA does, as you 
said). At the time of writing, we actually followed the TLS 1.2 convention, and 
later we will change to follow TLS 1.3.


- The proposed ciphersuites are really bad. No new blockmode or stream-
mode ciphers should be defined (especially blockmode, those are almost
impossible to implement in secure way). If ECDHE_ECDSA is used, one
avoids allocating any new ciphersuites.

[Answer]: We specified the ciphersuites according to TLS 1.2. We now realized 
that the way ciphersuites are defined has been changed in TLS 1.3, and we will 
follow accordingly later. In fact we have no intention to introduce new 
ciphersuites in the sense of TLS 1.3.


- Security considerations missing.
- IANA considerations missing, should ask for allocation of all
new codepoints (and that one OID).
- References section is duplicated.

[Answer]: We will add or rectify in the subsequent versions.

Anyway, our idea of the proposal is simple: to use a certificateless signature 
(RFC 6507) in TLS to avoid the certificate-based signatures, in order to avoid 
the hassle of certificates.







From: TLS [tls-boun...@ietf.org] on behalf of Martin Thomson 
[martin.thom...@gmail.com]
Sent: Monday, 10 July, 2017 7:48:57 AM
To: Russ Housley
Cc: IETF TLS
Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)

On 8 July 2017 at 05:40, Russ Housley  wrote:
> The TLS WG wants to work on a a way to combine a PSK with (EC)DH after the
> current specification is finished for quantum protection.

TLS 1.3 allows this already. The drawback being that you need to get
the PSK. At the moment, this means talking to the server once before
in most cases. I thought that the PQ plan was to add a new key
exchange paired with ECDH, along the lines of what was proposed in
draft-whyte-qsh-tls13-01 (I recall someone asking CFRG for advice on
combining of the outputs, but that doesn't seem to have gone
anywhere).

___
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] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-00.txt

[Kazuho Oku]

Thank you for writing the draft.

I agree for the need to hide hostnames from passive attackers, and I really
like the fact that the draft discusses of various attack vectors that a
proper SNI protection should take care of.

OTOH, it makes me sad that the proposed methods require an additional
roundtrip (when compared to no encrypted SNI).

Can't we consider adopting a method that improves both performance and
privacy, instead of choosing one between the two?

Specifically, I wonder if we could consider embedding part of the TLS
handshake within a secure DNS query / response. That will make the
connection setup even faster than today at the same time providing us more
privacy.

Note that regardless of the approach, it is mandatory to migrate DNS onto a
secure channel (i.e. over TLS or QUIC) in order to protect the hostname
that the client is going to access. Protecting just the SNI is insufficient.

Approach 1. embed TLS handshake in the DNS query and response

A client queries a DNS over a secure channel. ClientHello is embedded to
the DNS query. The resolver that receives the query will always contact the
authoritative server by using a secure channel, transmitting both the DNS
query and the ClientHello. Upon receiving the query, the authoritative
server will send a DNS response that embeds the server's first flight of
the TLS handshake (i.e. from ServerHello to ServerFinished). The resolver
relays the DNS response (with the handshake messages) to the client.

When the client receives the DNS response and the TLS handshake messages,
it connects to the server (that is designated by the DNS response) and
immediately sends the client's second flight of the TLS handshake (i.e.
ClientFinished) with an identifier that correlates that message to the
first flight of the messages transmitted through DNS, followed by
application data.

The merit of the approach is that connection setup will be even more faster
than now, since the time being spent changes from 1 RTT-to-DNS + 1
RTT-to-origin to 1 RTT-to-origin-through-DNS (note that reducing the
roundtrip to DNS has become important than before due to the fact that
resolvers are less common to be located near the client. This is especially
the case for mobile networks). Though there could be replay issues until
the client receives the server's first flight through the direct connection.

In short, the connection setup latency (including DNS) will be reduced from
2 RTT to 1 RTT, whereas in the approaches that are discussed in the draft
it will change from 2 RTT to 3 RTT.

Approach 2. embed TLS handshake originating from the server in DNS response

This is a variation of the former approach.

In this approach, a DNS query is sent over a secure channel but does not
convey any TLS handshake massage. OTOH it is the server that initiates the
handshake, upon receiving a DNS query. The DNS response (sent over a secure
channel) will include the necessary parameters to establish an end-to-end
secure channel (e.g. nonce, cryptographic parameters, server certificate,
and a signature signing the values). When the client receives the DNS
response that contains the handshake messages, it will use that to
establish a secure connection to the server (by sending it's nonce and the
negotiated parameters that are signed).

The time required for establishing a connection will be the same as the
first approach.

However, one interesting difference from the former approach is that it
will be possible for a DNS resolver to cache the DNS response including the
server's first flight of the handshake messages (at the cost of losing
single-op DH). Hence the change required to existing DNS infrastructure
could be somewhat smaller.

The risk would be that if the resolver reuses the DNS response, a passive
observer could determine whether if multiple new connections went to the
same origin (by looking at the identifier that designates the handshake
that the client is responding to). If that is an issue, a client may want
to inject randomness into the query to suppress the resolver from reusing
the response.

2017-06-22 13:25 GMT+09:00 Christian Huitema :

> We has many discussions of SNI encryption on this list recently, and that
> was enough motivation to write a draft about it. I am pretty sure that this
> will be met with wide approval and no discussion at all :-).
>
> -- Christian Huitema
>
>  Forwarded Message 
> Subject: New Version Notification for draft-huitema-tls-sni-
> encryption-00.txt
> Date: Wed, 21 Jun 2017 21:17:26 -0700
> From: internet-dra...@ietf.org
> To: Christian Huitema  , Eric
> Rescorla  
>
> A new version of I-D, draft-huitema-tls-sni-encryption-00.txt
> has been successfully submitted by Christian Huitema and posted to the
> IETF repository.
>
> Name: draft-huitema-tls-sni-encryption
> Revision: 00
> Title:SNI Encryption in TLS 

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

[Watson Ladd]

On Jul 10, 2017 4:09 PM, "Eric Mill"  wrote:

On Mon, Jul 10, 2017 at 6:07 PM, Russ Housley  wrote:
>
> >> So, I failed to convince you.  However, you have also failed to
> >> convince me that the proposal is wiretapping under the definition in
> >> RFC 2804, Section 3.
> >
> > 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?
>
> You are pointing to email.  Some MTAs will use SMTP over TLS, but many
> others do not.  It would be great if they all do, especially for the
> authentication.  In your response you are talking about an email system
> that has been using plaintext for ages, and you are trying to apply
> hop-by-hop a mechanism to the delivery.  Then, you are saying that the
> sender and receiver have confidentiality expectations that are being
> violated.  I do not buy it.
>

It seems like a weak counterargument to say that because there remain areas
where mail servers don't use TLS, that senders and receivers have no
expectation of confidentiality with email at all. Are you really saying
that if an MTA used this static-DH draft version of TLS to maintain keys to
decrypt email traffic, despite it only being "intended" for enterprise use,
that it wouldn't be wiretapping?

What about if/when MTA STS[1] is implemented? Will MTA adoption have to hit
100% before it's suddenly wiretapping for any given MTA to surreptitiously
use the static DH version of TLS that was "intended" only for enterprise
use?


I don't read RFC 2804 as applying to cases where intermediaries authorized
by a party to view information are handing it over. The MTA is authorized
by the recipient to be in the path and to look at the emails for all sorts
of reasons, and if they decide to hand over all your emails to someone else
via FTP, that's not a reason to be against FTP.

If it was to apply anything where a proxy service can be behind another
proxy would run afoul of this: they would proxy through the evesdropper. So
would reply-all, the most blatant cause of accidental evesdropping online.

Historically 2804 came out of (I think) a different situation where
signaling information related to interception was going to be included in
the protocol. Sadly it talks about sender and recipient without considering
cases where the identity is confused by subcontracting, and doesn't
distinguish cases like this which are similar to key escrow except there is
only one entity involved in the escrow.


-- Eric

[1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-06


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



-- 
konklone.com | @konklone 

___
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...

[Jeffrey Walton]

On Mon, Jul 10, 2017 at 3:37 PM, Stephen Farrell
 wrote:
>
> And if coercion of a server to comply with a wiretap
> scheme like this stills fanciful to you, please check
> out the history of lavabit - had there been a standard
> wiretap API as envisaged here it's pretty certain that
> would have been the device of choice in a case like that.
> While it's easy enough to envisage many other abuses
> that could be based on this wiretap scheme, that one is
> a good match and a real one.

There's a lot of insight based on the history.

If the mechanism operated at layer 3 or 4 (modify the protocol), then
the net is cast overly wide in a shared hosting arrangement. That is,
all virtual host's traffic is captured and recovered.

If it operates at layer 6 or 7 (modify the applications and/or its
libraries, like Apache or Nginx), then there is more precision in
target traffic. That is, only the target's traffic can captured and
recovered.

Jeff

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

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

[Eric Mill]

On Mon, Jul 10, 2017 at 6:07 PM, Russ Housley  wrote:
>
> >> So, I failed to convince you.  However, you have also failed to
> >> convince me that the proposal is wiretapping under the definition in
> >> RFC 2804, Section 3.
> >
> > 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?
>
> You are pointing to email.  Some MTAs will use SMTP over TLS, but many
> others do not.  It would be great if they all do, especially for the
> authentication.  In your response you are talking about an email system
> that has been using plaintext for ages, and you are trying to apply
> hop-by-hop a mechanism to the delivery.  Then, you are saying that the
> sender and receiver have confidentiality expectations that are being
> violated.  I do not buy it.
>

It seems like a weak counterargument to say that because there remain areas
where mail servers don't use TLS, that senders and receivers have no
expectation of confidentiality with email at all. Are you really saying
that if an MTA used this static-DH draft version of TLS to maintain keys to
decrypt email traffic, despite it only being "intended" for enterprise use,
that it wouldn't be wiretapping?

What about if/when MTA STS[1] is implemented? Will MTA adoption have to hit
100% before it's suddenly wiretapping for any given MTA to surreptitiously
use the static DH version of TLS that was "intended" only for enterprise
use?

-- Eric

[1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-06


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



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

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

[Stephen Farrell]

On 10/07/17 23:32, Russ Housley wrote:
> Stephen:
> 
> 
>> And to avoid a repeat of Russ' failed justification, many
>> protocols use and depend on TLS where the entity
>> controlling the TLS server private key materials is not the
>> higher layer sender or receiver, so all four points in the
>> definition in 2804 are fully met by your wiretapping
>> scheme.
> 
> It is clear that you do not agree with the reasoning that I
> posted on Friday.  Some people do, and clearly, others do
> not.
> 
> So, I failed to convince you.  However, you have also failed
> to convince me that the proposal is wiretapping under the
> definition in RFC 2804, Section 3.
 
 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?
>>> 
>>> You are pointing to email.  Some MTAs will use SMTP over TLS, but
>>> many others do not.  It would be great if they all do, especially
>>> for the authentication.  In your response you are talking about
>>> an email system that has been using plaintext for ages, and you
>>> are trying to apply hop-by-hop a mechanism to the delivery.
>>> Then, you are saying that the sender and receiver have
>>> confidentiality expectations that are being violated.  I do not
>>> buy it.
>> 
>> See [1].
>> 
>> Those show nearly 90% of mails being encrypted with TLS now.
>> 
>> In many mail deployments there will be an added hop e.g. for
>> anti-spam (we do that here in tcd) to an outside party.
>> 
>> While not 100% of mail is encrypted with TLS on all hops, much is.
>> (And the UTA WG are developing MTA-STS to try improve that.)
>> 
>> If one of those external parties implements your scheme then mail
>> senders and receivers will not know and that real TLS application
>> meets the 2804 definition for lots and lots and lots of emails.
>> 
>> Hence, 2804 applies here and the standards-track label ought be
>> removed.
>> 
>> S.
>> 
>> [1] https://www.google.com/transparencyreport/saferemail/
> 
> I'm glad that TLS is being used to protect email delivery.
> 
> I do not see how this changes the expectation discussed in RFC 2804,
> Section 3, Item number 3.
> 

Talk to our (tcd.ie) or gmail's mail admin folks. Their
expectations count too. (Or are we against enterprise
requirements or something? ;-)

S.

> Russ
> 
> 
> 



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

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

[Russ Housley]

Stephen:

 
> And to avoid a repeat of Russ' failed justification, many protocols
> use and depend on TLS where the entity controlling the TLS server
> private key materials is not the higher layer sender or receiver,
> so all four points in the definition in 2804 are fully met by your
> wiretapping scheme.
 
 It is clear that you do not agree with the reasoning that I posted on
 Friday.  Some people do, and clearly, others do not.
 
 So, I failed to convince you.  However, you have also failed to
 convince me that the proposal is wiretapping under the definition in
 RFC 2804, Section 3.
>>> 
>>> 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?
>> 
>> You are pointing to email.  Some MTAs will use SMTP over TLS, but many 
>> others do not.  It would be great if they all do, especially for the 
>> authentication.  In your response you are talking about an email system that 
>> has been using plaintext for ages, and you are trying to apply hop-by-hop a 
>> mechanism to the delivery.  Then, you are saying that the sender and 
>> receiver have confidentiality expectations that are being violated.  I do 
>> not buy it.
> 
> See [1].
> 
> Those show nearly 90% of mails being encrypted with
> TLS now.
> 
> In many mail deployments there will be an added hop e.g.
> for anti-spam (we do that here in tcd) to an outside
> party.
> 
> While not 100% of mail is encrypted with TLS on all
> hops, much is. (And the UTA WG are developing MTA-STS
> to try improve that.)
> 
> If one of those external parties implements your
> scheme then mail senders and receivers will not know and
> that real TLS application meets the 2804 definition for
> lots and lots and lots of emails.
> 
> Hence, 2804 applies here and the standards-track label
> ought be removed.
> 
> S.
> 
> [1] https://www.google.com/transparencyreport/saferemail/

I'm glad that TLS is being used to protect email delivery.

I do not see how this changes the expectation discussed in RFC 2804, Section 3, 
Item number 3.

Russ


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

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

[Stephen Farrell]

On 10/07/17 23:07, Russ Housley wrote:
> Stephen:
> 
>>>
 And to avoid a repeat of Russ' failed justification, many protocols
 use and depend on TLS where the entity controlling the TLS server
 private key materials is not the higher layer sender or receiver,
 so all four points in the definition in 2804 are fully met by your
 wiretapping scheme.
>>>
>>> It is clear that you do not agree with the reasoning that I posted on
>>> Friday.  Some people do, and clearly, others do not.
>>>
>>> So, I failed to convince you.  However, you have also failed to
>>> convince me that the proposal is wiretapping under the definition in
>>> RFC 2804, Section 3.
>>
>> 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?
> 
> You are pointing to email.  Some MTAs will use SMTP over TLS, but many others 
> do not.  It would be great if they all do, especially for the authentication. 
>  In your response you are talking about an email system that has been using 
> plaintext for ages, and you are trying to apply hop-by-hop a mechanism to the 
> delivery.  Then, you are saying that the sender and receiver have 
> confidentiality expectations that are being violated.  I do not buy it.

See [1].

Those show nearly 90% of mails being encrypted with
TLS now.

In many mail deployments there will be an added hop e.g.
for anti-spam (we do that here in tcd) to an outside
party.

While not 100% of mail is encrypted with TLS on all
hops, much is. (And the UTA WG are developing MTA-STS
to try improve that.)

If one of those external parties implements your
scheme then mail senders and receivers will not know and
that real TLS application meets the 2804 definition for
lots and lots and lots of emails.

Hence, 2804 applies here and the standards-track label
ought be removed.

S.

[1] https://www.google.com/transparencyreport/saferemail/

> 
> Russ
> 
> 



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

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

[Russ Housley]

Stephen:

>> 
>>> And to avoid a repeat of Russ' failed justification, many protocols
>>> use and depend on TLS where the entity controlling the TLS server
>>> private key materials is not the higher layer sender or receiver,
>>> so all four points in the definition in 2804 are fully met by your
>>> wiretapping scheme.
>> 
>> It is clear that you do not agree with the reasoning that I posted on
>> Friday.  Some people do, and clearly, others do not.
>> 
>> So, I failed to convince you.  However, you have also failed to
>> convince me that the proposal is wiretapping under the definition in
>> RFC 2804, Section 3.
> 
> 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?

You are pointing to email.  Some MTAs will use SMTP over TLS, but many others 
do not.  It would be great if they all do, especially for the authentication.  
In your response you are talking about an email system that has been using 
plaintext for ages, and you are trying to apply hop-by-hop a mechanism to the 
delivery.  Then, you are saying that the sender and receiver have 
confidentiality expectations that are being violated.  I do not buy it.

Russ

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

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

[Stephen Farrell]

On 10/07/17 22:26, Russ Housley wrote:
> Stephen:
> 
>> And to avoid a repeat of Russ' failed justification, many protocols
>> use and depend on TLS where the entity controlling the TLS server
>> private key materials is not the higher layer sender or receiver,
>> so all four points in the definition in 2804 are fully met by your
>> wiretapping scheme.
> 
> It is clear that you do not agree with the reasoning that I posted on
> Friday.  Some people do, and clearly, others do not.
> 
> So, I failed to convince you.  However, you have also failed to
> convince me that the proposal is wiretapping under the definition in
> RFC 2804, Section 3.

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?

S.

> 
> Russ
> 
> 



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

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

[Russ Housley]

Stephen:

> And to avoid a repeat of Russ' failed justification, many
> protocols use and depend on TLS where the entity controlling
> the TLS server private key materials is not the higher
> layer sender or receiver, so all four points in the definition
> in 2804 are fully met by your wiretapping scheme.

It is clear that you do not agree with the reasoning that I posted on Friday.  
Some people do, and clearly, others do not.

So, I failed to convince you.  However, you have also failed to convince me 
that the proposal is wiretapping under the definition in RFC 2804, Section 3.

Russ

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

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

[Sean Turner]

> On Jul 10, 2017, at 15:29, Stephen Farrell  wrote:
> 
> You did not respond about the Prague agenda. I continue to ask that
> you not give this bad idea more f2f time. If you do give it time,
> then I'd ask for equal time to debunk this bad idea. But better to
> have zero time.

Thanks for point this out.  We have adjusted the agenda but only to make room 
for 
draft-ietf-tls-dnssec-chain-extension and to rearrange the topics:
https://www.ietf.org/proceedings/99/agenda/agenda-99-tls-01
Note that the time allocated for this topics includes discussion time, where I 
have no there will be a mad dash to get to the mic.

spt

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

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

[Ackermann, Michael]

Most Enterprises do have well developed logging collection and parsing 
infrastructures (e.g. Splunk, etc.). But they are one of many tools needed 
to effectively manage complex corporate networks and applications.They 
cannot fully replace network monitoring any more than network monitoring can 
replace logging, IMHO.

I do agree that it would be optimal for all perspectives and requirements to be 
introduced as early in the process as possible.Hence one of the motivations 
for attempting to get Enterprises more active in IETF,  in general.


From: Watson Ladd [mailto:watsonbl...@gmail.com]
Sent: Monday, July 10, 2017 4:11 PM
To: Ackermann, Michael 
Cc: Polk, Tim (Fed) ; tls@ietf.org
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...



On Jul 10, 2017 8:46 AM, "Ackermann, Michael" 
> wrote:
+1 !!!

And
For the enterprise situations,  we typically own, operate and manage the 
involved “Facilities”:
The Servers
The Applications
The Networks
The Keys
The Data
and in Many cases the clients as well

Given the above scenario,  I do not understand how this can be construed as 
“Wiretapping”.2804 seems to make this clear.

What Enterprises want in this space, is the ability to continue to have access 
to their aforementioned facilities,  to perform diagnostics, monitoring and 
security functions.   (i.e. continue to effectively operate and manage our 
networks).  Although I believe the Matt Green draft proposes a very good, 
viable and well thought out solution for TLS 1.3,  I suspect most of us are 
open to different or better solutions,  if such exists or can be conceived.
There seems to be good discussion, requirements and ideas on both sides of this 
issue,  albeit in sharp disagreement in many cases.  Such critical 
colloquy,  with significant long term impact,  should not be prematurely 
terminated,  IMHO.


Finally an editorial comment from those of us TRYING to get Enterprises 
involved at IETF.   We finally have some interest and engagement from 
Enterprise perspectives. Killing discussion on this issue,  which is 
clearly important to Enterprises, will send the message that IETF did not 
really want this input or feedback.  I hope this is not the case.

One vertical is not all enterprises. Plenty of companies can trace requests via 
logging systems and do not need mirroring for diagnostics.

Perhaps if we weren't faced with a last minute request to include static 
ciphersuites things would be different. But the technique exists and can be 
used regardless of approval. (Have you considered Dual EC+extended random?)

The problem->box model has never been well-suited for the internet. There are 
serious policy considerations here and a long agenda for this WG. Stopping 
discussion is not about ignoring the problem: it's stopping a discussion going 
nowhere from eating up all the bandwidth.

From: TLS [mailto:tls-boun...@ietf.org] On Behalf 
Of Polk, Tim (Fed)
Sent: Monday, July 10, 2017 9:54 AM
To: tls@ietf.org
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...

First, I do not see this as a “wiretapping discussion” based on my reading of 
2804, although others may disagree.

Second, I believe that this discussion should go forward based on several 
points:

  1.  this proposal does not involve any changes to the bits on the wire 
specified in the TLS 1.3 document
  2.  this proposal offers significantly better security properties than 
current practice (central distribution of static RSA keys)
  3.  alternative solutions with significantly worse security properties are 
also feasible under TLS 1.3, and I would like to avoid them!

We should be in the business of developing pragmatic, interoperable solutions 
with appropriate security properties.  Balancing cryptographic security with 
other security requirements to achieve such solutions should be an acceptable 
path, and pursuing this work in the TLS working group gives the IETF the best 
opportunity to influence these solutions.





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



The information contained in this 

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

[Stephen Farrell]

On 10/07/17 21:20, Ackermann, Michael wrote:
> Then we read 2804 differently. When I read 2804,  the contained
> discourses on what is and is not wiretapping,  clearly says to me,
> that what Enterprises do within their networks,  is NOT wiretapping
> according to 2804 (or to me for that matter).

You're misunderstanding what 2804 says and what the
IETF is about. 2804 says nothing about your, or my,
network at all. You are free to define middle-endian
ordering and three-valued bits if you want or to do
whatever forms of wiretapping you like in your n/w.

2804 is instead about standards track protocols as
specified by the IETF, which are used in many networks.

In the case of TLS the changes for which you are
arguing would clearly enable wiretapping in many networks
and the draft is therefore clearly inconsistent with 2804
and the standards track.

And to avoid a repeat of Russ' failed justification, many
protocols use and depend on TLS where the entity controlling
the TLS server private key materials is not the higher
layer sender or receiver, so all four points in the definition
in 2804 are fully met by your wiretapping scheme. If you want
examples, think about STMP with STARTTLS or CDNs and the web.
I'm sure there are loads of others.

Bottom line: that draft is a wiretapping draft.

At best, it ought be an ISE RFC, and even then I could see
arguments against that if what is documented has not actually
been deployed. (That last seems to me to be needed to acquire
the utility of publication described in 2804 - RFCs about
speculative schemes don't seem to me to offer any value
at all.)

S.


> 
> We (and many others in this discussion),  have different
> perspectives.   Perhaps this is a contributing reason the Chairs
> determined it should continue. I sincerely hope this will lead to
> some mutually acceptable dialogue and related solutions.
> 
> 
> 
> -Original Message- From: Stephen Farrell
> [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, July 10, 2017 3:37
> PM To: Ackermann, Michael ; Polk, Tim (Fed)
> ; tls@ietf.org Subject: Re: [TLS] chairs -
> please shutdown wiretapping discussion...
> 
> 
> 
> On 10/07/17 16:30, Ackermann, Michael wrote:
>> Given the above scenario,  I do not understand how this can be
>> construed as "Wiretapping".2804 seems to make this clear.
> 
> TLS is much more widely used that you seem to imagine.
> 
> Please see the comments to the effect that there is no way to control
> to location of the wiretap/TLS-decrypter in the protocol.
> 
> If that's not obvious, I don't know how to explain it further.
> 
> See also text in 2804 wrt tools being used for more than initially
> envisaged.
> 
> And if coercion of a server to comply with a wiretap scheme like this
> stills fanciful to you, please check out the history of lavabit - had
> there been a standard wiretap API as envisaged here it's pretty
> certain that would have been the device of choice in a case like
> that. While it's easy enough to envisage many other abuses that could
> be based on this wiretap scheme, that one is a good match and a real
> one.
> 
>> Such critical colloquy,  with significant long term impact,  should
>>  not be prematurely terminated,  IMHO
> 
> "Premature" is nonsense, this debate has gone on too long already.
> 
> S.
> 
> 
> 
> 
> 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.
> 



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

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

[Ackermann, Michael]

Then we read 2804 differently. When I read 2804,  the contained discourses 
on what is and is not wiretapping,  clearly says to me,  that what Enterprises 
do within their networks,  is NOT wiretapping according to 2804 (or to me for 
that matter).  

We (and many others in this discussion),  have different perspectives.   
Perhaps this is a contributing reason the Chairs determined it should continue. 
I sincerely hope this will lead to some mutually acceptable dialogue and 
related solutions.  



-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
Sent: Monday, July 10, 2017 3:37 PM
To: Ackermann, Michael ; Polk, Tim (Fed) 
; tls@ietf.org
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...



On 10/07/17 16:30, Ackermann, Michael wrote:
> Given the above scenario,  I do not understand how this can be construed as 
> "Wiretapping".2804 seems to make this clear.

TLS is much more widely used that you seem to imagine.

Please see the comments to the effect that there is no way to control to 
location of the wiretap/TLS-decrypter in the protocol.

If that's not obvious, I don't know how to explain it further.

See also text in 2804 wrt tools being used for more than initially envisaged.

And if coercion of a server to comply with a wiretap scheme like this stills 
fanciful to you, please check out the history of lavabit - had there been a 
standard wiretap API as envisaged here it's pretty certain that would have been 
the device of choice in a case like that.
While it's easy enough to envisage many other abuses that could be based on 
this wiretap scheme, that one is a good match and a real one.

> Such critical colloquy,  with significant long term impact,  should 
> not be prematurely terminated,  IMHO

"Premature" is nonsense, this debate has gone on too long already.

S.




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] chairs - please shutdown wiretapping discussion...

[Watson Ladd]

On Jul 10, 2017 8:46 AM, "Ackermann, Michael"  wrote:

+1 !!!



And

For the enterprise situations,  we typically own, operate and manage the
involved “Facilities”:

The Servers

The Applications

The Networks

The Keys

The Data
and in Many cases the clients as well



Given the above scenario,  I do not understand how this can be construed as
“Wiretapping”.2804 seems to make this clear.



What Enterprises want in this space, is the ability to continue to have
access to their aforementioned facilities,  to perform diagnostics,
monitoring and security functions.   (i.e. continue to effectively operate
and manage our networks).  Although I believe the Matt Green draft proposes
a very good, viable and well thought out solution for TLS 1.3,  I suspect
most of us are open to different or better solutions,  if such exists or
can be conceived.

There seems to be good discussion, requirements and ideas on both sides of
this issue,  albeit in sharp disagreement in many cases.  Such critical
colloquy,  with significant long term impact,  should not be prematurely
terminated,  IMHO.





Finally an editorial comment from those of us TRYING to get Enterprises
involved at IETF.   We finally have some interest and engagement from
Enterprise perspectives. Killing discussion on this issue,  which is
clearly important to Enterprises, will send the message that IETF did not
really want this input or feedback.  I hope this is not the case.


One vertical is not all enterprises. Plenty of companies can trace requests
via logging systems and do not need mirroring for diagnostics.

Perhaps if we weren't faced with a last minute request to include static
ciphersuites things would be different. But the technique exists and can be
used regardless of approval. (Have you considered Dual EC+extended random?)

The problem->box model has never been well-suited for the internet. There
are serious policy considerations here and a long agenda for this WG.
Stopping discussion is not about ignoring the problem: it's stopping a
discussion going nowhere from eating up all the bandwidth.



*From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Polk, Tim (Fed)
*Sent:* Monday, July 10, 2017 9:54 AM
*To:* tls@ietf.org
*Subject:* Re: [TLS] chairs - please shutdown wiretapping discussion...



First, I do not see this as a “wiretapping discussion” based on my reading
of 2804, although others may disagree.



Second, I believe that this discussion should go forward based on several
points:

   1. this proposal does not involve any changes to the bits on the wire
   specified in the TLS 1.3 document
   2. this proposal offers significantly better security properties than
   current practice (central distribution of static RSA keys)
   3. alternative solutions with significantly worse security properties
   are also feasible under TLS 1.3, and I would like to avoid them!



We should be in the business of developing pragmatic, interoperable
solutions with appropriate security properties.  Balancing cryptographic
security with other security requirements to achieve such solutions should
be an acceptable path, and pursuing this work in the TLS working group
gives the IETF the best opportunity to influence these solutions.







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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

On Mon, Jul 10, 2017 at 08:29:26PM +0100, Stephen Farrell wrote:
> On 10/07/17 17:57, Sean Turner wrote:
> > After some discussion amongst the chairs, we have decided to not shut
> > down the discussion about draft-green-tls-static-dh-in-tls13.  
> 
> Ok, that's your call. But a bad call IMO.

IMO there's a trivial fix: make draft-green-tls-static-dh-in-tls13 an
individual submission targeting Informational, and allow discussion on
the TLS WG without making it a WG item (meaning, too, that no WG
milestone should refer to it).

Given that the entire text of draft-green-tls-static-dh-in-tls13 looks
like it's informational ("if you want key escrow with TLS 1.3, this is
how you might do it"), Informational looks right.

(BCP would not be appropriate, since on the cap-I Internet we would want
this deployed.  And as to intranets, we don't care.)

An I-D specifying a protocol for doing key auditing for escrow purposes
could be Standards-Track, since it could be a protocol that many need to
interop with.  But it wouldn't necessarily be a TLS WG item.  And we
might still want it to be Informational (since we can specify protocols
that way as well).

Nico
-- 

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

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

[Stephen Farrell]

On 10/07/17 17:42, Colm MacCárthaigh wrote:
> It's clear that there is a strong distaste here for the kind of MITM being
> talked about

It is not (only) "distaste," it is IETF policy as a result of
a significant debate on wiretapping.

S



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

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

[Stephen Farrell]

On 10/07/17 16:30, Ackermann, Michael wrote:
> Given the above scenario,  I do not understand how this can be construed as 
> "Wiretapping".2804 seems to make this clear.

TLS is much more widely used that you seem to imagine.

Please see the comments to the effect that there is no
way to control to location of the wiretap/TLS-decrypter
in the protocol.

If that's not obvious, I don't know how to explain it
further.

See also text in 2804 wrt tools being used for more than
initially envisaged.

And if coercion of a server to comply with a wiretap
scheme like this stills fanciful to you, please check
out the history of lavabit - had there been a standard
wiretap API as envisaged here it's pretty certain that
would have been the device of choice in a case like that.
While it's easy enough to envisage many other abuses
that could be based on this wiretap scheme, that one is
a good match and a real one.

> Such critical colloquy,  with significant long term
> impact,  should not be prematurely terminated,  IMHO

"Premature" is nonsense, this debate has gone on too long
already.

S.




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

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

[Stephen Farrell]

On 10/07/17 20:07, Blumenthal, Uri - 0553 - MITLL wrote:
> My $0.02: absolutely not on the Standards Track (for reasons already
> expressed by others), might be discussable if Informational.

I haven't checked, but as far as I recall, other wiretapping
RFCs inconsistent with 2804 have all been in the ISE stream
(or predate it) and have all documented already deployed
wiretapping schemes. I think that is consistent with 2804 and
using a WG list and WG participant cycles/attention to
debate/develop wiretapping methods does go against 2804 and
ought not be done.

S.

> 
> -- Regards, Uri Blumenthal
> 
> On 7/10/17, 15:03, "TLS on behalf of Nico Williams"
>  wrote:
> 
> On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote:
>>> On 10 Jul 2017, at 17:16, Stephen Farrell
>>>  wrote:
 2.  this proposal offers significantly better security
 properties than current practice (central distribution of
 static RSA keys)
>>> 
>>> I fail to see any relevant difference in security properties 
>>> between those two, never mind a significant improvement.
>> 
>> I can see one way in which it is worse.
>> 
>> With static RSA keys, you can configure the server to use only PFS 
>> ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the
>> non-FS, you need to switch to RSA ciphersuites, and that would be
>> obvious to any client.  In fact, I think today a server would stick
>> out if it only supported RSA ciphersuites.
>> 
>> There is no way to know that a server is doing what it says in the 
>> draft. It’s completely opaque to the client.
>> 
>> However, in both cases the server does get FS. As long as the
>> server has not enabled RSA ciphersuites or exportable private key
>> shares, any recorded TLS stream is safe even if the attacker later
>> gets the private key.
> 
> Well, a client could observe reuse of server ECDHE public keys...
> 
> And servers can always share session keys with an auditing system. 
> There's no way a client could detect this.
> 
> I don't think we need to have the client KNOW what the server is
> doing because... how the heck can the server prove it's not
> publishing the client's secrets??  The server simply cannot prove
> that it is adhering to any privacy policy.
> 
> Brief reuse of server ECDHE public keys is an optimization.  I
> _think_ it's a safe optimization, and it's safer the shorter the
> reuse period is -- and correspondingly less safe the longer the reuse
> period.
> 
> But I would prefer that anyone wanting auditability just build that
> into their implementations as a proper audit capability.  Yes, it's
> more complex to later decrypt sessions, but it also doesn't mess with
> the protocol in any way.
> 
> That said, I wouldn't object to the proposal if it meant to be 
> Informational.  I don't see how a document that describes a possible
> a configuration (not protocol!) that is not relevant to the Internet 
> should be a Standards-Track RFC, or BCP for that matter.
> Informational will do.
> 
> 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
> 



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

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

[Stephen Farrell]

On 10/07/17 17:57, Sean Turner wrote:
> Stephen,
> 
> After some discussion amongst the chairs, we have decided to not shut
> down the discussion about draft-green-tls-static-dh-in-tls13.  

Ok, that's your call. But a bad call IMO.

This topic, if not the specific draft, was already the subject
of significant debate during which the use of static DH values
was raised. I think you are putting the WG participants through
repetitive calls here for no good reason. (The fact that a -01
was emitted and new authors added is not IMO a good reason.)

So I'd ask that you review the previous related threads and
consider again if the basic idea behind this hasn't already
been rejected by the WG in the recent past.

In text below I'll assume you do that but decide to have an
adoption call nonetheless (though I hope you review the mail
archive and decide to reconsider).

> We are
> not shutting down this discussion because this topic is relevant to
> the constituents on both sides of the issue in the working group and
> there is a concrete proposal to discuss. 

That seems to me to be a recipe for whack-a-mole - we have seen
these break-tls proposals over and over and handling it your way
seems like it'll encourage more of 'em.

> Now that we know the
> authors are going to ask for WG adoption, the resulting working
> group's consensus or lack of consensus on this approach will be
> useful information for other discussions that will happen in the
> broader IETF community regardless of the outcome.  

I have no idea of the process problems that that'll create if
the WG go crazy and decide to adopt this despite it conflicting
with 2804 and given all the inevitable follow up wiretapping
additions that'll be proposed for quic and pretty much everything
else, if the TLS wg are seen to "fold." Seems like a recipe for
lots of confused process lawyering to me, but hopefully that'll
not turn out to be an issue.

> Further, we intend
> for consensus on the issue to be called quickly.

I'm against it:-)

> 
> We also do not believe that this discussion is derailing the TLS1.3
> draft, we are consistently surprised by the WG’s bandwidth and the
> draft is out for a 2nd targeted WGLC.  As far as DTLS1.3, the
> specification is coming along but is not at a critical point where we
> believe this discussion will greatly detract from its development.
> 

You did not respond about the Prague agenda. I continue to ask that
you not give this bad idea more f2f time. If you do give it time,
then I'd ask for equal time to debunk this bad idea. But better to
have zero time.

S.

> J
> 
>> On Jul 8, 2017, at 05:17, Stephen Farrell
>>  wrote:
>> 
>> 
>> Sean/Joe,
>> 
>> This is a request that you, as chairs, shut down the distracting 
>> wiretapping discussion, at least until DTLS1.3 is done.
>> 
>> I have planned to spend time reading draft 21 and DTLS, but that 
>> won't happen if we keep having to fight off the latest attempts to
>> break TLS. I'd not be surprised if I weren't the only one finding
>> that distraction an irritating waste of time. Finishing TLS1.3 and
>> getting DTLS1.3 on the way surely needs to not be constantly
>> de-railed by these attempts to break TLS.
>> 
>> Therefore I'd ask that you declare this discussion closed for at 
>> least that long (i.e until DTLS1.3 is done).
>> 
>> I'd also ask that you not allocate agenda time for wiretapping in
>> Prague.
>> 
>> Thanks, S.
>> 
>> ___ TLS mailing list 
>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 
> 



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

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

[Blumenthal, Uri - 0553 - MITLL]

My $0.02: absolutely not on the Standards Track (for reasons already expressed 
by others), might be discussable if Informational.

--
Regards,
Uri Blumenthal

On 7/10/17, 15:03, "TLS on behalf of Nico Williams"  wrote:

On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote:
> > On 10 Jul 2017, at 17:16, Stephen Farrell  
wrote:
> >> 2.  this proposal offers
> >> significantly better security properties than current practice
> >> (central distribution of static RSA keys)
> > 
> > I fail to see any relevant difference in security properties
> > between those two, never mind a significant improvement.
> 
> I can see one way in which it is worse.
> 
> With static RSA keys, you can configure the server to use only PFS
> ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the non-FS,
> you need to switch to RSA ciphersuites, and that would be obvious to
> any client.  In fact, I think today a server would stick out if it
> only supported RSA ciphersuites.
> 
> There is no way to know that a server is doing what it says in the
> draft. It’s completely opaque to the client.
> 
> However, in both cases the server does get FS. As long as the server
> has not enabled RSA ciphersuites or exportable private key shares, any
> recorded TLS stream is safe even if the attacker later gets the
> private key.

Well, a client could observe reuse of server ECDHE public keys...

And servers can always share session keys with an auditing system.
There's no way a client could detect this.

I don't think we need to have the client KNOW what the server is doing
because... how the heck can the server prove it's not publishing the
client's secrets??  The server simply cannot prove that it is adhering
to any privacy policy.

Brief reuse of server ECDHE public keys is an optimization.  I _think_
it's a safe optimization, and it's safer the shorter the reuse period is
-- and correspondingly less safe the longer the reuse period.

But I would prefer that anyone wanting auditability just build that into
their implementations as a proper audit capability.  Yes, it's more
complex to later decrypt sessions, but it also doesn't mess with the
protocol in any way.

That said, I wouldn't object to the proposal if it meant to be
Informational.  I don't see how a document that describes a possible a
configuration (not protocol!) that is not relevant to the Internet
should be a Standards-Track RFC, or BCP for that matter.  Informational
will do.

Nico
-- 

___
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] chairs - please shutdown wiretapping discussion...

[Nico Williams]

On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote:
> > On 10 Jul 2017, at 17:16, Stephen Farrell  wrote:
> >> 2.  this proposal offers
> >> significantly better security properties than current practice
> >> (central distribution of static RSA keys)
> > 
> > I fail to see any relevant difference in security properties
> > between those two, never mind a significant improvement.
> 
> I can see one way in which it is worse.
> 
> With static RSA keys, you can configure the server to use only PFS
> ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the non-FS,
> you need to switch to RSA ciphersuites, and that would be obvious to
> any client.  In fact, I think today a server would stick out if it
> only supported RSA ciphersuites.
> 
> There is no way to know that a server is doing what it says in the
> draft. It’s completely opaque to the client.
> 
> However, in both cases the server does get FS. As long as the server
> has not enabled RSA ciphersuites or exportable private key shares, any
> recorded TLS stream is safe even if the attacker later gets the
> private key.

Well, a client could observe reuse of server ECDHE public keys...

And servers can always share session keys with an auditing system.
There's no way a client could detect this.

I don't think we need to have the client KNOW what the server is doing
because... how the heck can the server prove it's not publishing the
client's secrets??  The server simply cannot prove that it is adhering
to any privacy policy.

Brief reuse of server ECDHE public keys is an optimization.  I _think_
it's a safe optimization, and it's safer the shorter the reuse period is
-- and correspondingly less safe the longer the reuse period.

But I would prefer that anyone wanting auditability just build that into
their implementations as a proper audit capability.  Yes, it's more
complex to later decrypt sessions, but it also doesn't mess with the
protocol in any way.

That said, I wouldn't object to the proposal if it meant to be
Informational.  I don't see how a document that describes a possible a
configuration (not protocol!) that is not relevant to the Internet
should be a Standards-Track RFC, or BCP for that matter.  Informational
will do.

Nico
-- 

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

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

[Yoav Nir]

> On 10 Jul 2017, at 17:16, Stephen Farrell  wrote:
> 
> 
>> 2.  this proposal offers
>> significantly better security properties than current practice
>> (central distribution of static RSA keys)
> 
> I fail to see any relevant difference in security properties
> between those two, never mind a significant improvement.

I can see one way in which it is worse.

With static RSA keys, you can configure the server to use only PFS ciphesuites 
(ECDHE-RSA or DHE-RSA). If you want to enable the non-FS, you need to switch to 
RSA ciphersuites, and that would be obvious to any client.  In fact, I think 
today a server would stick out if it only supported RSA ciphersuites.

There is no way to know that a server is doing what it says in the draft. It’s 
completely opaque to the client.

However, in both cases the server does get FS. As long as the server has not 
enabled RSA ciphersuites or exportable private key shares, any recorded TLS 
stream is safe even if the attacker later gets the private key.

Yoav


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

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

[Sean Turner]

Stephen,

After some discussion amongst the chairs, we have decided to not shut down the 
discussion about draft-green-tls-static-dh-in-tls13.  We are not shutting down 
this discussion because this topic is relevant to the constituents on both 
sides of the issue in the working group and there is a concrete proposal to 
discuss.  Now that we know the authors are going to ask for WG adoption, the 
resulting working group's consensus or lack of consensus on this approach will 
be useful information for other discussions that will happen in the broader 
IETF community regardless of the outcome.  Further, we intend for consensus on 
the issue to be called quickly.

We also do not believe that this discussion is derailing the TLS1.3 draft, we 
are consistently surprised by the WG’s bandwidth and the draft is out for a 2nd 
targeted WGLC.  As far as DTLS1.3, the specification is coming along but is not 
at a critical point where we believe this discussion will greatly detract from 
its development.

J

> On Jul 8, 2017, at 05:17, Stephen Farrell  wrote:
> 
> 
> Sean/Joe,
> 
> This is a request that you, as chairs, shut down the distracting
> wiretapping discussion, at least until DTLS1.3 is done.
> 
> I have planned to spend time reading draft 21 and DTLS, but that
> won't happen if we keep having to fight off the latest attempts
> to break TLS. I'd not be surprised if I weren't the only one
> finding that distraction an irritating waste of time. Finishing
> TLS1.3 and getting DTLS1.3 on the way surely needs to not be
> constantly de-railed by these attempts to break TLS.
> 
> Therefore I'd ask that you declare this discussion closed for at
> least that long (i.e until DTLS1.3 is done).
> 
> I'd also ask that you not allocate agenda time for wiretapping
> in Prague.
> 
> Thanks,
> 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...

[Colm MacCárthaigh]

On Mon, Jul 10, 2017 at 8:14 AM, Nikos Mavrogiannopoulos 
wrote:

> Certainly, but that doesn't need to happen on this working group, nor
> protocols which implement similar solutions need to be called TLS.
>

I'll belabor this point: rather than thinking about what these providers
are owed, which is nothing, it is better to think about what is best for
TLS overall. Selfishly, I have a strong preference to see TLS1.3 succeed
and that within a matter of years, we no longer have to support TLS1.2 or
earlier versions.

If some networks and operators feel that they can't feasibly use TLS1.3,
they're very likely to stay on the older versions. We could consider
brinkmanship; and see who blinks first if we try to disable the older
versions anyway, but that's a gambit that often makes hostages out of
innocent users, and can end up serving to taint TLS1.3 with reliability
issues and hold back its adoption.

It's clear that there is a strong distaste here for the kind of MITM being
talked about, and many wish not to give it any kind of stamp of approval
within the standard; that that itself would also taint TLS1.3 with security
concerns. Proxies are proposed as a work-around instead, as it avoids any
changes to protocol. But this seems like cutting our noses off to spite our
faces. Proxies tend to be always-on and render plaintext much more
accessible than a tcpdump tap. Proxies are also inline, read-write, and
subject to exploit in a worse way than a tcpdump tap (which can be network
isolated). In real security terms, I absolutely buy that proxies would be
worse for overall security and all of the properties that TLS is supposed
to provide, in some environments. That would seem like a bizarre conclusion.

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

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

[Ackermann, Michael]

+1 !!!

And
For the enterprise situations,  we typically own, operate and manage the 
involved "Facilities":
The Servers
The Applications
The Networks
The Keys
The Data
and in Many cases the clients as well

Given the above scenario,  I do not understand how this can be construed as 
"Wiretapping".2804 seems to make this clear.

What Enterprises want in this space, is the ability to continue to have access 
to their aforementioned facilities,  to perform diagnostics, monitoring and 
security functions.   (i.e. continue to effectively operate and manage our 
networks).  Although I believe the Matt Green draft proposes a very good, 
viable and well thought out solution for TLS 1.3,  I suspect most of us are 
open to different or better solutions,  if such exists or can be conceived.
There seems to be good discussion, requirements and ideas on both sides of this 
issue,  albeit in sharp disagreement in many cases.  Such critical 
colloquy,  with significant long term impact,  should not be prematurely 
terminated,  IMHO.


Finally an editorial comment from those of us TRYING to get Enterprises 
involved at IETF.   We finally have some interest and engagement from 
Enterprise perspectives. Killing discussion on this issue,  which is 
clearly important to Enterprises, will send the message that IETF did not 
really want this input or feedback.  I hope this is not the case.

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Polk, Tim (Fed)
Sent: Monday, July 10, 2017 9:54 AM
To: tls@ietf.org
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...

First, I do not see this as a "wiretapping discussion" based on my reading of 
2804, although others may disagree.

Second, I believe that this discussion should go forward based on several 
points:

  1.  this proposal does not involve any changes to the bits on the wire 
specified in the TLS 1.3 document
  2.  this proposal offers significantly better security properties than 
current practice (central distribution of static RSA keys)
  3.  alternative solutions with significantly worse security properties are 
also feasible under TLS 1.3, and I would like to avoid them!

We should be in the business of developing pragmatic, interoperable solutions 
with appropriate security properties.  Balancing cryptographic security with 
other security requirements to achieve such solutions should be an acceptable 
path, and pursuing this work in the TLS working group gives the IETF the best 
opportunity to influence these solutions.





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] chairs - please shutdown wiretapping discussion...

[Nikos Mavrogiannopoulos]

On Mon, 2017-07-10 at 13:54 +, Polk, Tim (Fed) wrote:
> First, I do not see this as a “wiretapping discussion” based on my
> reading of 2804, although others may disagree.
>  
> Second, I believe that this discussion should go forward based on
> several points:
> this proposal does not involve any changes to the bits on the wire
> specified in the TLS 1.3 document
> this proposal offers significantly better security properties than
> current practice (central distribution of static RSA keys)
> alternative solutions with significantly worse security properties
> are also feasible under TLS 1.3, and I would like to avoid them!
>  
> We should be in the business of developing pragmatic, interoperable
> solutions with appropriate security properties.  Balancing
> cryptographic security with other security requirements to achieve
> such solutions should be an acceptable path, and pursuing this work
> in the TLS working group gives the IETF the best opportunity to
> influence these solutions.

Certainly, but that doesn't need to happen on this working group, nor
protocols which implement similar solutions need to be called TLS.

regards,
Nikos

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

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

[Stephen Farrell]

Hiya,

While we're waiting on Sean/Joe... :-)

On 10/07/17 14:54, Polk, Tim (Fed) wrote:
> First, I do not see this as a “wiretapping discussion” based on my
> reading of 2804, although others may disagree.

s/may/do/

Figure 3 in the draft is absolutely clearly describing
an architecture for wiretapping TLS connections. And I
see no way in which this scheme can avoid that problem
as there is no way in which the "TLS decrypter" can be
assured to be in any particular place in any network.
(If one did try fix that, then you end up in the mctls
muck.)

> 
> Second, I believe that this discussion should go forward based on
> several points:
> 
> 1.  this proposal does not involve any changes to the bits on the
> wire specified in the TLS 1.3 document 

I would assert that it substantially changes the semantics of
the bits emitted by standards-track TLS implementations. With
this, a client cannot know if it's application PDUs are being
decrypted from the middle of the network when talking to any
standards-compliant server. That basically breaks one of the
most important security properties of TLS.

> 2.  this proposal offers
> significantly better security properties than current practice
> (central distribution of static RSA keys) 

I fail to see any relevant difference in security properties
between those two, never mind a significant improvement.

> 3.  alternative solutions
> with significantly worse security properties are also feasible under
> TLS 1.3, and I would like to avoid them!

Yes. But that is not a justification to weaken security for
standards-track implementations of TLS1.3. We should not
standardise ways of doing crappy crypto would be my take.

> We should be in the business of developing pragmatic, interoperable
> solutions with appropriate security properties.  

Absolutely. This proposal, being inappropriate for the standards
track, should go visit /dev/null.

> Balancing
> cryptographic security with other security requirements to achieve
> such solutions should be an acceptable path, and pursuing this work
> in the TLS working group gives the IETF the best opportunity to
> influence these solutions.

See the raven mailing list I guess. That was specifically
discussed then.

S.


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



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

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

[Polk, Tim (Fed)]

First, I do not see this as a “wiretapping discussion” based on my reading of 
2804, although others may disagree.

Second, I believe that this discussion should go forward based on several 
points:

  1.  this proposal does not involve any changes to the bits on the wire 
specified in the TLS 1.3 document
  2.  this proposal offers significantly better security properties than 
current practice (central distribution of static RSA keys)
  3.  alternative solutions with significantly worse security properties are 
also feasible under TLS 1.3, and I would like to avoid them!

We should be in the business of developing pragmatic, interoperable solutions 
with appropriate security properties.  Balancing cryptographic security with 
other security requirements to achieve such solutions should be an acceptable 
path, and pursuing this work in the TLS working group gives the IETF the best 
opportunity to influence these solutions.



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

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

[Sean Turner]

Message received.  Expect a response in a couple of hours.

spt

> On Jul 8, 2017, at 05:17, Stephen Farrell  wrote:
> 
> 
> Sean/Joe,
> 
> This is a request that you, as chairs, shut down the distracting
> wiretapping discussion, at least until DTLS1.3 is done.
> 
> I have planned to spend time reading draft 21 and DTLS, but that
> won't happen if we keep having to fight off the latest attempts
> to break TLS. I'd not be surprised if I weren't the only one
> finding that distraction an irritating waste of time. Finishing
> TLS1.3 and getting DTLS1.3 on the way surely needs to not be
> constantly de-railed by these attempts to break TLS.
> 
> Therefore I'd ask that you declare this discussion closed for at
> least that long (i.e until DTLS1.3 is done).
> 
> I'd also ask that you not allocate agenda time for wiretapping
> in Prague.
> 
> Thanks,
> 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