On Wed, Oct 25, 2017 at 8:02 PM, yinxinxing wrote:
> Hi Ekr,
>
>
>
> Sorry for the delay. I don’t quite understand “The way that this
> mechanism works is that it either replaces all of them or supplements the
> set.” I see the new CID is encrypted in the post-handshake message and
> transferred
Hi Ekr,
Sorry for the delay. I don’t quite understand “The way that this mechanism
works is that it either replaces all of them or supplements the set.” I see the
new CID is encrypted in the post-handshake message and transferred to the peer.
So, the record header of this message needs to conta
➢ options (quoted below) are wrong or do not work. The objection is
that the IETF should not be publishing a RFC that documents them, is
that right?
Not at all.
But maybe I’m mistaken; do you have links to messages that said that?
The draft in the subject line is a different item al
On 25/10/17 23:58, Peter Bowen wrote:
> So, to be completely clear, no one is arguing that Nick's three
> options (quoted below) are wrong or do not work. The objection is
> that the IETF should not be publishing a RFC that documents them, is
> that right?
No, it's not that simple.
For myself,
On Wed, Oct 25, 2017 at 3:40 PM, Stephen Farrell
wrote:
>
>
> On 25/10/17 23:37, Richard Barnes wrote:
>> Sorry, what? The current draft proposes an extension, literally the
>> opposite of a standard, supported feature. It's explicitly optional.
>
> Optional is not the opposite of standard.
>
>
On 25/10/17 23:37, Richard Barnes wrote:
> Sorry, what? The current draft proposes an extension, literally the
> opposite of a standard, supported feature. It's explicitly optional.
Optional is not the opposite of standard.
See the intended status below.
> I don't really have a dog in this f
On Oct 25, 2017 22:34, "Stephen Farrell" wrote:
Replying to just a couple of bits...
On 25/10/17 15:23, David A. Cooper wrote:
> Similarly, the best that TLS can offer in terms of privacy is that the
> contents of the communication between the two endpoints is not seen by
> anyone else *unless*
On 25/10/17 17:11, Ackermann, Michael wrote:
> And if this is not a feature that everyone wants, then so be it.
> But at least it was an attempt by a small number of people to try to
> find common ground and make any form of progress.
I do not accept that there is an onus on IETF participants
Replying to just a couple of bits...
On 25/10/17 15:23, David A. Cooper wrote:
> Similarly, the best that TLS can offer in terms of privacy is that the
> contents of the communication between the two endpoints is not seen by
> anyone else *unless* at least one of the two endpoints (client or
> se
Thank you Nick.
On 25/10/17 20:34, Nick Sullivan wrote:
> On that note, so what if some browsers opt in? Servers need to also opt-in
> to setting visibility keys.
It is good to see the discussion move on from the proponents'
seeming inability to envisage that anything bad could possibly
happen h
On Oct 25, 2017, at 3:34 PM, Nick Sullivan wrote:
> Forward secrecy with respect to other keys, like the session ticket key or
> other keys that can be generated centrally, are things that need to be looked
> at more closely for TLS 1.4 (or whatever’s next).
Unless I am very much mistaken, it i
I didn't want to stick my foot in this, but here we are.
The goal for an inspection service to be able to take a recording of the
network and a key (or corpus of keys) and be able to decrypt any TLS
connection to a server within that network.
There are multiple ways of getting these keys.
1) use
On Wed, Oct 25, 2017 at 12:21 PM, Roland Zink wrote:
> It could but RFC 7469 section 2.6
> (https://tools.ietf.org/html/rfc7469#section-2.6) says:
>
> " It is acceptable to allow Pin
>Validation to be disabled for some Hosts according to local policy.
>For example, a UA may disable Pin Va
No, they would not prevent those other
mechanisms. Where is your evidence that they would?
If the "attacker" controls the software that the client is using,
then it would set up the software to not check public-key pinning
or CT, if necessary. As Richard no
It could but RFC 7469 section 2.6
(https://tools.ietf.org/html/rfc7469#section-2.6) says:
" It is acceptable to allow Pin
Validation to be disabled for some Hosts according to local policy.
For example, a UA may disable Pin Validation for Pinned Hosts whose
validated certificate chain
On Wed, Oct 25, 2017 at 12:06 PM, Salz, Rich wrote:
> > since those other means would be easier and more effective. You
> have done nothing to suggest otherwise.
>
> Public-key pinning and CT seem like they would prevent those other
> mechanisms. No?
>
Remember that non-default, user-instal
" idea of a client extension was added based on feedback at the Prague meeting
in order to help prevent the protocol from being used over the public Internet,
by preventing the protocol from being used without the client's knowledge."
Responding ONLY to the above sentence, as I agree with Step
> since those other means would be easier and more effective. You
have done nothing to suggest otherwise.
Public-key pinning and CT seem like they would prevent those other mechanisms.
No?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/
I've already responded to this! Why are you wasting everyone's time by
asking the same questions over and over, even though I've already
clearly answered them?
An airplane/wifi provider might say "download our free browser," but it
won't rely on draft-rhrd-tls-tls13-visibility to snoop on its
>This question is based on your that belief that this protocol will
> "escape" onto the public Internet
Yes. Are you saying that you don’t believe that the enterprise visibility will
stop at their firewall? That they will allow ‘stock’ TLS 1.3 to work
connecting to their sites? That the
This question is based on your that belief that this protocol will
"escape" onto the public Internet, that browsers and other clients used
by individuals will feel forced to implement it, and that clients will
then be forced to enable the extension in order to get through
middleboxes that would
➢ Similarly, the best that TLS can offer in terms of privacy is that the
contents of the communication between the two endpoints is not seen by
anyone else *unless* at least one of the two endpoints (client or
server) chooses to provide the contents of the communication to some
Everything I have stated is my personal opinion.
Note that I never suggested that I like or am espousing a certain
approach, I was simply stating a fact. In many cases today, a TLS
connect that appears to a client to be terminating a one place (Company
X) is actually terminating somewhere else
Before you leave, there are a number of questions still unanswered.
1 Can this draft enable an active attacker to modify traffic? If not, then
then how is that prevented?
2 Can this draft be used to segregate traffic so that only those willing to be
intercepted can be handled separately from t
On Wed, Oct 25, 2017 at 08:48:56AM +0200, Nikos Mavrogiannopoulos wrote:
> On Mon, 2017-10-23 at 18:14 -0700, Eric Rescorla wrote:
> > 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'
25 matches
Mail list logo
