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

[Tony Arcieri]

On Mon, Oct 23, 2017 at 6:31 PM Ackermann, Michael 
wrote:

> NO
> The objective is to be passively observe, out of band and not to be a MitM
> or modify/inject text.Just as we all do today.


You seem to be confused as to the difference between an active vs passive
MitM. Using the term “MitM” for a passive network observer, particularly
one which can decrypt traffic, is perfectly apt.

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

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

[Blumenthal, Uri - 0553 - MITLL]

Who cares about the objective? People are asking about the result.

Regards,
Uri

Sent from my iPhone

> On Oct 23, 2017, at 19:32, Ackermann, Michael  wrote:
> 
> NO
> The objective is to be passively observe, out of band and not to be a MitM or 
> modify/inject text.Just as we all do today.  
> 
> -Original Message-
> From: Benjamin Kaduk [mailto:bka...@akamai.com] 
> Sent: Monday, October 23, 2017 6:33 PM
> To: Ackermann, Michael ; Tony Arcieri 
> ; Adam Caudill 
> Cc: tls@ietf.org
> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
> 
>> On 10/23/2017 05:09 PM, Ackermann, Michael wrote:
>> No one I am aware of is pushing for a MitM capability to address this.   
>> In fact it was one of the alternative solutions for which many 
>> implementation issues were cited at the Prague meeting and on this 
>> list.But I would like to ask,  what is the solution that your 
>> company and others that you reference,  have solved this problem by 
>> implementing?
> 
> Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the
> SSWrapDH1 private key has the cryptographic capability to inject traffic and 
> modify plaintext for the affected connections?
> 
> -Ben
> 
> 
> 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


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

[TLS] DTLS 1.3 ACKs

[Eric Rescorla]

We now have DTLS 1.3 implemented in NSS, which went pretty cleanly.

The one thing we ran into was the potential need to ACK in cases where you
can't process *any* records (e.g., you receive what's actually EE, but you
can't decrypt it). In this case, you want to send an empty ACK.

See PR:
https://github.com/tlswg/dtls13-spec/pull/14

This will be going into -02 modulo big objections.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] TLS 1.3 Record Boundaries

[Andrei Popov]

Draft-21 says:
"Handshake messages MUST NOT span key changes.  Implementations
  MUST verify that all messages immediately preceding a key change
  align with a record boundary; if not, then they MUST terminate the
  connection with an "unexpected_message" alert.  Because the
  ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate
 messages can immediately precede a key change, implementations
  MUST send these messages in alignment with a record boundary."

It is not clear to me what "sending messages in alignment with a record 
boundary" means.
Does it mean that each record is either all plaintext or all encrypted with key 
X? And therefore one cannot combine, e.g., ServerHello (plaintext) and 
EncryptedExtensions (encrypted with the handshake traffic key) messages in one 
record?

Thanks,

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

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

[Ackermann, Michael]

NO
The objective is to be passively observe, out of band and not to be a MitM or 
modify/inject text.Just as we all do today.  

-Original Message-
From: Benjamin Kaduk [mailto:bka...@akamai.com] 
Sent: Monday, October 23, 2017 6:33 PM
To: Ackermann, Michael ; Tony Arcieri 
; Adam Caudill 
Cc: tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/23/2017 05:09 PM, Ackermann, Michael wrote:
> No one I am aware of is pushing for a MitM capability to address this.   
> In fact it was one of the alternative solutions for which many 
> implementation issues were cited at the Prague meeting and on this 
> list.    But I would like to ask,  what is the solution that your 
> company and others that you reference,  have solved this problem by 
> implementing?

Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the
SSWrapDH1 private key has the cryptographic capability to inject traffic and 
modify plaintext for the affected connections?

-Ben


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] Publication of draft-rhrd-tls-tls13-visibility-00

[Colm MacCárthaigh]

On Mon, Oct 23, 2017 at 3:30 PM, Benjamin Kaduk  wrote:
>  There are no doubt folks here would claim that the writing has been on the 
> wall for
> five years or more that static RSA was out and forward secrecy was on
> the way in, and that now is the right time to draw the line and drop the
> backwards compatibility.In fact, there is already presumed WG
> consensus for that position, so a strong argument indeed would be needed
> to shift the boundary from now.  I won't say that no such argument can
> exist, but I don't think we've seen it yet.

I don't have too strong an interest in this thread, it's not going
anywhere, and I don't mind that. But I do want to chime in and point
out that forward secrecy is not completely on the way in. With STEK
based 0-RTT, it sounds like many implementors are happy to see user's
requests, cookies, passwords and other secret tokens protected only by
symmetric keys that are widely shared across many machines and
geographic boundaries, with no defined key schedule, usage
requirements or forward secrecy. Clearly, the consensus has been
willing to accept that trade-off, and there is definite wiggle room.

-- 
Colm

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

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

[Benjamin Kaduk]

On 10/23/2017 05:09 PM, Ackermann, Michael wrote:
> No one I am aware of is pushing for a MitM capability to address
> this.   In fact it was one of the alternative solutions for which many
> implementation issues were cited at the Prague meeting and on this
> list.    But I would like to ask,  what is the solution that your
> company and others that you reference,  have solved this problem by
> implementing?   

Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the
SSWrapDH1 private key has the cryptographic capability to inject traffic
and modify plaintext for the affected connections?

-Ben

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

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

[Benjamin Kaduk]

On 10/23/2017 01:42 PM, Ackermann, Michael wrote:
>  But as stated in several previous Emails, the fact that TLS 1.2 is still 
> available,  does not mean that we won't  have applications, business units or 
> other entities that require TLS 1.3 and we will need to manage, monitor and 
> secure these, as well as older versions.

This seems sufficiently hypothetical so as to be non-actionable.

That is, I assume that any sufficiently large enterprise must have some
sort of architecture review process before a new system is deployed (and
if one does not, it seems highly unlikely to be secure).  There would
need to be some resolution of the conflict between those parties
"requiring" monitorability and those parties "requiring" TLS 1.3 before
such a system could get approved and approach deployment, so I feel
obligated to insert "require" into scare quotes and attribute no real
meaning to the statement.

As was stated previously, this is a case of being stuck between a rock
and a hard place.  While it is reasonable to investigate changing both
of the rock and the hard place, it seems unwise to presume that it is
one or the other specifically that must change.  You assert in a
different message that it would be very expensive and time consuming to
change "virtually every platform and application, not to mention all the
management, monitoring, and security platforms" (e.g., the "hard
place"), and I do not disagree.  It would also be expensive and time
consuming to modify the TLS 1.3 protocol (e.g., "the rock") in the
way(s) being proposed; unfortunately, the error bars on this cost
estimate are necessarily quite large so as to take into account the risk
of catastrophic breakdown of the security of the Internet.   It seems
pretty clear that various parties involved in this conversation are
applying different metric functions to weight these various costs, which
makes it hard to see a path that would appease everyone.

In that same "different message" you also mention that you have come to
expect backwards compatibility, but can you really expect backwards
compatibility without limit?  Does Windows 10 run MS-DOS executables? 
Can a Kerberos principal who last set their password using Kerberos 4
expect to interoperate in a modern Kerberos 5 deployment?  Can you still
log into a shell server via telnet?  There are many arguments in support
of backwards compatibility, but they are not universal, and history
provides plenty of precedent for security eventually overriding
backwards compatibility.  So where would you put the boundary on the
backwards compatibility for static RSA in TLS or equivalent
non-forward-secrecy mechanisms?  Would you propose infinite
compatibility in this space with no bound?  Ten years from now?  When a
quantum computer can quickly factor 2048-bit RSA keys?  There are no
doubt folks here would claim that the writing has been on the wall for
five years or more that static RSA was out and forward secrecy was on
the way in, and that now is the right time to draw the line and drop the
backwards compatibility.    In fact, there is already presumed WG
consensus for that position, so a strong argument indeed would be needed
to shift the boundary from now.  I won't say that no such argument can
exist, but I don't think we've seen it yet.

-Ben

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

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

[Ackermann, Michael]

This can be solved without changes to the protocol or a standardized “backdoor” 
- and is being done today by at least some enterprises.

Having worked (and presently working) for more than one company of this nature, 
in the payments business no less, I would like to restate that it's incredibly 
disingenuous to cite the need for self-MitM capability as an "industry" concern.

No one I am aware of is pushing for a MitM capability to address this.   In 
fact it was one of the alternative solutions for which many implementation 
issues were cited at the Prague meeting and on this list.But I would like 
to ask,  what is the solution that your company and others that you reference,  
have solved this problem by implementing?




From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Tony Arcieri
Sent: Monday, October 23, 2017 5:43 PM
To: Adam Caudill 
Cc: tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill 
> wrote:
Those advocating for some standardized method of subverting the security 
properties of TLS have been offered numerous options in good faith, and 
continue to reject them all. I’m aware of extremely large enterprises that in 
fact require TLS 1.2 with PFS, as they made the investment in addressing this 
issue early on, and do so effectively. This can be solved without changes to 
the protocol or a standardized “backdoor” - and is being done today by at least 
some enterprises.

Having worked (and presently working) for more than one company of this nature, 
in the payments business no less, I would like to restate that it's incredibly 
disingenuous to cite the need for self-MitM capability as an "industry" concern.

I think if it were possible to ask for a hum "from industry", you'd find the 
field divided between those who have invested in a real observability story, 
and those who think passive network traffic collection is the only way to debug 
their systems. I think if you were to even take a straw poll of the best 
approaches monitoring/observability among actual industry practitioners, 
passive network traffic collection would rank close to the bottom of the list.

I would go as far as to say that if you are among those requesting this 
misfeature, you are doing a terrible job securing your infrastructure, and 
should look into modern observability techniques as an alternative to debugging 
by concentrating network traffic dumps into a single point of compromise which 
represents a huge security liability. Yes, switching to a new approach to 
observability is a huge investment that will take time, but so is upgrading to 
a new version of TLS.

The "industry" reality is that many companies do not need a self-MitM 
misfeature and could be actively harmed by it, and while a self-MitM capability 
may be standard operating practice for some, it is not true for all, and 
identifying those who want the self-MitM capability as "industry" is a 
composition fallacy being leveraged as a rhetorical tactic, i.e. "IETF is not 
listening to the concerns of industry".

As a member of "industry" myself, I implore the IETF: please don't make the 
rest of us less secure at the request of those who are running insecure 
infrastructures and apparently intend on keeping things that way.


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] Closing PR#47 on draft-ietf-tls-iana-registry-updates

[Benjamin Kaduk]

On 10/23/2017 12:50 PM, Joseph Salowey wrote:
> ekr proposed a PR (#47) for  draft-ietf-tls-iana-registry-updates that
> clarified the specification required rules to include Internet Drafts.  
>
> I believe this is not the intent and we should close the issue.  
>
> I think the intent of specification required is to allow a community
> that needs a code point to make a specification available in a public
> location that is relevant to that community. I don't think an an I-D
> would be appropriate in most cases.
>

I'm inclined to agree, given that something with an explicit expiration
data cannot be considered "stable".

(There's also a bit of a circular dependency in that the allocation
would have to point to a preexisting I-D version that could not then be
updated to refer to the allocated value, though I don't expect that to
actually give anyone much pause.)

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

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

[Tony Arcieri]

On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill  wrote:

> Those advocating for some standardized method of subverting the security
> properties of TLS have been offered numerous options in good faith, and
> continue to reject them all. I’m aware of extremely large enterprises that
> in fact require TLS 1.2 with PFS, as they made the investment in addressing
> this issue early on, and do so effectively. This can be solved without
> changes to the protocol or a standardized “backdoor” - and is being done
> today by at least some enterprises.
>

Having worked (and presently working) for more than one company of this
nature, in the payments business no less, I would like to restate that it's
incredibly disingenuous to cite the need for self-MitM capability as an
"industry" concern.

I think if it were possible to ask for a hum "from industry", you'd find
the field divided between those who have invested in a real observability
story, and those who think passive network traffic collection is the only
way to debug their systems. I think if you were to even take a straw poll
of the best approaches monitoring/observability among actual industry
practitioners, passive network traffic collection would rank close to the
bottom of the list.

I would go as far as to say that if you are among those requesting this
misfeature, you are doing a terrible job securing your infrastructure, and
should look into modern observability techniques as an alternative to
debugging by concentrating network traffic dumps into a single point of
compromise which represents a huge security liability. Yes, switching to a
new approach to observability is a huge investment that will take time, but
so is upgrading to a new version of TLS.

The "industry" reality is that many companies do not need a self-MitM
misfeature and could be actively harmed by it, and while a self-MitM
capability may be standard operating practice for some, it is not true for
all, and identifying those who want the self-MitM capability as "industry"
is a composition fallacy being leveraged as a rhetorical tactic, i.e. "IETF
is not listening to the concerns of industry".

As a member of "industry" myself, I implore the IETF: please don't make the
rest of us less secure at the request of those who are running insecure
infrastructures and apparently intend on keeping things that way.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Mon, Oct 23, 2017 at 2:22 PM, Benjamin Kaduk  wrote:

> On 10/23/2017 07:12 AM, Eric Rescorla wrote:
>
>  Another comment is about symmetrical CID.
>>
>> 1.   Consider a client sends a normal CID (CID length is not zero,
>> named C-CID) to server, but the server doesn’t wants to use client’s CID
>> and sends a CID generated by the server (named S-CID) to the client.
>>
> No. The CID is for the client's benefit, so why would this be useful?
>
>
>> At the same time, client needs to know server has ignored C-CID (which
>> means the downlink application message from the server will not include
>> C-CID), and client will use S-CID in its application message. Will the
>> draft cover this scenario?
>>
> No.
>
>
> That is to say, this draft does not consider symmetrical CIDs at all.
>

You could of course echo the other side's CID, but no.

-Ekr


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

Re: [TLS] Connection ID Draft

[Benjamin Kaduk]

On 10/23/2017 07:12 AM, Eric Rescorla wrote:
>
>  Another comment is about symmetrical CID.
>
> 1.   Consider a client sends a normal CID (CID length is not
> zero, named C-CID) to server, but the server doesn’t wants to use
> client’s CID and sends a CID generated by the server (named S-CID)
> to the client.
>
> No. The CID is for the client's benefit, so why would this be useful?
>  
>
> At the same time, client needs to know server has ignored C-CID
> (which means the downlink application message from the server will
> not include C-CID), and client will use S-CID in its application
> message. Will the draft cover this scenario?
>
> No.

That is to say, this draft does not consider symmetrical CIDs at all.

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

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

[Adam Caudill]

To be honest, I’m rather surprised that this group continues to spend time
on this. I’m of the opinion that the chairs should step in and put this
discussion on hold until the work on TLS 1.3 is complete. This, and any
document of the same goal, are eating up time and energy that should be
directed to completing the work this group was chartered to do. There’s no
indication that there will be any consensus on moving forward with any such
document in this group, and I don’t think that will change any time soon.

Those advocating for some standardized method of subverting the security
properties of TLS have been offered numerous options in good faith, and
continue to reject them all. I’m aware of extremely large enterprises that
in fact require TLS 1.2 with PFS, as they made the investment in addressing
this issue early on, and do so effectively. This can be solved without
changes to the protocol or a standardized “backdoor” - and is being done
today by at least some enterprises.

I understand that this complicates the work that some do, and will mean
additional engineering or spending to deal with it, when they eventually
move to TLS 1.3; that said, I don’t think their decision to take the easy
route in traffic inspection and ignore the evolution of 1.3 till the last
moment should lead to adding new risk to every other TLS user, especially
those that invested in long term solutions that deal with these changes.

I’m of the opinion that this discussion is no longer productive; there’s no
indication that there will be consensus on this or similar documents, good
faith efforts have been made to offer alternatives - in multiple
discussions, it’s distracting from the work of completing 1.3. To me, the
most logical thing to do is move on, finish the work on 1.3, and then
reevaluate (not that I expect consensus to emerge then either).


-- 

--*Adam Caudill*
http://adamcaudill.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

 But as stated in several previous Emails, the fact that TLS 1.2 is still 
available,  does not mean that we won't  have applications, business units or 
other entities that require TLS 1.3 and we will need to manage, monitor and 
secure these, as well as older versions.  

-Original Message-
From: Salz, Rich [mailto:rs...@akamai.com] 
Sent: Friday, October 20, 2017 12:57 PM
To: Ackermann, Michael ; Stephen Farrell 
; Darin Pettis ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00



So it sounds like we are in agreement that continuing to use TLS 1.2 is not 
a viable long term  alternative.  


Long-term is a subjective term, and using it can lead to misunderstandings.

Based on current and previous actions around SSL and TLS versions, you can use 
TLS 1.2 for at least five, likely at least 10, years.





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] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

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

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

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


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

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

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

[Ackermann, Michael]

To suggest that I or my industry does not take security seriously, is 
inaccurate and immaterial to this discussion.

I would put the comment  that anyone or any industry is attempting to lay costs 
for anything off on IETF,  in the same unfortunate bucket.

These types of subjectively negative statements are not at all constructive, 
germane nor worthy of response.

From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Monday, October 23, 2017 1:45 PM
To: Ackermann, Michael 
Cc: Salz, Rich ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

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

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

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

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

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



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] Publication of draft-rhrd-tls-tls13-visibility-00

[Stephen Farrell]

On 23/10/17 18:30, Ackermann, Michael wrote:
> It is a huge proposition requiring change to virtually every platform
> and application.Not to mention all the management,  monitoring
> and security platforms. It would be very expensive and time
> consuming. And when they ask why this is necessary,  it is because
> the new version of the existing protocol is not backwards compatible,
> which is something we have come to expect.
All of these cost (*) arguments were raised in the draft-green
iteration of this nonsense. None of them are any different when
draft-green is replaced with draft-rehired.

The arguments did not convince before, and will not convince now.

They did not garner rough consensus before and I'm pretty happy
from list discussion that they don't seem to be doing so now.

Why do you insist on wasting the time of the WG? That seems
disruptive to me.

For the chairs:
- Various people have asked you to call a halt here.
- I do so again.
- Pretty-please even :-)

It seems clear this latest version of the same old bad idea
is going nowhere but /dev/null, as is proper. Please do declare
the discussion done.

S.

(*) The arguments here are of course all about moving the
cost to someone else, they are not about reducing costs. The
proponents of moving the cost elsewhere of course never seem
to admit that.



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

[TLS] Closing PR#47 on draft-ietf-tls-iana-registry-updates

[Joseph Salowey]

ekr proposed a PR (#47) for  draft-ietf-tls-iana-registry-updates that
clarified the specification required rules to include Internet Drafts.

I believe this is not the intent and we should close the issue.

I think the intent of specification required is to allow a community that
needs a code point to make a specification available in a public location
that is relevant to that community. I don't think an an I-D would be
appropriate in most cases.

Cheers,

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

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

[Salz, Rich]

  *   It is a huge proposition requiring change to virtually every platform and 
application.Not to mention all the management,  monitoring and security 
platforms.

Do you expect that this draft will require no changes to all your management, 
monitoring, and security platforms?



  *   And when they ask why this is necessary,  it is because the new version 
of the existing protocol is not backwards compatible,  which is something we 
have come to expect.

You have years to set the right expectation.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ackermann, Michael]

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

From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Monday, October 23, 2017 12:44 PM
To: Ackermann, Michael 
Cc: Salz, Rich ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 12:39 PM, Ackermann, Michael 
> wrote:

  1.  If staying with TLS 1.2 indefinitely was considered acceptable,  would we 
even be having these discussions?

This is a vacuous argument.   Nobody has provided any evidence of any kind that 
"enterprise" installations relying on TLS 1.2 would ever switch to TLS 1.3, 
much less that they would do so in any kind of hurry.   You demonstrate why 
with your very next bullet point:

  1.
  2.  Modifying Server,  application and logging infrastructure is a huge, 
expensive proposition,  that executive management would not be receptive to at 
all.   Not to mention the logistics to follow if they were.

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

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



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] Publication of draft-rhrd-tls-tls13-visibility-00

[Dave Garrett]

On 10/23/2017 12:39 PM, Ackermann, Michael wrote:

 2. Modifying Server,  application and logging infrastructure is a huge,
expensive proposition,  that executive management would not be
receptive to at all.   Not to mention the logistics to follow if
they were.


I'd just like to have everyone stop and focus on this, right here. This 
is the crux of everything. It takes effort and resources to upgrade your 
systems, and you don't want to do it. Tough; this is not the TLS WG's 
problem. The job here is to design the most secure protocol possible, 
and weakening things significantly to accommodate legacy methods is not 
a realistic option. Organizations will *always* have to expend effort 
and resources to upgrade to better systems. If that can be reduced 
without affecting security, great, but if not, then you're just going to 
have to accept it. People should not be here arguing against technical 
improvements; they should be with their managers explaining the simple 
reality of the situation. Yeah, I know it's hard to explain to executive 
management that they are not in control here, but they aren't.


I count at least 400+ messages on this list on this one topic. The 
answer is still "no". You're not getting a cheap drop-in replacement for 
your existing insecure use of static RSA keys out of this WG. Fixing 
devil's advocate qualms like whether or not clients have to send an 
extension is not enough to get even a rough consensus. Nontrivial, but 
very much viable, effort and resources will be required to upgrade.


https://en.wikipedia.org/wiki/Technical_debt


Dave

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

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

[Salz, Rich]

  1.  If staying with TLS 1.2 indefinitely was considered acceptable,  would we 
even be having these discussions?

DAMMIT.  Stop saying indefinitely.

What percentage of hosts within your enterprise use TLS 1.2 as the preferred 
protocol?


  1.  Modifying Server,  application and logging infrastructure is a huge, 
expensive proposition,  that executive management would not be receptive to at 
all.   Not to mention the logistics to follow if they were.

And this is probably the main point behind all this.  Folks want to make the 
entire Internet less secure (I’ve explained why) so that they can save time and 
money.

But even if that were not the issue, do you think this draft won’t require 
custom work?

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

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

[Ted Lemon]

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

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

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

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

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

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

[Hubert Kario]

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

so that they benefit from standardisation, network effects and be fiscally 
responsible!


 
> Regards,
> Uri
> 
> Sent from my iPhone
> 
> 
> > On Oct 19, 2017, at 13:08, Paul Turner  wrote:
> > 
> > 
> > 
> > 
> >> 
> >> Subverting one CA cuts across a large scale of Internet traffic and might
> >> be
 noticed or can be routed around.
> > 
> > 
> > With respect to "be noticed", forcing clients to opt-in seems like it
> > would clearly be noticed. My understanding was that you were saying that
> > the middlebox could block traffic. That seems in conflict with your
> > statement that they can be "routed around". 
 
> > 
> >> Certificate transparency helps prevent a
> >> single CA from being coerced into misissuance.  
> > 
> > 
> > It seems like a middlebox that is able to deny traffic (has that level of
> > power, would simply use their own CA and force trust of that)
 
> > 
> >> With this extension, someone
> >> doesn’t have to coerce a CA or force victims to trust a new CA.  Instead
> >> they have to gain the cooperation of the origin(s) they are interested
> >> in.>
> > 
> > Gaining the cooperation of the servers (origins) seems relevant. If they
> > get the cooperation of the servers, they can simply get the data directly
> > from them. But, again, they also have to get the cooperation of the
> > clients. 
 
> > If a middlebox has sufficient power to block traffic, force clients into
> > opting in, and coerce servers into opting in, it seems like they have
> > sufficient alternative options that are of equivalent effort ("ease").
 
> > 
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


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

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

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

[Ackermann, Michael]

Thanks Rich
I have seen these suggestions previously.
But as numerous messages on this chain, from various people have discussed, 
neither  of those suggestions are viable from an Enterprise Architecture 
planning perspective.


  1.  If staying with TLS 1.2 indefinitely was considered acceptable,  would we 
even be having these discussions?
  2.  Modifying Server,  application and logging infrastructure is a huge, 
expensive proposition,  that executive management would not be receptive to at 
all.   Not to mention the logistics to follow if they were.


From: Salz, Rich [mailto:rs...@akamai.com]
Sent: Monday, October 23, 2017 12:27 PM
To: Ackermann, Michael ; Ted Lemon 
Cc: tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00


  *   I am merely trying to understand if there are any constructive 
suggestions amongst all these discussions, that we should consider.

Yes.  To repeat myself, here are two:


  1.  Continue to use your existing schemes. You won’t have to change to TLS 
1.3 for years.
  2.  Modify your servers and logging infrastructure to report-out the PFS keys 
and use them

Do you need me to post links to my messages?



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] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon]

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

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

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


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

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

[Ted Lemon]

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

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

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


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

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

[Salz, Rich]

  *   Is there running code that demonstrates the IPsec+IKE can be deployed and 
operated at scale in the sort of environment the enterprise network tips have 
described to us?

IBM has supported full-scale IPsec/IKE deployment on System/z for a very long 
time, and it also has an interesting way of sharing/escrowing TLS session keys 
with Cisco boxes.

So if we can assume that many of these large enterprises have a mainframe, then 
they have the proofpoints behind their own firewall.

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

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

[Salz, Rich]

  *   I am merely trying to understand if there are any constructive 
suggestions amongst all these discussions, that we should consider.

Yes.  To repeat myself, here are two:


  1.  Continue to use your existing schemes. You won’t have to change to TLS 
1.3 for years.
  2.  Modify your servers and logging infrastructure to report-out the PFS keys 
and use them

Do you need me to post links to my messages?

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

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

[Ralph Droms]

> On Oct 22, 2017, at 2:40 PM, Ted Lemon  wrote:
> 
> On Oct 22, 2017, at 1:54 PM, Russ Housley  > wrote:
>> No one is requiring TLS 1.3 that I know about.  However, there are places 
>> that require visibility into TLS.  I will let one of the people that works 
>> in a regulated industry offer pointers to the documents.
> 
> What they require is visibility into contents of the flow that they are using 
> encryption to protect.   Right now, the protocol they are using is TLS 1.1 or 
> TLS 1.2.   The right thing for them to do if they continue to need this 
> visibility and are no longer permitted to use TLS 1.2 is to use IPsec+IKE,

Is there running code that demonstrates the IPsec+IKE can be deployed and 
operated at scale in the sort of environment the enterprise network tips have 
described to us?

> or some protocol that is designed for this use case, not to take a protocol 
> designed specifically for securing flows from on-path eavesdropping and 
> create a mode where it is easier to wiretap.

...assuming the necessary lead time and support from vendors to implement 
another protocol.

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

But TLS 1.3 addresses *part* of the use case, as it does provide better 
security and it represents an incremental change to the current deployment and 
operation practices.  

- Ralph

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

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

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

[Ackermann, Michael]

I am merely trying to understand if there are any constructive suggestions 
amongst all these discussions, that we should consider.

Your comment was
"It would be better to use a simpler protocol,"

My question back to you was WHAT SIMPLIER PROTOCOL?

If  your answer to my question,  is to refer to Kathleen's document,  then she 
discusses a few things.   If I have to guess which one of those you may be 
referring to,  I will guess IPSEC?
Is this correct?   Are you suggesting we should convert to IPSEC?

If that was stated in any previous correspondence,  I did not see it.

From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Monday, October 23, 2017 11:41 AM
To: Ackermann, Michael 
Cc: Steve Fenter ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

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

With respect, Michael, I gave my opinion in the message to which Kathleen 
replied, so your assertion that you have been reading these messages doesn't 
seem to be reflected in the dialog we are having.


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] Publication of draft-rhrd-tls-tls13-visibility-00

[Peter Saint-Andre]

On 10/22/17 5:26 PM, Steve Fenter wrote:
> I know of a number of large enterprises in verticals including financial, 
> health care, retail, and government, across multiple countries, who are using 
> packet payload inspection within their data centers.  Most of these 
> enterprises are reluctant to step forward in a public forum and reveal their 
> internal network structure and their internal security and monitoring 
> practices. This gives the false impression that out of band decryption of TLS 
> is not a big deal. It is in fact mission critical to a significant number of 
> large enterprises.
> 
> I have been saying to anyone who will listen that the IETF needs a private 
> forum for enterprises, to enable them to come forward and discuss their real 
> requirements. Without this input the IETF is trying to architect and engineer 
> solutions without knowing the complete set of requirements, at least on the 
> enterprise side.  This results in sub-optimal design decisions (from an 
> enterprise perspective), which in this case will break mission critical 
> enterprise monitoring and troubleshooting systems.

The IETF doesn't run private forums behind closed doors. You'd need to
do that kind of work elsewhere (these large enterprises could, of
course, start their own industry forum, where they could work in ways
that the IETF doesn't).

> We've already experienced what a rollout of TLS 1.3 will be like, at more 
> than one enterprise, when certain vendors decided to move Diffie Hellman 
> ciphers to the top of their priority list on a code upgrade. This caused 
> severity one outages of critical monitoring systems. 

It sounds as if different internal teams might not have been
communicating well about the rollout of those new cipher suites.
Operational issues in large enterprises are not a problem that requires
protocol work.

>  This means that critical applications depend on these monitoring systems, 
> and if the monitoring system is down the application is completely down. This 
> is not the outcome we want when TLS 1.3 is rolled out, but it is what we are 
> headed for. Enterprise monitoring should be tested as part of the operational 
> TLS 1.3 testing before TLS 1.3 is approved as a standard, and TLS 1.3 should 
> not be approved if enterprise monitoring breaks.

Operational testing is always good, but very strong arguments need to be
made for the latter claim. Among other things, you're adding a new
requirement to the Internet Standards Process, which would necessitate
IETF consensus on changes to RFC 2026!

> The only other option being presented to enterprises is that we continue to 
> run on a TLS spec that is nine years old, and then continue running it until 
> it is 14 to 19 years old. It makes no sense to me to put out a TLS 1.3 
> standard, but say that enterprises cannot upgrade to it.

There are many options, some of which Kathleen outlined in her blog
post. It's not helpful to say there is just one option when we haven't
fully explored either the problem space or the solution space. And by
"we" I mean especially those who are claiming the need for TLS visibility.

Peter




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

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

[Ted Lemon]

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

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

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

[Ackermann, Michael]

I have.
I was only asking what your opinion was, based on that statement in your reply.

From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Sunday, October 22, 2017 7:44 PM
To: Ackermann, Michael 
Cc: Steve Fenter ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

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

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



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] Connection ID Draft

[Eric Rescorla]

On Mon, Oct 23, 2017 at 12:53 AM, yinxinxing  wrote:

> Hi Ekr,
>
>
>
> For the post-handshake messages in the draft, I have some comments.
>
>
>
> 1.   When one peer sends NewconnectionID message to the other, it
> uses a newly defined handshake type. This new CID is attached in the
> payload of the record message. But there must be some information for the
> receiver to know which CID is going to be updated. I mean that when sending
> new CID through the NewConnectionID message, the record header should
> include the “old” CID, so that the receiver knows which one to replace.
>
The way that this mechanism works is that it either replaces all of them or
supplements the set. I'm not sure that this is the right dynamic, but I'd
first want to see some worked through cases.

2.   In the draft, is the new CID encrypted? I suggest that the new CID
> (for the first time sending) can be encrypted  to make sure that an
> attacker can not associate a new CID with an old CID. Let’s consider a case
> where an attacker wants to track an IOT device. If the newly generated CID
> is not encrypted when updating, the attacker can associate the new CID with
> the old one. Then, when the peer sends message with the new CID later, the
> attacker knows this packet is sent from the victim. If we encrypt the new
> CID when updating, this tracking problem can be avoided.
>

TLS 1.3 post-handshake messages are always encrypted.

 Another comment is about symmetrical CID.
>
> 1.   Consider a client sends a normal CID (CID length is not zero,
> named C-CID) to server, but the server doesn’t wants to use client’s CID
> and sends a CID generated by the server (named S-CID) to the client.
>
No. The CID is for the client's benefit, so why would this be useful?


> At the same time, client needs to know server has ignored C-CID (which
> means the downlink application message from the server will not include
> C-CID), and client will use S-CID in its application message. Will the
> draft cover this scenario?
>
No.

-Ekr


>
>
> Yin Xinxing
>
>
>
> *发件人:* Eric Rescorla [mailto:e...@rtfm.com]
> *发送时间:* 2017年10月13日 21:00
> *收件人:* yinxinxing
> *抄送:* tls@ietf.org
> *主题:* Re: [TLS] Connection ID Draft
>
>
>
>
>
>
>
> On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing  wrote:
>
> Hi Ekr,
>
>
>
> Thanks for your effort. The draft looks good. A few comments are listed
> below.
>
>
>
> 1.   Based on the draft, for either DTLS1.2 or 1.3, server can’t
> differentiate whether the packet from client is a “connection ID” packet or
> a standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also
> introduced this problem)
>
> Maybe we can add a new “ContentType” in the DTLS record format to help
> server identify the “connection ID” packet. In addition, you see the length
> of the record payload is limited by 2^14-1, this means the first two bits
> of “length” is zero. We could utilize this feature and set the first two
> bits or more bits of CID being one, e.g., ….(but the CID must be put
> between sequence number and length). When server finds  after sequence
> number, it knows this is a “connection ID” packet. However, I don’t know
> whether it is proper to use such magic number. In my view, adding new
> contenttype may be a choice.
>
>
>
> As I said to Nikos, for DTLS 1.2, you can use a specially-constructed CID
> that would not be a valid length field. This can actually just have the
> leading bit set. As we're revising the DTLS 1.3 record format, we would
> need to do something different for that.
>
>
>
> 2.For DTLS 1.2, there is no NewConnectionID and
> RequestConnectionID message. DTLS 1.2 server and client also has the
> requirement to request for a new CID, and at present, many products still
> use DTLS1.2 and I believe it will continue to be used for a long time even
> if TLS/DTLS1.3 is published. My point is that we need a corresponding
> method for updating CID for DTLS1.2 too.
>
> In general, the WG is working on TLS 1.3, not TLS 1.2, so I'm not really
> that excited about putting a lot of effort into enhancing TLS 1.2. The
> basic extension works fine for them, but if they want to change CIDs, then
> they should adopt DTLS 1.3.
>
>
>
> I don’t quite understand the following sentences
>
> “In DTLS 1.2, connection ids are exchanged at the beginning of the
>
>DTLS session only.  There is no dedicated "connection id update"
>
>message that allows new connection ids to be established mid-session,
>
>because DTLS 1.2 in general does not allow post-handshake messages
>
>that do not themselves begin other handshakes.”
>
>
>
> The only post-handshake messages allowed in DTLS 1.2 are ClientHello and
> HelloRequest.
>
>
>
> Besides, for CID in DTLS1.3, I think the corresponding responding messages
> of  NewConnectionID and RequestConnectionID are also needed to ensure that
> the peer has received CID.
>
>
>
> No, you use the ACK for these 

Re: [TLS] Connection ID Draft

[yinxinxing]

Hi Ekr,

For the post-handshake messages in the draft, I have some comments.


1.   When one peer sends NewconnectionID message to the other, it uses a 
newly defined handshake type. This new CID is attached in the payload of the 
record message. But there must be some information for the receiver to know 
which CID is going to be updated. I mean that when sending new CID through the 
NewConnectionID message, the record header should include the “old” CID, so 
that the receiver knows which one to replace.

2.   In the draft, is the new CID encrypted? I suggest that the new CID 
(for the first time sending) can be encrypted  to make sure that an attacker 
can not associate a new CID with an old CID. Let’s consider a case where an 
attacker wants to track an IOT device. If the newly generated CID is not 
encrypted when updating, the attacker can associate the new CID with the old 
one. Then, when the peer sends message with the new CID later, the attacker 
knows this packet is sent from the victim. If we encrypt the new CID when 
updating, this tracking problem can be avoided.

Another comment is about symmetrical CID.

1.   Consider a client sends a normal CID (CID length is not zero, named 
C-CID) to server, but the server doesn’t wants to use client’s CID and sends a 
CID generated by the server (named S-CID) to the client. At the same time, 
client needs to know server has ignored C-CID (which means the downlink 
application message from the server will not include C-CID), and client will 
use S-CID in its application message. Will the draft cover this scenario?

Yin Xinxing

发件人: Eric Rescorla [mailto:e...@rtfm.com]
发送时间: 2017年10月13日 21:00
收件人: yinxinxing
抄送: tls@ietf.org
主题: Re: [TLS] Connection ID Draft



On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing 
> wrote:
Hi Ekr,

Thanks for your effort. The draft looks good. A few comments are listed below.


1.   Based on the draft, for either DTLS1.2 or 1.3, server can’t 
differentiate whether the packet from client is a “connection ID” packet or a 
standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also introduced 
this problem)

Maybe we can add a new “ContentType” in the DTLS record format to help server 
identify the “connection ID” packet. In addition, you see the length of the 
record payload is limited by 2^14-1, this means the first two bits of “length” 
is zero. We could utilize this feature and set the first two bits or more bits 
of CID being one, e.g., ….(but the CID must be put between sequence number 
and length). When server finds  after sequence number, it knows this is a 
“connection ID” packet. However, I don’t know whether it is proper to use such 
magic number. In my view, adding new contenttype may be a choice.

As I said to Nikos, for DTLS 1.2, you can use a specially-constructed CID that 
would not be a valid length field. This can actually just have the leading bit 
set. As we're revising the DTLS 1.3 record format, we would need to do 
something different for that.


2.For DTLS 1.2, there is no NewConnectionID and RequestConnectionID 
message. DTLS 1.2 server and client also has the requirement to request for a 
new CID, and at present, many products still use DTLS1.2 and I believe it will 
continue to be used for a long time even if TLS/DTLS1.3 is published. My point 
is that we need a corresponding method for updating CID for DTLS1.2 too.
In general, the WG is working on TLS 1.3, not TLS 1.2, so I'm not really that 
excited about putting a lot of effort into enhancing TLS 1.2. The basic 
extension works fine for them, but if they want to change CIDs, then they 
should adopt DTLS 1.3.


I don’t quite understand the following sentences

“In DTLS 1.2, connection ids are exchanged at the beginning of the

   DTLS session only.  There is no dedicated "connection id update"

   message that allows new connection ids to be established mid-session,

   because DTLS 1.2 in general does not allow post-handshake messages

   that do not themselves begin other handshakes.”

The only post-handshake messages allowed in DTLS 1.2 are ClientHello and 
HelloRequest.


Besides, for CID in DTLS1.3, I think the corresponding responding messages of  
NewConnectionID and RequestConnectionID are also needed to ensure that the peer 
has received CID.

No, you use the ACK for these 
(https://tools.ietf.org/html/draft-ietf-tls-dtls13-01#section-7). This is one 
reason why there is not a straightforward port to DTLS 1.2 for these messages.


4.   The generation of CID should be more concrete. For example, using 
random number or a counter?
I explicitly did not want to do that, because there are a lot of valid ways to 
generate CID. This is also what we did in QUIC.

-Ekr



Regards,
Yin Xinxing

发件人: TLS [mailto:tls-boun...@ietf.org] 代表 Eric 
Rescorla
发送时间: 2017年10月13日 7:14
收件人: tls@ietf.org
主题: [TLS] Connection ID