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

[Stephen Farrell]

On 21/08/18 17:15, Ted Lemon wrote:
> I asked you if you have any specific devices for which this is an issue.
>  Do you?   How did you determine that it was an issue?   Do you have A/B
> testing results on power consumption and/or performance of a null cipher
> suite versus encryption?

If doing such comparisons, then it's very well worth noting the
significant differences between e.g. h/w accelerated AES, vs s/w
AES vs chacha. It'd be hard to evaluate claims about difficulty
of implementation/deployment without that.

S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] integrity only ciphersuites

[Stephen Farrell]

On 21/08/18 14:36, Andreas Walz wrote:
> 
> I strongly believe it is *not* a good idea to hold back all the valuable
> experience condensed in TLS and entail the design of customized security
> protocols for such systems. TLS is state-of-the-art and its benefits
> should be accessible to as many systems as possible. 

I agree. Quoting the meat of the abstract of RFC8446:

   TLS allows client/server applications to communicate
   over the Internet in a way that is designed to prevent eavesdropping,
   tampering, and message forgery.

Using TLS in non-Internet contexts is just fine. Possibly
weakening the "prevent eavesdropping" part is the issue here.
Confidentiality is required for lots of reasons, e.g. bearer
token security, or maybe even firmware updates, as pointed
out earlier in this thread.

Cheers,
S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] integrity only ciphersuites

[Stephen Farrell]

Hiya,

On 21/08/18 13:10, Blumenthal, Uri - 0553 - MITLL wrote:
> "Vulnerable-by-design ciphersuites"? Vulnerable to what?

Accidental use, at least. If libraries implemented this
it could create a need for "!NULL" additions to random
configurations for example.

(I do accept that vulnerable-by-design might be considered
overstated, but I'm looking at his from a "part of TLS" POV
and not just at the lower level cryptographic mechanism.)

> Suck sites are designed to provide end-point authentication and
> traffic integrity. Care to explain/show how these properties would
> not hold?
>
> Besides, it's been explained several times that some use cases do not
> require confidentiality, and in some use cases confidentiality is
> forbidden.

I think I and others addressed those issues. Or tried to,
anyway;-) Assuming the only "forbidden" case means ham
radio. And it's I think fair to say that a number of times
when people have started out thinking they don't need
confidentiality, it turned out later that they did.

Cheers,
S.

> 
> Regards, Uri
> 
> Sent from my iPhone
> 
>> On Aug 21, 2018, at 07:42, Stephen Farrell
>>  wrote:
>> 
>> 
>> 
>>> On 20/08/18 21:48, Nancy Cam-Winget (ncamwing) wrote: All, A
>>> couple IoT consortiums are trying to embrace the improvements 
>>> made to TLS 1.3 and as they define their new security constructs 
>>> would like to adopt the latest protocols, in this case TLS 1.3.
>>> To that extent, they have a strong need for mutual
>>> authentication, but integrity only (no confidentiality)
>>> requirements.
>>> 
>>> In following the new IANA rules, we have posted the draft 
>>> https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-00
>>>
>>> 
to document request for registrations of HMAC based cipher selections
>>> with TLS 1.3…..and are soliciting feedback from the WG on the
>>> draft and its path forward.
>> 
>> As ekr pointed out, with the new registration rules, there's
>> nothing to stop someone defining any old set of crypto stuff and
>> getting non-recommended codepoints.
>> 
>> That said, I don't consider that defining such vulnerable-by-design
>> ciphersuites is a good plan.
>> 
>> - It imposes costs on the non-niche users of TLS - once these
>> things are defined then developers and those who deploy/configure
>> applications using TLS need to check that they're not using these
>> undesirable ciphersuites, so costs are being displaced from niche
>> uses to the vast majority of implementations and deployments,
>> which seems to me to be a bad idea. And we know that people will
>> sometimes get those checks wrong leading to unexpected transmission
>> of plaintext over the Internet.
>> 
>> - Similarly, just defining such ciphersuites seems likely to lead
>> to less well tested and infrequently used code paths, which is
>> undesirable. (Assuming someone pays some developer to add these to
>> some library, which generally does seem to happen.)
>> 
>> - RFC7525 [1] is clear on this topic (after debate in the UTA WG) -
>> "Implementations MUST NOT negotiate the cipher suites with NULL
>> encryption" and I see nothing new to convince me that that ought
>> change for TLS1.3.
>> 
>> - Code footprint arguments aren't that convincing to me - to get
>> interop for the few devices where AES being present or absent could
>> make a real difference, you'd need an awful lot more profiling of
>> TLS or DTLS. I don't see evidence of that so the interop/footprint
>> arguments seem pretty weak. I'd also bet that any useful "tiny 
>> footprint" profile of that kind would end up targeting loads of
>> use-cases where confidentiality is absolutely required.
>> 
>> - (In addition to the good points made by Geoffrey Keating [2])
>> cleartext payloads would also assist in device fingerprinting,
>> making it easier to exploit vulnerabilities at scale.
>> 
>> - IIUC there is also a desire to encrypt firmware updates so that
>> patches can be distributed more quickly than attackers can
>> reverse-engineer attacks. [4] I'm not entirely sure if that's
>> really likely to happen, but if it were, then devices would need to
>> be able to use recommended ciphersuites in any case.
>> 
>> - TLS/AX.25 doesn't seem that good a plan in any case - according
>> to [3], which seems reasonable to me, using clear-signed GPG is
>> quicker and better meets the oddball regulations. Attempting to
>> deal with those regulations by weakening TLS seems like a very bad

Re: [TLS] integrity only ciphersuites

[Stephen Farrell]

On 20/08/18 21:48, Nancy Cam-Winget (ncamwing) wrote:
> All, A couple IoT consortiums are trying to embrace the improvements
> made to TLS 1.3 and as they define their new security constructs
> would like to adopt the latest protocols, in this case TLS 1.3.   To
> that extent, they have a strong need for mutual authentication, but
> integrity only (no confidentiality) requirements.
> 
> In following the new IANA rules, we have posted the draft
> https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-00
> to document request for registrations of HMAC based cipher selections
> with TLS 1.3…..and are soliciting feedback from the WG on the draft
> and its path forward.

As ekr pointed out, with the new registration rules,
there's nothing to stop someone defining any old set
of crypto stuff and getting non-recommended codepoints.

That said, I don't consider that defining such
vulnerable-by-design ciphersuites is a good plan.

- It imposes costs on the non-niche users of TLS - once
these things are defined then developers and those who
deploy/configure applications using TLS need to check
that they're not using these undesirable ciphersuites,
so costs are being displaced from niche uses to the
vast majority of implementations and deployments, which
seems to me to be a bad idea. And we know that people
will sometimes get those checks wrong leading to unexpected
transmission of plaintext over the Internet.

- Similarly, just defining such ciphersuites seems likely
to lead to less well tested and infrequently used code
paths, which is undesirable. (Assuming someone pays some
developer to add these to some library, which generally
does seem to happen.)

- RFC7525 [1] is clear on this topic (after debate in the
UTA WG) - "Implementations MUST NOT negotiate the cipher
suites with NULL encryption" and I see nothing new to
convince me that that ought change for TLS1.3.

- Code footprint arguments aren't that convincing to
me - to get interop for the few devices where AES being
present or absent could make a real difference, you'd
need an awful lot more profiling of TLS or DTLS. I don't
see evidence of that so the interop/footprint arguments
seem pretty weak. I'd also bet that any useful "tiny
footprint" profile of that kind would end up targeting
loads of use-cases where confidentiality is absolutely
required.

- (In addition to the good points made by Geoffrey
Keating [2]) cleartext payloads would also assist in
device fingerprinting, making it easier to exploit
vulnerabilities at scale.

- IIUC there is also a desire to encrypt firmware
updates so that patches can be distributed more quickly
than attackers can reverse-engineer attacks. [4] I'm
not entirely sure if that's really likely to happen,
but if it were, then devices would need to be able to
use recommended ciphersuites in any case.

- TLS/AX.25 doesn't seem that good a plan in any
case - according to [3], which seems reasonable to
me, using clear-signed GPG is quicker and better
meets the oddball regulations. Attempting to deal
with those regulations by weakening TLS seems like
a very bad plan, as you'd fail in any case to achieve
interop with normal TLS applications like the web.
(And the advertising is as illegal as the crypto
apparently, though I do like that aspect:-)

- WRT unix sockets, I'm not clear that there's a
sufficiently important performance improvement in
real deployments to justify introducing weakened
ciphersuites - presumably mail servers are going to
use standard TLS libraries that (I hope!) won't be
offering NULL encryption, so I'd be surprised if
the right engineering decision was to prioritise
CPU to that extent, given the risks associated with
having weak ciphersuites present in widely used
implementations. IOW, it seems more sensible to me
for mail servers to just stick to using RECOMMENDED
ciphersuites. And given that you could use SASL
with Postfix/LMTP [5] I'm not sure why you'd want
a weirdo-version of TLS1.3 anyway but maybe there's
some reason I don't get.

- I think this WG has had to spend wy too much
time dealing with the "inspection of data" debate in
various forms, but we did get an answer (no consensus)
in the end for that. Niche use cases seem extremely
unlikely to me to justify revisiting that painful
topic.

So all in all, I just don't see a need for these
weak-by-design ciphersuites to even be defined. I'd
encourage folks who think they're needed to instead
think about how using RECOMMENDED ciphersuites might
make their implementations more widely applicable and
safer. Seems like a much more productive approach to
me anyway.

Regards,
S.

[1] https://tools.ietf.org/html/rfc7525
[2] https://mailarchive.ietf.org/arch/msg/tls/uI8xVgp7gTuJgwUyY-UgZfmUkRo
[3] https://tools.ietf.org/html/draft-ietf-suit-architecture-01#section-3.3
[4] https://www.tapr.org/pdf/DCC2010-AX.25-AuthenticationEffects-KE5LKY.pdf
[5] http://www.postfix.org/SASL_README.html#client_sasl




0x5AB2FAF17B172BEA.asc
Description: 

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Stephen Farrell]

Hiya,

Thanks for reading the draft!

On 19/08/18 00:45, Artyom Gavrichenkov wrote:
> On Mon, Jul 9, 2018 at 7:42 PM Kathleen Moriarty
>  wrote:
>> Stephen and I posted the draft below to see if the TLS working group
>> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
>> been a recent drop off in usage for web applications due to the PCI
>> Council recommendation to move off TLSv1.0, with a recommendation to
>> go to TLSv1.2 by June 30th.
> 
> Err, sorry, but – to make it one hundred per cent correct – it seems
> like PCI SSC has just deprecated TLS v1.0 _only_.
> 
> "Migrating from SSL and Early TLS", version 1.1:
> "The best response is to disable SSL entirely and migrate to a more
> modern encryption protocol, which at the time of publication is a
> minimum of TLS v1.1"
> https://www.pcisecuritystandards.org/documents/Migrating-from-SSL-Early-TLS-Info-Supp-v1_1.pdf
> 
> draft-moriarty-diediedie also mentions PCI SSC requirements. Do I get
> anything wrong here?

Well, two comments:

1. The bit you quote above is incomplete, the full paragraph says
"The best response is to disable SSL entirely and migrate to a more
modern encryption protocol, which at the time of publication is a
minimum of TLS v1.1, although entities are strongly encouraged to
consider TLS v1.2.  Note that not all implementations of TLS v1.1
are considered secure – refer to NIST SP 800-52 rev 1 for guidance
on secure TLS configurations." So there's already a strong hint
in PCI-land to GOTO TLSv1.2+.

2. Use of TLSv1.1 seems to be almost non-existent. See the figures
in the -01 draft for some detail, (and more data is always welcome).
It seems like there's more already-deprecated SSL than there is
TLSv1.1 which I think means that this is really a non-issue.

I guess there could be a formal but theoretical problem resulting
from this, but OTOH, if (or when) the IETF finished an RFC based
on this draft deprecating these legacy versions then PCI folks can
catch up, and without that affecting pretty much anyone, so I'd say,
in this case, it's likely ok to just ignore this slight discrepancy.
But if you've some text change to suggest that'd handle it better,
that'd be great to see.

Cheers,
S.


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


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] WG adoption call: draft-rescorla-tls-esni

[Stephen Farrell]

Yeah, adopt it. I'll review.

S

On 25/07/18 03:16, Joseph Salowey wrote:
> The sense of the TLS@IETF102 room was the the WG should adopt
> https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item.
> But, we need to confirm this on list.  If you would like for this draft to
> become a WG document and you are willing to review it as it moves through
> the process, then please let the list know by 2359UTC 20180807.  If you are
> opposed to this being a WG document, please say so (and say why).
> 
> Note that the draft has been marked as a "Candidate for WG Adoption” in the
> datatracker.
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Stephen Farrell]

Hiya,

On 13/07/18 13:24, nalini elkins wrote:
> Stephen,
> 
> Sorry for the late reply.   I was travelling to Montreal from India and
> was jet lagged.

No problem. And that'll be me tomorrow:-)

I generally agree with Ekr's mail just now but a little bit
more below...

> 
>>
>>> I am thinking the following:
>>>
>>> Location: U.S. / Canada (possibly U.K.)
>>>
>>> -  3 banks (hopefully from the top 5)
>>> -  3 large insurance companies  (includes back end processing)
>>> -  3 U.S. federal government agencies
>>> -  3 companies in the Wall Street / Stock brokerage sector (includes back
>>> end processing)
>>> -  3 large credit card / processors (ex. Visa, Discover, MasterCard,
> etc.)
>>> -  3 in the retail sector (Home Depot, Target, Lowes, et al)
> 
>> Those are pretty small numbers unless they're interacting with
>> a lot of TLS services. It'd be hard to know if they'd be
>> representative of something or not if they're anonymised in the
>> results.
> 
> I would expect that these people would have quite a few applications
> using TLS.   Telnet, FTP, MQSeries, SMTP, and many written by the
> organization itself.
> 
> What numbers do you feel WOULD be representative?

Well, for externally visible services, that information is
public already and visible via e.g. censys.io and similar
so you could just omit those from any numbers you report I
guess.

I've not thought so much about things that are only visible
internally, though I did (have a student:-) do some scanning
of our university n/w early this year, but I've yet to look
at that data so a) I still need to verify it, and b) I'm not
sure how I'd report on it in detail. That said, what he
reported for port 443, was ~800 regularly seen servers in
the bits of n/w he scanned with:

 SSLv3 (18%),
 TLSv1.0 (35%),
 TLSv1.1 (0%),
 TLSv1.2 (45%),
 TLSv1.3 (0%)

Which is a tad sad;-( I think many of the SSLv3 and TLSv1.0
servers were on things like printers, conferencing boxes,
access points and servers that are have basically been left
running when nobody cares for 'em any more. But that's the
bit I'd like to go re-check before standing over those
numbers. And I'd also like to know more about how those
change over time too, and look at other ports and not just
443. (Doing that is somewhere down towards the end of my
to-do list but maybe I'll set another student on it later
in the year.)

If you could quote figures (and rate of change) like those
for identified networks that'd I think be useful. If you
anonymise and/or aggregate then it's a bit harder to know
how to interpret the data. (E.g. the fact we're a university
likely means we've more forgotten web servers I guess;-).
And if they're guesses and not measurements, or if it's not
clear what was measured, then it's really not so useful.

I guess the thing to keep in mind is that it's better if
the findings can be replicated or otherwise validated. (If
it helps, my student's scanning code is at [1] but I reckon
there's a good bit of work to be done to make that usable
for anyone else.)

>> I'd encourage you to try get people to be open about
>> things here - there's no particular shame in having 10% TLSv1.0
>> sessions after all:-)
> 
> It isn't a question of shame but it is just a bit too much information
> to provide a potential adversary.  That is, to say that Stock Exchange XYZ
> has n% of TLS1.0 clients provides a potential attacker too much
> information.  

Not sure I agree there tbh. If they're externally visible
services, then it's public already. If they're not, and the
attacker is inside the n/w, then the bad actor can find it
out then. But I do understand organisations being shy about
such things.

Cheers,
S.

[1] https://github.com/mikeyPower/final-year-project

> As I say, most organizations that I know are trying very hard
> to migrate from older versions.  It is not as simple as it might seem.
> 
> If the organizations need to be identified by name, then I think this will
> be a show stopper for any kind of data that I might be able to provide.
> Having said that, I completely understand (and share) your distrust of
> anonymous data.   I am at a loss as to how to proceed.
> 
> I am open to any constructive suggestions.
> 
> Thanks,
> Nalini
> 
> 
> On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell 
> wrote:
> 
>>
>> Hiya,
>>
>> On 11/07/18 06:45, nalini elkins wrote:
>>>  Stephen,
>>>
>>>> I'd love to add more detail like that and/or more sections for other
>>> protocols if folks have data to offer with references.
>>>
>>> I believe that I can reach out to various people I know.   Please comment
>>> if my methodology is acceptable and if you think this

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Stephen Farrell]

Hiya,

On 11/07/18 06:45, nalini elkins wrote:
>  Stephen,
> 
>> I'd love to add more detail like that and/or more sections for other
> protocols if folks have data to offer with references.
> 
> I believe that I can reach out to various people I know.   Please comment
> if my methodology is acceptable and if you think this will be helpful.

It's not whether the methodology is acceptable to me or not
but whether or not the references to the numbers are credible
for readers:-)

A few comment below,

> 
> I am thinking the following:
> 
> Location: U.S. / Canada (possibly U.K.)
> 
> -  3 banks (hopefully from the top 5)
> -  3 large insurance companies  (includes back end processing)
> -  3 U.S. federal government agencies
> -  3 companies in the Wall Street / Stock brokerage sector (includes back
> end processing)
> -  3 large credit card / processors (ex. Visa, Discover, MasterCard, etc.)
> -  3 in the retail sector (Home Depot, Target, Lowes, et al)

Those are pretty small numbers unless they're interacting with
a lot of TLS services. It'd be hard to know if they'd be
representative of something or not if they're anonymised in the
results. I'd encourage you to try get people to be open about
things here - there's no particular shame in having 10% TLSv1.0
sessions after all:-)

> 
> Note: I put in "back end processing" because these are the folks that most
> often have many connections to other business partners and so in some ways
> have the most complex systems to deal with.
> 
> Note #2:  This is aspirational!  I hope I can get all these people to
> cooperate.  I will try at least to get some in each category.
> 
> 
> I will ask them the following questions:
> 
> 1.  How many applications do you have?  (This may end up being only the
> mission critical ones as otherwise it may be too hard to obtain.)

I'm not sure that's so interesting for this question. And I'm not
sure that different people would count things as applications in
the same way.

> 2.   How many are using TLS and how many are still plain text?  (We will
> disregard SSH and other such variants.)

Again, that's not so interesting here.

> 3.   What percent of clients are using a pre-TLS1.2 version?  (This will be
> an estimation.
I don't see why this needs to be estimated, this is kinda the key
measurement needed and easy to measure. There should be no need for
anyone to stick their thumb in the air for this:-)

It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and
TLSv1.3) and to say for how many TLS sessions or hosts/IPs the
figures apply.

And of course providing as much context as possible so that it's
possible to understand the numbers and whether or not the numbers
from different sources are based on the same or different kinds of
measurement.

> 
> 4.   Do you have an active project to migrate off of older versions of TLS?

Sure.

> 
> 5.   What do you estimate your percent of clients using pre-TLS1.2 versions
> to be next year?

I don't see how this'd be so useful. Aaking about the historic and
current rates of change of use of the various protocol versions would
be good though if people have that, but they may not.

S.

> 
> 
> Please let me know if this will be of use & if you have suggestions for
> improvement.
> 
> Thanks,
> Nalini
> 
> 
> 
> 
> On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell 
> wrote:
> 
>>
>> Hi Nalini,
>>
>> On 10/07/18 04:50, nalini elkins wrote:
>>> It would be nice to see some of this reflected in the draft rather than
>>> only statistics on browsers.   The real usage of these protocols is far
>>> more complex.
>>
>> I didn't have time before the I-D cutoff but have since
>> added a section on mail to the repo pre-01 version. (See
>> [1] section 3.2.) I'd love to add more detail like that
>> and/or more sections for other protocols if folks have
>> data to offer with references.
>>
>> Consistent with other folks' numbers sent to the list
>> yesterday, (though based on a much smaller sat of data I
>> guess;-) my data shows 10.6% use of TLSv1.0 when talking
>> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K
>> IP addresses that listen on port 25 (mail servers).
>>
>> What I don't currently have is a rate of change for that
>> figure. I think that rate of change is the important number
>> for figuring out what to do in the next while. E.g. The
>> WG might conclude that if the percentage of TLSv1.0 is
>> moving down nicely, we should be a bit patient. If it's
>> not moving at all, we can probably move now or in 5 years
>> without that being different. If we're not sure, then get
>> more data...
>>
>> Cheers,
>> S.
>>
>> [1]
>> https://github.com/sftcd/tls-oldversions-diediedie/blob/mast
>> er/draft-moriarty-tls-oldversions-diediedie.txt
>>
> 
> 
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Stephen Farrell]

Hiya,

On 10/07/18 19:04, Viktor Dukhovni wrote:
> On Tue, Jul 10, 2018 at 09:21:04AM +0100, Stephen Farrell wrote:
> 
>> I didn't have time before the I-D cutoff but have since
>> added a section on mail to the repo pre-01 version. (See
>> [1] section 3.2.) I'd love to add more detail like that
>> and/or more sections for other protocols if folks have
>> data to offer with references.
> 
> The numbers for MX hosts with working DANE TLSA records are:
> 
> 4337  TLS 1.2
>   63  TLS 1.0
>5  TLS 1.1

Thanks. I'll try add text on the above and other usable
numbers sent to the list to the repo version before we shoot
out a -01.

> These are early adopters of enhanced SMTP security, so one would
> expect to find modern software and an emphasis on security, and
> yet, for >1% of the MX hosts, their SMTP server libraries fail to
> negotiate TLS 1.2.  Presumably, the broader MTA population has a
> higher incidence of TLS 1.0-only servers.

Fair point.

Cheers,
S.


> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Stephen Farrell]

Hi Nalini,

On 10/07/18 04:50, nalini elkins wrote:
> It would be nice to see some of this reflected in the draft rather than
> only statistics on browsers.   The real usage of these protocols is far
> more complex.

I didn't have time before the I-D cutoff but have since
added a section on mail to the repo pre-01 version. (See
[1] section 3.2.) I'd love to add more detail like that
and/or more sections for other protocols if folks have
data to offer with references.

Consistent with other folks' numbers sent to the list
yesterday, (though based on a much smaller sat of data I
guess;-) my data shows 10.6% use of TLSv1.0 when talking
SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K
IP addresses that listen on port 25 (mail servers).

What I don't currently have is a rate of change for that
figure. I think that rate of change is the important number
for figuring out what to do in the next while. E.g. The
WG might conclude that if the percentage of TLSv1.0 is
moving down nicely, we should be a bit patient. If it's
not moving at all, we can probably move now or in 5 years
without that being different. If we're not sure, then get
more data...

Cheers,
S.

[1]
https://github.com/sftcd/tls-oldversions-diediedie/blob/master/draft-moriarty-tls-oldversions-diediedie.txt


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] DNS-based Encrypted SNI

[Stephen Farrell]

Hiya,

Just on this bit...

On 04/07/18 18:20, Eric Rescorla wrote:
> The structure started a bit simpler and got new features to
> deal with new issues. Specifically:
> 
> - The checksum is intended to deal with corruption

I'm not sure I see why that's needed, but I believe you if
you say it might help with some home routers. (Though I'd
also be interested in information/citation about the
details of the problems seen there.)

> - The keys and cipher suites seem kind of mandatory

Yep. OTOH, given we need to support >1 value for the RR, if
mostly people just need one key+CS per-RR, it may be possible
to use multiple RRs to provide additional keys/CSes. (If most
uses would have a variable number of keys/CSes then I agree
the current structure is better.)

> - The padded length is needed to tell the client how much to
>   pad. Though I guess we could always pad to 260. If you don't
>   pad at all, it doesn't work.

Sure.

> - I think it's clear what not_before and not_after are for. If you have
>   more concrete feedback about better ways to do that, we'd welcome
>   this.

With not_before/not_after (and the TTL) there'll need to be some
consideration of the various overlaps, which has been a source of
bugs and ops screw-ups in other scenarios. I also don't like the
forced expiry of not_after - people will just put in 2038 all over,
or risk weird breakage. (X.509's mandatory notAfter was IMO an
error for most uses of X.509 - an error inherited from the X.500
DAP user authentication use-case that initially motivated X.509.)

I wonder would an incrementing counter (like SOA serial) maybe be
easier where the client just uses the highest value? (There was
some discussion on related topics during the work on MTA-STS, but
I forget the details, might be worth checking with the folks
involved.)

> - Extensions is just there because we're trying to be safe.

Sure, but I hope we consider dropping 'em if there's no need.
New RRTYPEs could always be used for extensions (if new RRTYPEs
are cheap, that is:-)

> 
> FWIW, this actually is pretty friendly because we b64-encode
> (thus making the internal structure opaque to DNS). Removing
> things won't make it much smaller because a big chunk of
> the data is in the keys. For instance, in my implementation,
> the object is 70 bytes long and 34 bytes of that is key (X25519)
> and 8 bytes is cipher suite (each of these has 2 bytes of length).

That's good. But I was more thinking about how friendly this
would be for the DNS admin folks. One thing I like about TLSA
and CAA is that (for my use-cases:-) I can just cut'n'paste
the values into zone files and they'll be good until a CA root
key or name changes, which is pretty rare and would be widely
advertised ahead of time.

With RRSIGs and similar, I can also easily inspect values by
just looking at zonefiles and/or using dig, which is helpful
for me at least. But I don't have to deal with large zones so
that kind of inspection may not be of much use to larger
operators. So, I'd defer to real DNS server folks on whether
or not being able to directly view the internals of ESNIKeys
encoding makes any difference.

All that said, I did just suggest adding in the dummy sni
value:-) So I mostly think if this goes ahead (as I hope it
does), we spend a bit of time considering the above issues
before we're done.

Cheers,
S.



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] DNS-based Encrypted SNI

[Stephen Farrell]

Hiya,

On 03/07/18 00:39, Eric Rescorla wrote:
> Hi folks,
> 
> I just submitted:
> 
>   https://tools.ietf.org/html/draft-rescorla-tls-esni-00

Thanks for writing that up. I think it's an interesting
addition to the set of potential solutions.

> 
> This draft describes a DNS-based approach to doing encrypted SNI.
> 
> Previously, we had thought this wouldn't work because only sites that
> were particularly vulnerable would do it, and so the use of ESNI marks
> you out. The idea behind this draft is that there are a lot of sites
> which are hosted by -- and whose DNS is run by -- a large provider,
> and that provider can shift many if not all of its sites to ESNI at
> once, thus removing the "standing out" issue and making a DNS-based
> approach practical.

I'm not sure I fully understand how this approach would fit
with others, nor to what extent it depends on the DNS and
CDN providers co-operating, but it definitely seems worth
exploring.

> 
> I am working on an implementation for NSS/Firefox and I know some
> others are working on their own implementations, so hopefully we can
> do some interop in Montreal.
> 
> This is at a pretty early stage, so comments, questions, defect
> reports welcome.

Quick comments after flicking through the draft:

- I'm not that fussed myself as to whether this uses a TXT
or new RRTYPE. But if the latter would work, it seems better.

- I didn't quite get what "all the domains" in 3.2 means. I
guess if a client uses non-encrypted sni for one of those,
it should still work, but I'm not clear if supporting esni
for any domain means that the provider has to decrypt esni
and then deal with successful decrypted sni values as if
the client had sent sni in clear. A concern is requiring
"all the domains" might make it hard to roll this out.

- I guess some form(s) of key rollover will be needed, ut
I'm not sure that not_before/not_after is the best way to
do that.

- The ESNIKeys structure generally seems a bit complicated,
it might be better to aim for simplifying that and maybe
making it more "zonefile friendly" (whether in a TXT RR
or not).

- It might be interesting to think about how this'd work
for e.g. the IETF web site (where ietf.org is hosted
locally but www.ietf.org is not), and for STARTTLS and
MX RRs. That's probably ok, but I've not gotten it
straight in my little head yet:-)

- Would it make sense to include the innocuous dummy sni
in the published RR, so that all clients use the same
one and stand out that bit less?

- 7.1 probably needs more work - I'm not sure that it's
that ok to use this with cleartext DNS. ISTM that DOH/DPRIVE,
or a client application that knows the ESNIKeys, are most
likely needed, but there's probably also some work to do
to analyse the recursive to authoritative interactions to
get the ESNIKeys even with DPRIVE.

Lastly, the topic of whether or not to try address this
problem is something that the WG has debated quite a bit,
and IIRC the consensus after that debate was to do work
on this (hence Christian's draft).

So I don't see any need to debate whether or not to work on
this is needed, and trying to re-open such a debate seems
somewhat disruptive to me. It is entirely reasonable to
consider what, if anything, widespread use of esni or other
approaches might break though. But going back to all this
"privacy at any cost" and "we're the enterprises" hyperbole
is not at all helpful IMO, so I hope we don't have to suffer
more rounds of that. But maybe that's inevitable with every
iteration of attempts to improve privacy sadly;-(

Cheers,
S.


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


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

Russ,

On 15/03/18 17:29, Russ Housley wrote:
>>> Nalini, why don't you (the consortium) define the standard,
>>> then?
> 
>> Indeed, if a “TLS13-visibility” standard has to be defined, it
>> would make sense for the consortium (rather than the TLS WG) to
>> define it.
> 
> In fact, my mistake that was caught by Martin is exactly the reason
> that we want the experts in the TLS WG to review the document.

Two things:-

1. I disagree with your assertion. Broad review to improve
security is well worthwhile and is a reason to bring work
to the IETF. Figuring out the how to controversially yet
diligently make TLS (or any IETF protocol) *weaker* is not
part of our process, and would IMO be extremely long-term
damaging to the argument that IETF security review is a
benefit of work being done via the IETF's processes.

2. Having had that fairly fundamental error pointed out,
and given the serious amount of analysis done for TLS1.3,
and *not done* for this MitM enabler, (e.g. the >1 snooper
issue has some showstoppers IMO no matter how any MitM
capability proposal tries to tackle or avoid it) - would you
not now agree that your draft is far too far from baked to
be worth the WG's f2f time in London, even if the WG had
consensus to consider the topic, which I think we've all
acknowledged is not the case? (*)

Thanks,
S.

(*) I considered not making this point - it could suit my
arguments better if the WG have a sequence of drafts like
this and draft-green to dismiss I guess but in fairness
and just in case you're now happy to withdraw your request
for a slot, I figured it worth asking, as I continue to
think that the way this topic is being mishandled is a bad
plan for all concerned.

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


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

On 14/03/18 23:16, Stephen Farrell wrote:
> Of course some people who are used to MitMing connections will
> have problems and will have to change.

I got an offlist message correcting me about the above.

I do agree that it's odd to describe post-facto decryption
of a TLS session that used RSA key transport (via a copy of
the RSA private key) as a MitM. (The off list message didn't
say "odd" - it said "wrong":-)

It'd have been better if I'd said that all these approaches
*enable* MitM rather than *are* MitMing - even if the holder
of the copy of the RSA private key might never actually mount
an MitM, they always do have the capability to MitM whenever
they choose to do that. The same is true of Russ and Ralph's
draft as well, though of course the on-path nature of that
proposal makes an actual MitM attack more likely I'd guess,
given it requires both the cryptographic and the topological
capability to MitM whereas RSA based schemes only have to
provide the cryptographic capability.

So I accept the correction, it's a fair cop.

That said, I find using the term MitM as a shorthand for all
of the above to be wy more accurate than abusing the word
"visibility" to describe standardising a MitM capability.

S.


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

On 15/03/18 00:05, nalini elkins wrote:
> There is no question of a smokey back room.

I'm sorry to disagree so bluntly, but while I was an
AD some of the people involved here requested that I
meet them in private to discuss this topic before it
had been raised on the list, and without telling me
ahead of time who, from what "enterprises," would be
in the room looking for what. As an AD I was always
happy to meet folks and have quiet discussions about
how to engage with the IETF or explore some detail of
how to get something done, I definitely did draw a
line well before private meetings aiming to overthrow
established WG consensus.

While that all might be put down to a tactical error
in which advice to follow with whom when initially
engaging with the IETF, from my POV it was the epitome
of a request for a smokey-back room discussion.

So yes, I do find that there are questions here about
smokey back rooms indeed.

S.


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

On 14/03/18 23:32, nalini elkins wrote:
> But, it is a very difficult issue.   If I can use a different analogy, if
> the City of Monterey built a new sewer system and told me that to connect
> to it, I had to build a new house, I would scream!

Analogies cannot be used to draw conclusions, merely to illustrate.
That analogy doesn't help illustrate anything for me fwiw.

> TLS is used in many, many places.  The Internet is critical to the
> businesses of the world. 

Yes. Both fine reasons to not mess about with, weaken or
try break the TLS protocol.

BTW - while you and others may constantly over-claim and
say your consortium represents "enterprises," I assume you
do not claim to represent all "business." ;-)

>  You can't just say use something other than
> TLS.   

Yes. I can. Kerberos and IPsec are used within many enterprise
networks. TLS is not the only tool in the toolbox.

If your consortium want a multi-party security protocol that
does not affect other folks' security as you seem to claim,
then that is the obvious route to explore. And that protocol
needs to be non-interoperable with TLS (maybe even non-confusable
in some stronger sense) IMO in order to avoid the risks that
breaking TLS would result in us all taking.

> Or don't use the Internet.  It's not so easy.

I never said that. Why invent something like that?

> I wish we could actually talk to each other quietly and reasonably.  This
> is a very, very difficult problem.

I am just fine with talking openly on the mailing list, as
per IETF processes. I see no benefit in smokey back room
discussions here at all, and only downsides to such.

S.




0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

On 14/03/18 23:00, nalini elkins wrote:
> The simple explanation is that people think they will have serious
> issues with TLS1.3 and actually, TLS1.2 when it is DH only.

Of course some people who are used to MitMing connections will
have problems and will have to change.

But that does not mean that their problems ought to be solved
by any change to TLS.

IMO the costs to the broader Internet of breaking TLS like that
are far too high to optimse for these folks. It's understandable
that they'd prefer otherwise.

People with such problems should IMO look elsewhere for
solutions and not be fixated on breaking TLS.

Lastly, bear in mind that even if the people with whom you
are dealing have the best intentions, there really are people
who are paid large amounts of money to weaken Internet security
(see [1] for scant detail of just one country's efforts in
that regard) and that we have IETF consensus to oppose such
efforts, as far as it's in the IETF's remit to do so.

So it doesn't really help the discussion to claim that
such-and-such a (set of person(s) is/are good actors - we do
assume that, but also that there are others who would like
the same changes to happen who do not share the IETF's goals
of making Internet security better as far as we can.

S.

[1] https://en.wikipedia.org/wiki/Bullrun_(decryption_program)


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

[Stephen Farrell]

Hi Rich (and Tony Rutkowski == hot_middlebox I assume?)

On 14/03/18 22:17, Salz, Rich wrote:
>   *   The requirements for visibility exist in an array of regulated 
> environments worldwide.  It is one of the presentation areas in the Hot 
> Middlebox Workshop.  
> http://www.etsi.org/etsi-security-week-2018/middlebox-security?tab=1
> 
> Do you know if they require packet traces to be decoded, or if one of the 
> nodes can just log the traffic?  Do they require this to be true for traffic 
> over the public Internet or just within an enterprise?
> 
> 

I see no content at that URL. This seems to be another case of
claiming regulations exist but yet again being unable to point
to any such regulation that others can read. (And yes, we did
this before for PCI-DSS so let's not repeat that if there's no
new information offered.)

S.

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


0x7B172BEA.asc
Description: application/pgp-keys


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

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

[Stephen Farrell]

Russ,

On 14/03/18 03:03, Russ Housley wrote:
> Stephen:
> 
>>> I do not know if the TLS WG will want to adopt this approach.  I
>>>  would like to find out.
>> 
>> Did you read the list traffic from Oct/Nov? I have no idea how you
>> can be in doubt if you did. It's readily apparent that your draft
>> has not caused a lot of people to change their minds. Do you agree?
>> If so, then the conclusion is obvious, isn't it?
> 
> I see a handfull of very vocal people on this topic and many quiet
> ones. 

Handful? I don't think that's at all accurate.

But we know head-counting doesn't count of course.

My question to you, that you've not answered, was whether you agree
that your draft has not caused any significant shift in positions.

> I hum in the meeting is a meaningful way to find out what the
> quiet people are thinking.

And of course also any people who try pack out the room for any
reason;-(

S






> 
> Russ
> 
> 


0x7B172BEA.asc
Description: application/pgp-keys


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

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

[Stephen Farrell]

Hi Russ,

On 13/03/18 21:49, Russ Housley wrote:
> The Prague discussion was about draft-green-...

Much more was discussed than just that one dead draft. In particular
see the minutes for the more general question posed by the chairs.

> Nick Sullivan summarized four concerns with that approach.  See 
> https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg
>
> 

> 
> draft-rhrd-... addresses all four of these concerns.  We had some 
> discussion on the mail list, which lead to -01 being posted.

The problem you have however is that you're trying to square a
circle, so picking any set of N objections to try to address will
still leave you ending up with something unacceptable, for at
least one of a bunch of reasons. Partly, that's because you need
there to be a boundary between a data centre and the rest of the
Internet that's meaningful to TLS, and no such boundary exists.

(So the answer to Nalini's problems is: for applications causing
you this particular pain within a data centre don't use TLS,
find another way and while that might be painful for Nalini's
consortium, it's the right answer, given the overall costs of
anything else.)

> I do not know if the TLS WG will want to adopt this approach.  I 
> would like to find out.

Did you read the list traffic from Oct/Nov? I have no idea how
you can be in doubt if you did. It's readily apparent that your
draft has not caused a lot of people to change their minds. Do
you agree? If so, then the conclusion is obvious, isn't it?

S.


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

Joe,

On 13/03/18 16:09, Joseph Salowey wrote:
> Hi Stephen,
> 
> It is not accurate to say that there was consensus to stop discussion of
> this topic in Prague.  

I did not say that.

I said numerous times that there was a clear lack of consensus
in Prague.

Based on the question *you* asked, which was much more general
than one about draft-green, that means that work in this space
is not being undertaken by the WG. I hope we agree on that.

> There are vocal contingents both for an against this
> topic. 
I could quibble there too - Nalini calls her folks a consortium,
and it certainly seems that there were a bunch of them in the room.
AFAIK, there's no well-organised other set of folks, just a bunch
of people who have significant overlapping technical concerns with
proposals to break TLS. But that's an aside.

> We did not have discussion of this draft in Singapore because the
> authors could not make the meeting due to several issues and we did not not
> think it would be appropriate to have a discussion without them present.
> We are going to continue forward and have discussion on this topic in the
> Monday TLS meeting in London.

My problem is that we *did* have significant discussion on the
list (of Russ and Ralph's -00 draft). I can see no way in which
anyone could read that mega-thread and conclude that this draft
is likely to garner rough consensus on the list.

And since the list is the place where we do real work, and we're
not in any case working on this topic as a WG (see above), allocating
a presentation slot for the -01 version of Russ and Ralph's draft
seems to me to be ignoring the WG participants' postings to the list,
and hence violating our processes.

I think you and Sean, as chairs, should have read the thread on
Russ and Ralph's -00 and said whether or not you think it could
achieve rough consensus. That requires no presentation from Russ.

I mean, do you *really* think there's any chance of reaching rough
consensus on the list for this draft? If not, then ISTM you're
putting meeting attendees and list participants through a bunch
of pain for no gain.

Lastly, to be clear: if Nalini's consortium's next set of authors
turn up with yet another attempt, then I would not ask you to
immediately shut down that *list* discussion, but just as in this
case, I would expect you to *not* schedule WG session time for such
a proposal, if significant list discussion has demonstrated that
folks' sets of opinions have not really changed. (Which is pretty
likely, isn't it?) Similarly, if such a proposal hasn't had any
list discussion then I also think it ought not get WG session
time. ISTM, that if you (chairs) don't start to impose that kind
of (normal actually) discipline on these efforts, we risk an
endless round of iterations of this overall discussion.

S.


> 
> 
> On Tue, Mar 13, 2018 at 7:21 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie>
> wrote:
> 
>>
>> Hiya,
>>
>> Just to be clear: I'm still waiting for the chairs and/or
>> AD to explain how the proposed discussion of this draft
>> is consistent with IETF processes, given the results of
>> the discussion in Prague (a very clear lack of consensus
>> to even work on this topic), and the discussion of the
>> -00 version of this late last year. IOW, I don't consider
>> my objection has been answered.
>>
>> In case people haven't got all the mails from last year
>> at the front of their minds, I went through them for you
>> and have provided links and selected quotes below. Yes,
>> the quotes are selected but I think do indicate that the
>> opposition to these ideas is as before. And there were
>> also the usual voices in support of weakening TLS in this
>> manner as well - a read of the thread clearly indicates
>> to me that discussion of this draft in London will, as
>> before, be a divisive waste of time and energy.
>>
>> Chairs: Please drop the agenda item, or explain how any
>> of this fits our process, because I'm just not getting
>> it.
>>
>> Thanks,
>> Stephen.
>>
>>
>> me, "IMO the WG shouldn't touch this terrible proposal with a
>> bargepole."
>>
>> https://www.ietf.org/mail-archive/web/tls/current/msg24493.html
>>
>> Randy Bush: "there are a lot of us lurkers out here a bit horrified
>> watching this wg go off the rails." (Different thread, but same topic)
>>
>> https://www.ietf.org/mail-archive/web/tls/current/msg24539.html
>>
>> Uri Blumenthal: "+1 to Stephen"
>>
>> https://www.ietf.org/mail-archive/web/tls/current/msg24542.html
>>
>> Rich Salz: "put this on hold for a year or two after TLS 1.3 is done"
>>
>> https://www.ietf.org/m

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

Hiya,

Just to be clear: I'm still waiting for the chairs and/or
AD to explain how the proposed discussion of this draft
is consistent with IETF processes, given the results of
the discussion in Prague (a very clear lack of consensus
to even work on this topic), and the discussion of the
-00 version of this late last year. IOW, I don't consider
my objection has been answered.

In case people haven't got all the mails from last year
at the front of their minds, I went through them for you
and have provided links and selected quotes below. Yes,
the quotes are selected but I think do indicate that the
opposition to these ideas is as before. And there were
also the usual voices in support of weakening TLS in this
manner as well - a read of the thread clearly indicates
to me that discussion of this draft in London will, as
before, be a divisive waste of time and energy.

Chairs: Please drop the agenda item, or explain how any
of this fits our process, because I'm just not getting
it.

Thanks,
Stephen.


me, "IMO the WG shouldn't touch this terrible proposal with a
bargepole."

https://www.ietf.org/mail-archive/web/tls/current/msg24493.html

Randy Bush: "there are a lot of us lurkers out here a bit horrified
watching this wg go off the rails." (Different thread, but same topic)

https://www.ietf.org/mail-archive/web/tls/current/msg24539.html

Uri Blumenthal: "+1 to Stephen"

https://www.ietf.org/mail-archive/web/tls/current/msg24542.html

Rich Salz: "put this on hold for a year or two after TLS 1.3 is done"

https://www.ietf.org/mail-archive/web/tls/current/msg24544.html

Ion Larranaga Azcue, "I really don't feel confortable with the approach
taken in this draft."

https://www.ietf.org/mail-archive/web/tls/current/msg24562.html

Hubert Kario: "to be clear: me too" (replying about hating the idea)

https://www.ietf.org/mail-archive/web/tls/current/msg24578.html

Rich Salz: "I am opposed to the basic concept of injecting a third-party
into the E2E TLS process."

https://www.ietf.org/mail-archive/web/tls/current/msg24585.html

Florian Weimer: "I don't understand why this complicated approach is
needed."

https://www.ietf.org/mail-archive/web/tls/current/msg24607.html

Ben Kaduk: "I do not see any potential for a workable solution."

https://www.ietf.org/mail-archive/web/tls/current/msg24620.html

Uri Blumenthal: "why do we spend time discussing this draft?"

https://www.ietf.org/mail-archive/web/tls/current/msg24639.html

Christian Huitema: "Maybe they have found ways to manage their
applications and servers without breaking TLS..."

https://www.ietf.org/mail-archive/web/tls/current/msg24643.html

Ted Lemon: "I think we should stop."

https://www.ietf.org/mail-archive/web/tls/current/msg24649.html

Andrei Popov: "deploying a weakened configuration of TLS 1.3 (without
PFS) would not meet the intent of those future mandates/requirements."
(On "industry need")

https://www.ietf.org/mail-archive/web/tls/current/msg24656.html

Ben Kaduk: "The time I am spending on this thread is time that I am not
able to spend improving the TLS 1.3 document."

https://www.ietf.org/mail-archive/web/tls/current/msg24660.html

Dave Garrett: "Please, let's just let this mess die. "

https://www.ietf.org/mail-archive/web/tls/current/msg24667.html

Uri Blumenthal "I'm against weakening the protocol, since there are
other ways to accomplish the perlustrator's mission"

https://www.ietf.org/mail-archive/web/tls/current/msg24670.html
Yeah, I had to look it up too:-)
https://en.oxforddictionaries.com/definition/us/perlustrator

Adam Caudill: "To be honest, I’m rather surprised that this group
continues to spend time on this."

https://www.ietf.org/mail-archive/web/tls/current/msg24712.html

Tony Arcieri, "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."

https://www.ietf.org/mail-archive/web/tls/current/msg24715.html

Colm MacCárthaigh: "I don't have too strong an interest in this thread,
it's not going anywhere, and I don't mind that."

https://www.ietf.org/mail-archive/web/tls/current/msg24720.html

Peter Saint-Andre: "+1 to Stephen's request." (for chairs to close down
the discussion)

https://www.ietf.org/mail-archive/web/tls/current/msg24734.html

Cas Cremers: " I think such a mechanism should not be part of the TLS
1.3 standard."

https://www.ietf.org/mail-archive/web/tls/current/msg24885.html

Karthikeyan Bhargavan: "I really don’t recommend any change to the TLS
1.3 design to accomplish any of this"

https://www.ietf.org/mail-archive/web/tls/current/msg24903.html



0x7B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital 

Re: [TLS] TLS@IETF101 Agenda Posted

[stephen . farrell]

Hiya,

On Saturday, 10 March 2018, Melinda Shore wrote:
> On 3/9/18 12:57 PM, Kathleen Moriarty wrote:
> > The hummed answer to that question was very close to 50/50 in the
> > room, inconclusive.
> 
> From the perspective of consensus decision-making that's
> actually very clear - there's no consensus.  What that
> means in practice depends on the question that was asked,
> but at any rate I think what matters here is a lack of
> consensus.

Agreed. My earlier mail pointed at the minutes as to the question.  

> 
> Also, there's been basically no discussion of the draft
> on the mailing list, and I'm not sure why.
>

There was lots of discussion about -00, late last year.  -01 isn't 
significantly different afaics. From my pov that discussion was entirely 
predictable indicating no significant changes in position. 

Cheers 
S
 
> Melinda
> 
> -- 
> Software longa, hardware brevis
> 
> PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
>  34C0 DFB8 9172 9A76 DB8F
> 
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

Kathleen,

On 09/03/18 21:57, Kathleen Moriarty wrote:
> Hello, Stephen.
> 
> On Fri, Mar 9, 2018 at 4:24 PM, Stephen Farrell
> <stephen.farr...@cs.tcd.ie> wrote:
>>
>> Hi Joe,
>>
>> I'm sorry, but I gotta say that answer seems to me both unresponsive
>> to the questions asked and unconvincing.
>>
>> On 08/03/18 23:08, Joseph Salowey wrote:
>>> Hi Stephen,
>>>
>>> In the meeting in Prague there was interest in this problem space, but
>>> neither the consensus to accept or reject this work.
>>
>> Without rough consensus to adopt, the work is not adopted.
>>
>> But your statement above isn't accurate - it wasn't "this work"
>> (as in this draft) that was discussed in Prague, but rather the
>> entire idea of weakening TLS in these ways - quoting from the
>> Prague minutes [1]:
>>
>> "The main question: Is this subject something that the WG should
>> consider?"
> 
> The hummed answer to that question was very close to 50/50 in the
> room, inconclusive.

I'm sorry to disagree but it was entirely clear there was a
lack of consensus. That's the significant thing here. And
there is zero evidence that anyone's changing their position.

That ought be enough for the chairs to say no to all proposals
in this space unless someone turns up with something unexpected.

That's not the case here - in discussion of this draft, various
folks asked on the list that we stop the constant debate about
making TLS worse, so there is zero evidence that this draft is
going to change people's minds.

Where am I wrong?

> 
>>
>> There is clearly no consensus to adopt *any* work in this space,
>> whether that be draft-green or this latest iteration from Russ
>> and Ralph.
> 
> It was clear that there was no consensus to adopt draft-green and that
> is considered dead in the water, we agree there. 

The question asked in Prague was not specific to draft-green.
I would have preferred if it had been and Lucy Lynch suggested
that in fact (so say the minutes) but the chairs conferred and
asked a much more general question. The consequence is that
Russ and Ralph's draft, having been discussed on the list, with
no evidence that it's changed minds, ought not be taken further
in the WG and ought not get agenda time.

Where am I wrong?

> Since there was
> interest (50% of the room) to consider work in this space, I agree
> with the chairs assessment to allow this presentation.  I am confident
> they will work on any hums to carefully assess next steps and if any
> future proposals belong in this WG or elsewhere.

Again, I'm sorry but that's just not logical. There's abundant
evidence that people's opinions have not changed from the earlier
discussion of Russ and Ralph's draft so it makes no sense at all
to repeatedly impose this divisive topic on the WG.

S.


> 
>>
>> I see nothing whatsoever to indicate any significant change in
>> sets of opinions since Prague.
>>
>> What makes you think iterating on yet more proposals like this
>> will ever conclude? If there's no evidence of that we ought not
>> waste the time and energy. Can you point at any change that
>> could possibly indicate that this bun-fight is worth doing yet
>> again?
>>
>>>  The authors have
>>> revised their proposal to address some of the concerns raised by working
>>> group members and are asking to bring the new approach in front of the
>>> working group.
>>
>> What significant change has there been since -00 of Russ and Ralph's
>> draft? I see nothing major there. that -00 was debated on the list
>> which is the primary place for  discussion. My read of that set of
>> threads it that it pretty clearly showed that the same folks have
>> the same opinions with no significant movement. Can you point at
>> some evidence to the contrary? If not, we shouldn't bother to waste
>> more time on this.
>>
>> If instead you mean Russ and Ralph's draft differs from draft-green,
>> then see above - it wasn't only draft-green that was rejected in
>> Prague, but the entire idea of adopting work in this space, which
>> includes Russ and Ralph's -00 and -01.
>>
>> That the authors have asked for time counts for nothing, when the
>> WG have no consensus to work in this space. If just asking for time
>> does matter, then I'll now publicly repeat my request for time
>> to refure the assertions that'll be made for breaking TLS. You said
>> no to my request, so what's different about one that relates to a
>> draft that has been debated on the list and attracted significant
>> negative comment?
>>
>>> I believe in th

Re: [TLS] New Version Notification for draft-rhrd-tls-tls13-visibility-01.txt

[Stephen Farrell]

With no dis-respect to Russ or Ralph (but with zero
acceptance/respect for the main concept espoused by this
draft)...

I request that the WG chairs not waste yet more time on
agenda items dealing with proposals for breaking TLS - a
working group that spends so many f2f hours (yes, hours,
multiplied by a few hundred travelling people in a room)
on ways in which the core purpose of the WG (read the
abstract of the tls1.3 draft if you doubt that) could be
subverted *by the WG itself* seems really really weird to
me.

Enough, already.

Given the (lack of) potential for any of these (IMO bad)
ideas to garner rough consensus, I really think this would
be a *terribly* bad waste of f2f time and participant cycles,
no matter who proposes we waste time in that manner.

If time is regrettably granted for this yet again then I
also request time to propose not breaking TLS. (I don't care
if the presenter for that rebuttal slot is me or someone
else with the same views that the WG charter is clear that
the WG exists to make TLS better and not to break it.)

If a rebuttal slot is not considered appropriate then I
request a slot to help us reach consensus on whether or
not there's value in documenting the reasons to not break
TLS. (I believe the chairs agreed to try figure out if
the WG have consensus that that'd be worthwhile a couple
of meetings ago, but we've not done that so far.)

To be clear: given a choice of (a) not wasting yet more WG
time on this and (b) another bun-fight with an inevitable
outcome - I prefer (a) but will engage in (b) as necessary
(and enthusiastically, whilst grimacing;-)

Thanks,
S.

PS: That Russ requests a few minutes for an update does not
affect the above - I for one do not agree that this draft
ought get any WG time and allocating a few minutes for an
update would IMO normalise what ought be considered entirely
abnormal. The number of "proponent minutes this time" is not
a valid agenda-planning consideration IMO.

On 02/03/18 21:00, Russ Housley wrote:
> A few minutes at the TLS WG session in London have been requested to talk 
> about this draft.
> 
> Russ
> 
> 
>> From: internet-dra...@ietf.org
>> Subject: New Version Notification for draft-rhrd-tls-tls13-visibility-01.txt
>> Date: March 2, 2018 at 3:58:35 PM EST
>> To: "Ralph Droms" , "Russ Housley" 
>> 
>>
>>
>> A new version of I-D, draft-rhrd-tls-tls13-visibility-01.txt
>> has been successfully submitted by Ralph Droms and posted to the
>> IETF repository.
>>
>> Name:draft-rhrd-tls-tls13-visibility
>> Revision:01
>> Title:   TLS 1.3 Option for Negotiation of Visibility in the 
>> Datacenter
>> Document date:   2018-03-02
>> Group:   Individual Submission
>> Pages:   11
>> URL:
>> https://www.ietf.org/internet-drafts/draft-rhrd-tls-tls13-visibility-01.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
>> Htmlized:   
>> https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-01
>> Htmlized:   
>> https://datatracker.ietf.org/doc/html/draft-rhrd-tls-tls13-visibility-01
>> Diff:   
>> https://www.ietf.org/rfcdiff?url2=draft-rhrd-tls-tls13-visibility-01
>>
>> Abstract:
>>   Current drafts of TLS 1.3 do not include the use of the RSA
>>   handshake.  While (EC) Diffie-Hellman is in nearly all ways an
>>   improvement over the TLS RSA handshake, the use of (EC)DH has impacts
>>   certain enterprise network operational requirements.  The TLS
>>   Visibility Extension addresses one of the impacts of (EC)DH through
>>   an opt-in mechanism that allows a TLS client and server to explicitly
>>   grant access to the TLS session plaintext.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
> 
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

[Stephen Farrell]

Just on the 0-RTT thing:

As a non-fan of 0-RTT I agree with Colm's conclusion. (Nicely
argued too btw.)

I do believe we'll live to regret 0-RTT when implementation
issues and unsuitable application uses emerge over time but
neither that nor general dislike of 0-RTT are IMO sufficient
reasons to hold TLS 1.3 at this point, given the benefits of
other aspects of TLS 1.3.

In addition, the fact of 0-RTT as an (in practice) unavoidable
part of TLS 1.3 and the implications of that were previously
raised with both the IESG and IAB in a fair amount of detail,
(about 1.5-2 years ago maybe but the issues are the same) and
IIRC at an IETF plenary as well, so this has been rehearsed
before the IETF already, even if not during a formal IETF LC.

Cheers,
S.

On 19/02/18 19:13, Colm MacCárthaigh wrote:
> Since this IETF-LC/IESG process is a good chance to get a sanity check, I'd
> like to boil down what I think are the nits and risks with 0-RTT, and if
> others want to weigh in they can. I'll state my own position at the bottom.
> 
> Broadly, I think there are three issues with 0-RTT:
> 
>1) The TLS 1.3 draft allows for 0-RTT data, including things like
> requests and headers, to be replayed by attackers.
> 
>2) 0-RTT data, again including requests and headers, has no
> cryptographic guarantee of forward-secrecy and will likely be protected by
> symmetric session ticket encryption keys (STEK) that can be used quite
> broadly with no limits on re-use, rotation, and rely on vendors being able
> to share and revoke keys frequently and securely. Basically: If a vendors
> STEK is compromised, than an unbounded number of end-user requests and
> headers can be decrypted. This obviously defeats the goal of achieving
> forward secrecy.
> 
>   3) While no working attack has been found, some cryptographers and
> protocol experts believe that the 0-RTT exchange is overly-complex and a
> source of risk. Kenny Paterson made the most prominent statement (
> http://bristolcrypto.blogspot.com/2017/03/pkc-2017-kenny-paterson-accepting-bets.html
> ), but I've heard it echoed at several IACR events. It is definitely true
> that 0-RTT resumption complicates the TLS state machine and creates unusual
> conditions such as needing to restart messaging sequences.
> 
> The TLS-WG was chartered with "aiming for one roundtrip for a full
> handshake and one or zero roundtrip for repeated handshakes. The aim is
> also to maintain current security features" (
> https://datatracker.ietf.org/wg/tls/charter/).  But with these 3 issues,
> there is a clearly a trade-off between security (the S in TLS) and speed.
> 
> Issue 3 is matter of judgment; my personal judgement is that we will see
> implementation bugs due to state machine complexity, but there's no
> evidence that the cryptographic and protocol semantics are not robust.
> 
> With regards to issues 1, and 2, the latest TLS draft makes it possible to
> achieve both of these aims. Through the use of single-use session tickets,
> it is possible to provide anti-replay and forward-secrecy properties for
> 0-RTT data. I'm grateful for the changes that were introduced for this.
> 
> At the same time though, most vendors have stated that they don't plan to
> do that and instead have designed around limited replay time windows,
> non-transactional strike registers, and non-forward secure tickets. This is
> what I expect to see deployed, and already see with some TLS1.3 deployment
> experiments.  TLS1.3 could be more restrictive here; limiting the size of
> session tickets to smaller than the size of session state would effectively
> forbid any kind of session encoding which would force the issue, but
> several vendors are against it because it doesn't align with current
> practices and it incurs the cost of server-size caching. For balance, in
> the last year I have heard from most vendors that they do plan to implement
> some anti-replay mitigation though, beyond the simple time-windowing, which
> goes a way to protecting users from throttle limits.
> 
> I am disappointed by the unfortunate preference for cost-saving over robust
> security. Good cryptography usually costs money, or else we'd still be
> using RC4. I do think that we will see security and correctness issues due
> to replays interacting with non-idempotent services and throttling
> configurations. While it's true that browsers can be made to replay
> requests already, there are many web and non-HTTP services that are
> certainly not tolerant of replays. Secondly, I think that it is inevitable
> that vendor security compromises will disclose troves of user requests,
> passwords, credit cards to decryption; but this is perhaps more of a
> nation-state-adversary level risk. Some more detail on attacks related to
> issues 1/ and 2/ is available in the security review of 0-RTT data:
> https://github.com/tlswg/tls13-spec/issues/1001 .
> 
> 
> After all of that, here's my own position:
> 
> I strongly support the current TLS1.3 draft 

Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-04.txt

[Stephen Farrell]

Hiya,

On 15/02/18 13:12, Sean Turner wrote:
> Kathleen and Stephen,
> 
> This version incorporates the WGLC issues.  The authors believe this is now 
> ready for IETF LC.

As shepherd, I concur that this seems to address all the
issues raised as per list discussion.

This is a clearly non-crazy update:-)

Cheers,
S.

> 
> spt
> 
>> On Feb 15, 2018, at 08:10, internet-dra...@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Transport Layer Security WG of the IETF.
>>
>>Title   : IANA Registry Updates for TLS and DTLS
>>Authors : Joe Salowey
>>  Sean Turner
>>  Filename: draft-ietf-tls-iana-registry-updates-04.txt
>>  Pages   : 18
>>  Date: 2018-02-15
>>
>> Abstract:
>>   This document describes a number of changes to (D)TLS IANA registries
>>   that range from adding notes to the registry all the way to changing
>>   the registration policy.  These changes were mostly motivated by WG
>>   review of the (D)TLS-related registries undertaken as part of the
>>   TLS1.3 development process.  This document updates many (D)TLS RFCs
>>   (see updates header).
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-04
>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-04
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-04
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ___
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt

[Stephen Farrell]

Hi Kathleen,

The WGLC for this has expired.

There was only one explicit comment [1] saying to ship it.
The WG have chatted about this a bunch of times though so
FWIW I think it'd be fair to conclude there's pretty good
consensus for this.

Cheers,
S.

[1] https://www.ietf.org/mail-archive/web/tls/current/msg25279.html

On 15/01/18 21:34, Stephen Farrell wrote:
> 
> Hiya,
> 
> Kathleen's a bit busy at the moment so asked that, as shepherd,
> I kick off the WGLC for this one (as the two chairs are authors).
> The idea is that I'll summarise the WGLC thread to her and she
> can then decide if this is ready to move forward.
> 
> So this starts a 2-week WGLC, ending on January 29th.
> 
> Cheers,
> Shepherdy Stephen.
> 
> On 03/01/18 13:57, internet-dra...@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Transport Layer Security WG of the IETF.
>>
>> Title   : IANA Registry Updates for TLS and DTLS
>> Authors : Joe Salowey
>>   Sean Turner
>>  Filename: draft-ietf-tls-iana-registry-updates-03.txt
>>  Pages   : 16
>>  Date: 2018-01-03
>>
>> Abstract:
>>This document describes a number of changes to (D)TLS IANA registries
>>that range from adding notes to the registry all the way to changing
>>the registration policy.  These changes were mostly motivated by WG
>>review of the (D)TLS-related registries undertaken as part of the
>>TLS1.3 development process.  This document updates many (D)TLS RFCs
>>(see updates header).
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03
>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-03
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-03
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ___
>> 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
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


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

[TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt

[Stephen Farrell]

Hiya,

Kathleen's a bit busy at the moment so asked that, as shepherd,
I kick off the WGLC for this one (as the two chairs are authors).
The idea is that I'll summarise the WGLC thread to her and she
can then decide if this is ready to move forward.

So this starts a 2-week WGLC, ending on January 29th.

Cheers,
Shepherdy Stephen.

On 03/01/18 13:57, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
> Title   : IANA Registry Updates for TLS and DTLS
> Authors : Joe Salowey
>   Sean Turner
>   Filename: draft-ietf-tls-iana-registry-updates-03.txt
>   Pages   : 16
>   Date: 2018-01-03
> 
> Abstract:
>This document describes a number of changes to (D)TLS IANA registries
>that range from adding notes to the registry all the way to changing
>the registration policy.  These changes were mostly motivated by WG
>review of the (D)TLS-related registries undertaken as part of the
>TLS1.3 development process.  This document updates many (D)TLS RFCs
>(see updates header).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-03.txt

[Stephen Farrell]

On 04/01/18 16:51, Sean Turner wrote:
> 
> As we discussed in Singapore, Stephen Farrell has graciously offered to 
> Shepherd this draft; write-up can be found at:
> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/shepherdwriteup/

Gracious? Me? Well, I guess given the time of year it's ok to
pretend:-)

For those good at identifying folks based on writing style,
you'll quickly detect that Sean did the initial write-up and
I just did some edits. (Thanks Sean:-)

I do however fully agree with the content and did re-read the
draft etc. And I'm also convinced this is ready to go.

Cheers,
S.


-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] access_administratively_disabled v2

[Stephen Farrell]

On 04/01/18 14:22, Eric Rescorla wrote:
> I am not in favor of this change at this time.

Same here.

> 
> I suspect I'm not in favor of the mechanism, but i'm definitely not in
> favor of
> adding a placeholder alert for some mechanism which isn't specified.

I'm fairly sure I'm against attempting to handle captive
portal issues at the TLS layer. Any changes to TLS needed
for captive portals ought really garner consensus within
the capport wg and then be discussed here. (It looks from
the archive of that wg that this topic hasn't even been
raised there despite a few people suggesting that, which
is IMO another reason to reject this proposal now.)

I don't find the more-transparent-censorship argument
offered convincing. If DNS-based censorship is offered as
the motivation (as opposed to or in addition to captive
portals) then I think that'd require chatting with the
dnsop folks, who are already discussing DNS-RPZ. I'd guess,
(but not sure as it's not my fav. idea;-), that might throw
up a requirement that censorship might only be done for a
few minutes while some previously unseen name was checked
out, or a name might be censored for days or weeks, if it's
newly registered and some censor considers that a threat.
IOW, if any changes to TLS are warranted based on DNS-based
censorship, then those are likely more complex than has
been seen in this discussion, and also aren't things where
this list has the right expertise AFAIK.

S.

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


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

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

[Stephen Farrell]

On 02/01/18 20:08, Mateusz Jończyk wrote:
>> I'm not really enthusiastic about any of these ideas for any of the
>> administratively prohibited
>> use cases because the information being provided to the user is unverifiable.
>> I.e., this
>> just tells you that someone on the network didn't like it, but the message
>> itself is just
>> an assertion (this is different from 451 in that that's provided inside the 
>> TLS
>> channel
>> if TLS is used). It's not like, for instance, the browser should display the
>> string to the
>> user as if it were true.
> Then the browser should display a message inside the warning screen that the
> string cannot be trusted. 

There isn't always a browser. I'd say caldav was responsible for
nearly as many cert warnings for me, but I only know that 'cause
I delved into detail to find out. And the same'd be true of any
application that regularly pulls from somewhere. I think that's
another reason to handle this in the capport wg - I'd guess folks
there are more aware of the full range of cases that may need
handling and of how to try interpose the portal web page stuff
before other applications see the n/w as active (or whatever it
is they're doing with HTTP:-).

> This is no less secure then an alternative: a TLS
> certificate error that conveys no message to the user whatsoever.

That's true. OTOH, I'm not sure a different error is any more
secure either.

S.


-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] Additional TLS 1.3 results from Chrome

[Stephen Farrell]

Hiya,

On 19/12/17 13:56, Salz, Rich wrote:
> “dropped as a bad idea” is an interesting end-state.  Also “on hold
> for now” (which is how I want to see the TLS-breaking proposals).
> 
> Having more I-D workflow options seems like something the IESG should
> take up.
> 

Well, TBH I doubt it'd be best done from the IESG down.

If some WG wanted to pursue this kind of thing, I'd say
it'd be much better done by the WG and then the IESG
could get to decide what they think if/when such a draft
is ever put forward by the WG for publication as an RFC.

And for most WGs, there's little danger in expired I-Ds
hanging about unchanged. For TLS, as we've seen in this
case, there might be a downside to the expired I-D not
containing text saying: "Don't do this! Really. And
 why." :-)

As an aside, I'd say it'd be better to not think of
this as a retraction, but more as a case of ensuring
that the public record, as seen in the I-D repository,
better reflects the WG consensus, for the few cases
where there would be a concrete reason to not want
people to write or deploy code implementing the draft
concerned.

For a WG draft, the WG itself can always decide that
the right thing to happen is to publish a tombstone
draft, so that could be handled easily enough.

For a draft that's proposed for WG adoption, or that's
discussed but not adopted, it might get complicated, if
the authors don't agree that WG non-adoption is a good
reason to put out a tombstone. (We'd likely need the WG
to adopt the draft solely to put out the tombstone,
which'd be a bit weird.)

So as I said, I'm about half-convinced:-)

Cheers,
S.




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

Re: [TLS] Additional TLS 1.3 results from Chrome

[Stephen Farrell]

Hiya,

On 19/12/17 01:59, Salz, Rich wrote:
> However, since extension numbers are essentially infinite, this WG may
> consider renumbering key_share to avoid the issue.
> 
>> I think this would be fine, but not imperative.
> 
> I think it would almost be hypocritical if we did not do it.
> 

I'm not sure I agree renumbering is the right reaction,
though I don't object to that. This could be a case where
it's overall better that those specific devices suffer
breakage, and hopefully then do get firmware updated to
support TLS1.3 or TLS-without-extended-random-or-dual-ec
at some point.

WRT extended-random, it seems like the IETF process did
work, in that we dropped the work. However, it may also
be the case that the attacker's process (if one assumes
that somewhere in the background (*) there was an attacker
who wanted dual-ec attacks to be more efficient) also
worked to at least some extent in that they got that to
be deployed in some places, presumably at least partly
based on the existence of the (then expired?) draft.

I wonder if that argues for some kind of "dropped as a
very bad idea" tombstone draft (or even RFC) for such
cases? I can imagine that the IETF or TLS WG could do
that, but I'm not sure if it'd have helped the developers
of bsafe or those printers avoid the problem if such a
thing had existed. In the case of extended-random, it
is now clear that it is a very bad idea, even if that
wasn't the case when the WG chose to not proceed with
the work, so such a tombstone draft or RFC could be
easily done and could possibly be useful. (I'm about
half-convinced of that;-)

One reason to think about this is that we have some
more-current bad-idea drafts (e.g. draft-green) that
we know are dead, but folks not involved in the WG might
not be aware of that, so it could be good if those
were somewhat more officially put to rest than just
sitting forever as expired I-Ds. It'd be a fine thing
if the authors of such drafts did that themselves of
course, but if not, I'd volunteer to help:-)

Cheers,
S.

(*) To be clear, I am not at all saying the authors of
the extended-random draft were part of any attack. If
I were the bad actor in such a case, I'd ensure the
names that were public weren't in on the plan.








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

Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates

[Stephen Farrell]

On 21/11/17 23:39, Martin Thomson wrote:
> IESG action seems appropriate for both.  

I'm fairly sure the WG discussed the No->Yes (or new Yes)
before and wanted standards action for that. I'd guess
that changing that might take some discussion. (FWIW, I'd
not support that change myself but maybe others would.)

If the No->Yes stuff doesn't change I'll take you as
arguing for a (4) below but correct me if that's wrong.

Cheers,
S.

> If we could include guidance
> around this (values with Yes should only include those for which the
> community currently has consensus are worth having available at the
> current time), tat would be awesom>
> On Wed, Nov 22, 2017 at 7:37 AM, Stephen Farrell
> <stephen.farr...@cs.tcd.ie> wrote:
>>
>> Hiya,
>>
>> I just posted a draft shepherd write-up for this [1]. (The
>> write-up text was mostly written by Sean as it happens - for
>> which he has my thanks as it's boring as hell to do that:-)
>>
>> There are nits but only one substantive question that I don't
>> recall the WG discussing before (but maybe I'm forgetting).
>>
>> What is needed to change from Recommended == Yes down to
>> Recommended == No? Does that need a standards action (e.g.
>> with an RFC) or just IETF review or even maybe just IESG
>> action?
>>
>> In the current draft write-up I've put in the first as a
>> placeholder, as that's symmetric with the No->Yes change but
>> I think IESG action is probably ok if the WG wanted that as
>> the IESG probably won't go crazy and will likely do as the
>> WG want in such cases. If the WG do want to write a specific
>> foo-no-longer-recommended RFC it can do that in all cases,
>> and of course Yes->No transitions could be documented in an
>> RFC that documents a "replacement" Yes entry.
>>
>> So, unless this was already discussedanswers on a postcard
>> please - which'd we like:
>>
>> (1) say nothing (as in -02 draft)
>> (2) say standards action is required for a Yes->No transition
>> (3) say IETF review (i.e. an IETF last call) is required for a
>> Yes->No transition
>> (4) say IESG action is required for a Yes->No transition
>> (5) something else
>>
>> And as a reminder the Recommended column is not about crypto
>> quality but is about things for which we have consensus that
>> they ought be widely implemented and available at the current
>> point in time. Those are related things but Recommended == No
>> does not imply crap-crypto even if crap-crypto will hopefully
>> imply Recommended == No.
>>
>> If nobody says anything I'll chat with Kathleen, Sean and Joe
>> and we'll pick a thing and that'll doubtless be quibbled about
>> during directorate reviews and IESG processing as these things
>> always are;-)
>>
>> But since I'd hope implementers will care about keeping up to
>> date with the set of Recommended == Yes things, I do hope that
>> folks are willing to express a preference here.
>>
>> Cheers,
>> S.
>>
>> [1]
>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/shepherdwriteup/
>>
>>
>> ___
>> 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

[TLS] question for the WG about draft-ietf-tls-iana-registry-updates

[Stephen Farrell]

Hiya,

I just posted a draft shepherd write-up for this [1]. (The
write-up text was mostly written by Sean as it happens - for
which he has my thanks as it's boring as hell to do that:-)

There are nits but only one substantive question that I don't
recall the WG discussing before (but maybe I'm forgetting).

What is needed to change from Recommended == Yes down to
Recommended == No? Does that need a standards action (e.g.
with an RFC) or just IETF review or even maybe just IESG
action?

In the current draft write-up I've put in the first as a
placeholder, as that's symmetric with the No->Yes change but
I think IESG action is probably ok if the WG wanted that as
the IESG probably won't go crazy and will likely do as the
WG want in such cases. If the WG do want to write a specific
foo-no-longer-recommended RFC it can do that in all cases,
and of course Yes->No transitions could be documented in an
RFC that documents a "replacement" Yes entry.

So, unless this was already discussedanswers on a postcard
please - which'd we like:

(1) say nothing (as in -02 draft)
(2) say standards action is required for a Yes->No transition
(3) say IETF review (i.e. an IETF last call) is required for a
Yes->No transition
(4) say IESG action is required for a Yes->No transition
(5) something else

And as a reminder the Recommended column is not about crypto
quality but is about things for which we have consensus that
they ought be widely implemented and available at the current
point in time. Those are related things but Recommended == No
does not imply crap-crypto even if crap-crypto will hopefully
imply Recommended == No.

If nobody says anything I'll chat with Kathleen, Sean and Joe
and we'll pick a thing and that'll doubtless be quibbled about
during directorate reviews and IESG processing as these things
always are;-)

But since I'd hope implementers will care about keeping up to
date with the set of Recommended == Yes things, I do hope that
folks are willing to express a preference here.

Cheers,
S.

[1]
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/shepherdwriteup/



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

Re: [TLS] network-based security solution use cases

[Stephen Farrell]

Hiya,

On 08/11/17 00:23, Nancy Cam-Winget (ncamwing) wrote:
> Hi Stephen,
> Please see below:
> 
> On 11/7/17, 4:08 PM, "Stephen Farrell" <stephen.farr...@cs.tcd.ie> wrote:
> 
> 
> Hiya,
> 
> On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote:
> > Hi Stephen, Adding to Flemming’s comment,  finding “exact quotes”
> > will be difficult 
> 
> I'm sorry but when making a claim that such and such a regulation
> *requires* breaking TLS then you really do need to be that precise.
> [NCW] In TLS 1.2, not sure why you state *requires* as there is the 
> visibility afforded to 
> at least allow for the identity disclosure to enable white or blacklist for 
> example.  

Quoting from your draft wrt PCI-DSS:

" Requirement #2 (and Appendix A2 as it concerns TLS)
   describes the need to be able to detect protocol and protocol usage
   correctness."

That one is nice - you seem to be arguing for protocol non-conformance
(or for weakening conformant implementations) in order to help ensure
"protocol usage correctness." That kind of makes my head spin.

Another quote wrt NERC:

" In fact, regulatory standards such as NERC CIP
   [NERCCIP] place strong requirements about network perimeter security
   and its ability to have visibility to provide security information to
   the security management and control systems. "

Where exactly did you see those "strong requirements" that presumably
*require* breaking TLS?

I don't see them.

When I or others ask to be shown them we don't get shown them.

To me that means those are not *required*.

> 
> > as their intent is really not to break things but
> > rather want to ensure that inspection and oversight is available to
> > affect guards/protections within an (enterprise/data center)
> > infrastructure.   That said, PCI and other regulations will have a
> > lot of documents that one has to go through….one that kind-of calls
> > explicitly to the use of packet inspection, firewalling and such is
> > in:
> > 
> > https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.pdf
> 
> The first mention of TLS there talks about protecting administrator
> passwords via TLS. That totally argues against deployment of any kind
> of MitM infrastructure.
> [NCW] Agreed, they also state in ensuring that the newest TLS version where 
> possible is used.  BUT, they also expect monitoring and troubleshooting.

Sure. Not all monitoring *requires* breaking TLS. Same for
troubleshooting.

Of course people who sell kit for that or have been doing
that for a while might want to see what they do as being
mandatory/required/regulated-for but I'm not seeing it.

> 
> > 
> > It is an assessment questionnaire for vendors to evaluate their
> > compliance, the requirements speak to securing the network and
> > systems including firewalls, DMZs and the ability to do packet
> > inspection.
> 
> Please point me at the specific text. Given you added PCI-DSS to
> your document I would assume you did the work already. If not,
> that's a bit odd.
> [NCW] From the link above, you can look at requirements in 1.3,
> also Requirement 10 details the need to monitor and provide audit trails
> for network resources and cardholder data

You mean 1.3 on page 6 I guess. I see nothing on pages 6 or 7
that call for MitMing TLS. That seems to be about addressing
and DMZs and firewall and router configs.

Requirement 10 seems to be dealing with audit of accesses to
cardholder data, not with TLS at all. I read pages 50-55 for
that.

Honestly, what you're saying is there does not seem to be
there.

S.


> 
> S.
> 
> 
> > 
> > Thanks, Nancy
> > 
> > On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)"
> > <fandr...@cisco.com> wrote:
> > 
> > Thanks for taking an initial look at the document Stephen - please
> > see below for responses so far
> > 
> > On 11/7/17 4:13 AM, Stephen Farrell wrote:
> >> Hiya,
> >> 
> >> On 07/11/17 02:48, Flemming Andreasen wrote:
> >>> We didn't draw any particular line, but the use case scenarios
> >>> that we tried to highlight are those related to overall security
> >>> and regulatory requirements (including public sector)
> >> I had a quick look at the draft (will try read properly en-route
> >> to ietf-100) and I followed the reference to [1] but that only lead
> >> to a forest of documents in which I didn't find any reference to
> >>

Re: [TLS] network-based security solution use cases

[Stephen Farrell]

Hiya,

On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote:
> Hi Stephen, Adding to Flemming’s comment,  finding “exact quotes”
> will be difficult 

I'm sorry but when making a claim that such and such a regulation
*requires* breaking TLS then you really do need to be that precise.

> as their intent is really not to break things but
> rather want to ensure that inspection and oversight is available to
> affect guards/protections within an (enterprise/data center)
> infrastructure.   That said, PCI and other regulations will have a
> lot of documents that one has to go through….one that kind-of calls
> explicitly to the use of packet inspection, firewalling and such is
> in:
> 
> https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.pdf

The first mention of TLS there talks about protecting administrator
passwords via TLS. That totally argues against deployment of any kind
of MitM infrastructure.

> 
> It is an assessment questionnaire for vendors to evaluate their
> compliance, the requirements speak to securing the network and
> systems including firewalls, DMZs and the ability to do packet
> inspection.

Please point me at the specific text. Given you added PCI-DSS to
your document I would assume you did the work already. If not,
that's a bit odd.

S.


> 
> Thanks, Nancy
> 
> On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)"
> <fandr...@cisco.com> wrote:
> 
> Thanks for taking an initial look at the document Stephen - please
> see below for responses so far
> 
> On 11/7/17 4:13 AM, Stephen Farrell wrote:
>> Hiya,
>> 
>> On 07/11/17 02:48, Flemming Andreasen wrote:
>>> We didn't draw any particular line, but the use case scenarios
>>> that we tried to highlight are those related to overall security
>>> and regulatory requirements (including public sector)
>> I had a quick look at the draft (will try read properly en-route
>> to ietf-100) and I followed the reference to [1] but that only lead
>> to a forest of documents in which I didn't find any reference to
>> breaking TLS so far at least. Can you provide an explicit pointer
>> to the exact document on which that claim is based?
> For NERC, you can look under  "(CIP) Critital Infrastructure 
> Protection". CIP-005-5 for example covers the electronic security 
> perimeter, which has a couple of relevant requirements and associated
> text:
> 
> http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=United%20States
> 
> 
> 
> To be clear though, the document does not specifically call out
> breaking TLS, but it does clearly call out the need to detect
> malicious inbound and outbound communications by leveraging an
> "Electronic Access Point" (e.g. IDS/IPS) to enforce the Electronic
> Security Perimeter.
>> I'd also claim that your reference to PCI-DSS is misleading, as
>> that same spec also explicitly calls for there to be good key
>> management specifically including minimising the number of copies
>> of keys, so at most, one might be able to claim that PCI-DSS is ok
>> with people who break TLS in a nod-and-a-wink manner. But if you do
>> have a real quote from PCI-DSS that calls for breaking TLS then
>> please do also send that (it's been asked for a bunch of times
>> without any answer being provided so far).
> 
> I will need to look more closely for such a quote - if anybody else 
> knows of one, please chime in as well.
> 
> Thanks
> 
> -- Flemming
> 
> 
>> Thanks, S.
>> 
>> 
>> [1] 
>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
>
>> 
> 
> 
> 
> 



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

Re: [TLS] network-based security solution use cases

[Stephen Farrell]

Hiya,

On 07/11/17 23:27, Flemming Andreasen wrote:
> Thanks for taking an initial look at the document Stephen - please see
> below for responses so far
> 
> On 11/7/17 4:13 AM, Stephen Farrell wrote:
>> Hiya,
>>
>> On 07/11/17 02:48, Flemming Andreasen wrote:
>>> We didn't draw any particular line, but the use case scenarios that we
>>> tried to highlight are those related to overall security and regulatory
>>> requirements (including public sector)
>> I had a quick look at the draft (will try read properly en-route to
>> ietf-100) and I followed the reference to [1] but that only lead to a
>> forest of documents in which I didn't find any reference to breaking
>> TLS so far at least. Can you provide an explicit pointer to the
>> exact document on which that claim is based?
> For NERC, you can look under  "(CIP) Critital Infrastructure
> Protection". CIP-005-5 for example covers the electronic security
> perimeter, which has a couple of relevant requirements and associated text:
> 
> http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)=United%20States
> 

Thanks for that.

So I didn't see any mention of TLS in that document at all.

> 
> To be clear though, the document does not specifically call out breaking
> TLS, but it does clearly call out the need to detect malicious inbound

For inbound (on page 9) I see it mentions IDSes and application
layer firewalls as examples yes. Given that the latter would not
require any messing with TLS at all, this seems to be a very
clear example of a regulation not requiring breaking TLS. That'd
mean there is no regulatory requirement at all wouldn't it?

But again, if there are real regulatory requirements there that
really do call for MitM attacks on TLS I'd be glad to look at them
if you want to quote them.

> and outbound communications by leveraging an "Electronic Access Point"
> (e.g. IDS/IPS) to enforce the Electronic Security Perimeter.

Personally, I have to say I find the outbound stuff nonsense.
I know people make money selling product and services for that.

>> I'd also claim that your reference to PCI-DSS is misleading, as that
>> same spec also explicitly calls for there to be good key management
>> specifically including minimising the number of copies of keys, so
>> at most, one might be able to claim that PCI-DSS is ok with people
>> who break TLS in a nod-and-a-wink manner. But if you do have a real
>> quote from PCI-DSS that calls for breaking TLS then please do also
>> send that (it's been asked for a bunch of times without any answer
>> being provided so far).
> 
> I will need to look more closely for such a quote - if anybody else
> knows of one, please chime in as well.

It's been asked for a number of times without any substantive
response. I would assume that one of the authors of this would
be able to point at the text that caused you to add in a mention
of PCI-DSS. If not, that seems odd.

I actually looked through the PCI spec myself and found that it
is fairly explicitly asking for good crypto and not bad crypto.
(E.g. as mentioned, saying to minimise the number of copies of
keys that are anywhere.)

Maybe the ADs ought liaise to some of those organisations and
ask them if they do or do not recognise the claims related to
breaking TLS being attributed to them?

Or even better, maybe just not making those claims would be
easier all around and more accurate.

S.

> 
> Thanks
> 
> -- Flemming
> 
> 
>> Thanks,
>> S.
>>
>>
>> [1]
>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
>>
>>
> 
> 



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

Re: [TLS] network-based security solution use cases

[Stephen Farrell]

Hiya,

On 07/11/17 02:48, Flemming Andreasen wrote:
>>
> We didn't draw any particular line, but the use case scenarios that we
> tried to highlight are those related to overall security and regulatory
> requirements (including public sector)

I had a quick look at the draft (will try read properly en-route to
ietf-100) and I followed the reference to [1] but that only lead to a
forest of documents in which I didn't find any reference to breaking
TLS so far at least. Can you provide an explicit pointer to the
exact document on which that claim is based?

I'd also claim that your reference to PCI-DSS is misleading, as that
same spec also explicitly calls for there to be good key management
specifically including minimising the number of copies of keys, so
at most, one might be able to claim that PCI-DSS is ok with people
who break TLS in a nod-and-a-wink manner. But if you do have a real
quote from PCI-DSS that calls for breaking TLS then please do also
send that (it's been asked for a bunch of times without any answer
being provided so far).

Thanks,
S.


[1]
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP



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

Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?

[Stephen Farrell]

Hi Joe,

On 06/11/17 01:57, Joseph Salowey wrote:
> I'm not sure what use cases you are targeting, but this type of solution
> can be dangerous for application security. Most application security models
> assume that TLS will provide both confidentiality and authenticity.
> Breaking confidentiality will often expose vulnerabilities that can result
> in escalation of privilege or spoofing resulting in a loss of
> integrity/authenticity in the application. For example, the use bearer
> tokens such as passwords or session cookies is widespread. It will take
> much more work to make applications resilient to loss of confidentiality.
> There may be use cases where confidentiality compromise is limited to just
> confidentiality, but I think these are in the minority.

I kind-of agree but not fully.

Where we agree is that any change to the basic security
services offered by TLS affect the interface between the
TLS layer and the application. Ans any changes caused by
breaking-TLS will break applications, as the existing
APIs will no longer match whatever security model was in
the application developer's mind when code was written.

We also have real-world measurements that show that TLS
APIs are frequently misused by developers in any case, so
there is little hope that some more complex API that does
reflect broken-TLS can ever be effective.

Bottom line: breaking TLS will break many applications,
regardless of how one chooses to break TLS, partly at
least because the interfaces between TLS and applications
do not envisage broken-TLS.

S.


> 
> Joe
> 
> On Fri, Nov 3, 2017 at 7:41 AM, Cas Cremers  wrote:
> 
>> Hi Richard,
>>
>> Thanks for the pointer, I had missed your earlier observation of
>> essentially the same thing in the large mail threads.
>>
>> Personally, I think it is a substantial and unmotivated loss in security
>> to also give up authentication/integrity.
>>
>> Note that any changes towards PERC would require some significant changes
>> in the security analyses; for mctls, I expect it would be a completely new
>> analysis. (I haven't seen any analyses of rhrd, but of the three, it is of
>> course closest to the current setup.)
>>
>> Best,
>>
>> Cas
>>
>>
>> On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes  wrote:
>>
>>> Hey Cas,
>>>
>>> This question is a good one.  Earlier I brought up mcTLS, which some
>>> folks have been working on to provide even more granular separations than
>>> you suggest:
>>>
>>> https://mctls.org/
>>>
>>> I think the authors of draft-rhrd are trying for a more lightweight
>>> change to TLS.  That said, there might be some intermediate points on the
>>> spectrum here.  For example, you could define a TLS ciphersuite akin to
>>> what we defined in PERC when we wanted to break integrity partly and
>>> confidentiality not at all.
>>>
>>> https://tools.ietf.org/html/draft-ietf-perc-double-07
>>>
>>> That would be less invasive than mcTLS, while still getting the
>>> properties you describe.
>>>
>>> --Richard
>>>
>>>
>>> On Nov 3, 2017 09:43, "Cas Cremers"  wrote:
>>>
>>> Dear all,
>>> ​​
>>> ​​Disclaimer: I am not a proponent of the idea behind draft
>>> visibility/green/rhrd; I think such a mechanism should not be part of the
>>> TLS 1.3 standard.
>>> ​​
>>> ​​I have a technical problem with the current design, whose goal is to
>>> allow eavesdropping for inspection, i.e., selectively decreasing
>>> confidentiality.
>>> ​​
>>> ​​However, the design in the draft also enables arbitrary traffic
>>> modification/insertion, additionally breaking all authentication and
>>> integrity guarantees. Once someone has the session keys, they can not only
>>> eavesdrop but can also start to insert/modify traffic. This additional
>>> decrease in security is entirely unmotivated by the cited use cases.
>>> ​​
>>> ​​It is possible to offer authentication and integrity, while selectively
>>> giving up confidentiality. For example, one could replace the AEAD by (i) a
>>> mechanism for authentication and (ii) a separate mechanism for
>>> confidentiality, and then possibly reveal the keys used for (ii), but make
>>> sure only the real endpoint has the keys for (i). That seems more rational
>>> to me, and may retain the authentication/integrity guarantees. However, it
>>> would require a much more invasive change.
>>> ​​
>>> ​​Best,
>>> ​​
>>> ​​Cas
>>>
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org

Re: [TLS] TLS@IETF100: Agenda Requests

[Stephen Farrell]

Hiya,

On 05/11/17 13:09, Ted Lemon wrote:
> Consensus isn't about number of votes. However, I think we can say that
> although there seems to be some interest in making sure this use case is
> addressed, there are known ways of addressing it, and little interest in
> inventing a new way that weakens a new feature of tls 1.3

Don't disagree. In addition there's always been folks in the
rough when it comes to any security BCP or similar and ISTM
that the breaking-TLS case is no different - there'll always
be people who (mistakenly IMO) perceive that it'd be better
to break TLS (and prioritise their particular concern) than
it is do our best to improve Internet security and privacy
overall. (That's one reason the chairs' question in Prague
wasn't a good one - it will always be the case that there are
IETFers who do want to break TLS and similar - we learned
nothing from that hum at all.)

As a meta-comment, I think it's really a pity that most or
all such break-TLS proposals appear to be accompanied (not
necessarily from draft authors) by bad argument, overstatement
and ignoring the existence of downsides. (*) IMO that is yet
another indicator that those arguing to break TLS know that
they're likely to end up in the rough and hence at tempted
to attempt the "hard-sell" (as you Ted I think called it,
perhaps too generously) which is I think disruptive to WG
progress.

So I'd argue to not bother discussing this bad idea again at
IETF-100 - it's consumed enough cycles already and we won't
learn anything at all if we do waste time in that way yet
again.

S.

(*) I fully admit to meeting such bad argument with robust
argument and will continue doing so:-)

> 
> On Nov 5, 2017 14:03, "Salz, Rich"  wrote:
> 
>> So if the only people in favor of it are the draft authors, then we have
>> consensus, right?
>>
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



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

Re: [TLS] Draft RHRD

[Stephen Farrell]

On 01/11/17 14:18, Salz, Rich wrote:
> In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html,
> Nick Sullivan concluded:
> 
>> - on the other hand using draft-rhrd is safer than allowing
>> organizations to hack single-key escrow into TLS 1.3 or continue to
>> use TLS 1.2 with non-forward-secret cipher suites
> 
> I think this sets up a false comparison.  Existing TLS 1.3 debugging
> systems – Wireshark – can debug individual TLS sessions with the
> session key information being made available.  This is what the RHRD
> draft would require an organization to do, but it adds the additional
> signaling that the client is willing to allow it. The Wireshark
> example shows that the signaling is not needed.  Servers can
> unilaterally do it now.
> 
> I maintain that the cleartext signal servers no useful purpose,
> except to provide a mechanism for entities to segregate traffic.

I agree. I'd also like to point out that that in no
way implies that the absence of the visible signal
is any better. As we saw with draft-green, it was not.

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] New Version Notification for draft-friel-tls-over-http-00.txt

[Stephen Farrell]

Hi Owen,

On 31/10/17 21:03, Owen Friel (ofriel) wrote:
>> Interesting. One bit puzzles me: wouldn't the new content-type
>> give the game away and cause middleboxes to block this?
>> 
>> S.
>> 
> [ofriel] The intention isn’t to try and obscure the fact that there 
> is an ATLS session. Even if that new content-type was not defined,
> it would be easy to write a simple pattern match script on the
> middlebox to identity the JSON body and leading base64 bytes of the
> TLS records in the body.

So that leaves me puzzled still, sorry.

I can't think of a situation with a middlebox that isn't ok
with the client doing proper TLS but is ok with ATLS.

Can you give an example of such a situation?

In case it helps, I can imagine that some middleboxes won't
(yet) know about this and will let it through for a while,
but that seems fairly brittle. So, I'd have thought it may
be worthwhile trying to hide what's what here if you want
it to be robust against an antagonistic middlebox or censor.
But maybe you guys analysed that already and figured it'd
not work. (Which brings me back to "puzzled":-)

Cheers,
S.


> 
> 



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

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Stephen Farrell]

Hiya,

> Hasn’t this been the whole point of the discussion?! The proposal to
> separate PRNGs into those that supply publicly-visible randomness
> (nonces, etc), and those that supply “secret” randomness (keying
> material and such)? Thus, having *two* PRNGs, each (hopefully)
> properly seeded?
> 
> I’m glad you’re now agreeing that the above is a good plan.
> 

This discussion we had back in July was mostly motivated
by dual-ec. I think it's worth noting for the record that
we now have another instance of a very similar issue. [1]

Personally I think this argues for strengthening the text
we include in TLS1.3 to a RECOMMENDATION, in the body of
the document (as opposed to Appendix C.1 where it is now)
to separate the streams of randomness along the lines
described above.

The basic change would be to move the 2nd paragraph of C.1
to 4.1.2 where Random is defined, maybe to add a reference
to DUHK, and to insert a statement that implementers are
RECOMMENDED to put in place such separation. (I don't think
we need to say how they ought do that, as it's quite OS/RNG-
implementation dependent.)

I wonder if the new information (i.e. DUHK) convinces folks
that such a change is warranted?

If so, great. I'd be happy to submit a new PR or we could
re-open [2] or whatever. (I'd be just as happy that the
editor figure out the precise wording if that's easier.)

If not, I don't we need to debate this again, nor do we need
to hold up TLS1.3.

If the answer to the above isn't clear from the list between
now and the IETF meeting it might be worth asking the room
about this in Singapore if time permits.

Cheers,
S.

[1] https://duhkattack.com/
[2] https://github.com/tlswg/tls13-spec/pull/1068




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

[Stephen Farrell]

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, I disagree with some aspect's of Nick's analysis, which
we can go into as needed. I don't think that's needed in this mail.

On your second point...

The IETF has a range of policies (BCPs etc) that call for use of
strong and not-weakened cryptography in protocols. Some of that
is mentioned in places at [1] but I'm sure a more complete job
could be done. There are sound technical reasons why the IETF has
consensus on a bunch of those positions. For some of those, it
is also true that the consensus has always been rough, e.g. I
think it's true there have always been IETFers who would actually
like to MitM security protocols for what they consider good
reasons. (That doesn't make those people either bad or correct.)

One particular relevant RFC (2804) does explicitly envisage that
people who want to do snooping might document their ways of doing
that in independent stream RFCs (which are not IETF RFCs despite
almost no RFC-readers grokking any difference there;-). But in
this case the authors say they want standards-track. And in the
previous case, from talking with Russ, he didn't see any benefit
in the independent stream route (which I didn't understand at the
time tbh).

So the situation is actually sort-of clear, but not simple. It's
true that appreciating the clarity requires quite a bit of IETF
lore ;-)

S.

[1] https://github.com/sftcd/tinfoil




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

[Stephen Farrell]

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 fight, but let's please be accurate.

Accuracy level is just fine I think.

S.

Network Working Group R. Housley
Internet-DraftVigil Security
Intended status: Standards TrackR. Droms
Expires: April 2, 2018  Interisle Consulting
  September 29, 2017


 TLS 1.3 Option for Negotiation of Visibility in the Datacenter
   draft-rhrd-tls-tls13-visibility-00



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

[Stephen Farrell]

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
to acquiesce to bad ideas in the name of finding common ground.
The IETF is not that kind of SDO (at least I hope not).

When a thing is a sufficiently bad idea, then it is not a good
plan to try meet it half-way. That is the case with the basic
idea here.

So, sorry, no - compromise is not a goal.

OTOH, investigating non-damaging means of meeting data centre
requirements that do not involve TLS is an entirely fine thing
to do IMO. (Though maybe not the oft-quoted but *never* so far
substantiated claims related to PCI;-).

I would encourage you and others to go do that. If that calls
for the development of a new multi-party security protocol
that can be used in such environments, that is also just fine
and could have other interesting uses.

One could also do work to try make it easier for sites to
evolve towards use of (closer to, but not, perfect) forward
secrecy.

But breaking TLS is very different to both and is not fine.

S.




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

[Stephen Farrell]

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
> server) chooses to provide the contents of the communication to some
> other entity. draft-rhrd-tls-tls13-visibility doesn't change that.

The above is nonsense. The draft in question clearly proposes
fundamentally changing the feature set of TLS to include snooping
as a standard, supported feature.

> But, I'm tired of the abusive
> and false suggestions that draft-rhrd-tls-tls13-visibility is a
> "wiretapping" draft or that it is defining a "please-screw-me
> extension." 

Abusive of what/whom? The truth or falsity of the wiretapping
description is a matter for debate. (Russ' argument that these
are not witetapping features is one I find to be lawyerly nit
picking based on a partial reading of 2804, but I believe he
does believe that.) I'm fine that you ignore that there are
other opinions.

I also don't really care if the proponents of snooping as a
standard feature get tired to their ideas being criticised to
be honest. I am, and will remain, available to offer such
criticism.

And FWIW, I consider the use of euphemisms like "passive" or
"visibility" here to be deceptive. Perhaps not deliberately
deceptive, (I'm not saying the authors of the draft are trying
to deceive), but nonetheless I find such abuses of language
far more irritating than the occasional bit of robustness in
debate. Such euphemisms are also more long-term damaging IMO.

This draft and the one before it are proposing supporting an
active attacker in the middle of TLS sessions and that is how
we ought be discussing this, not as some pretend passive
good-natured observer capability.

S.



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

[Stephen Farrell]

David,

I'll go back over your mails tomorrow but was struck by this...

On 24/10/17 23:39, David A. Cooper wrote:
> I haven't even gotten into the question of what does it mean for a connection 
> to 
> be MiTM'd. If Company X decides to have its web site operated by Hosting 
> Provider Y is the connection between the client and Company X being MiTM'd? 
> The 
> client might think it has a secure end-to-end connection with Company X, but 
> in 
> reality its data is being intercepted and read by Hosting Provider Y, without 
> the client's permission (and most likely without the client's knowledge). How 
> does TLS, currently, prevent this? Why isn't anyone demanding that TLS cannot 
> be 
> standardized until it can be proven that such a scenario is impossible?

That strikes me as an incredibly nihilist approach you
(or NIST?) appear to be espousing, which is surprising.

As a question back to you: would it be ok if NIST were
to reinstate Dual-EC? If not why not? After all, (based
on the above), all that'd happen is someone could do
stuff that everyone knows (since 2008) can happen. (And
no, with the current draft, the client does NOT know who
the snooper is - it could be the NSA or the FSB and the
client can't tell - and all that was already discussed
on the list.)

I suspect you'll say that it's better that NIST do not
add Dual-EC back, (and I agree) because we're better off
with honest crypto. And the same is true of TLS - it's
a 2 party protocol and adding additional parties breaks
all the trust models based on TLS. So it'd be equally
good if NIST didn't espouse breaking TLS, at least IMO.

If you can show me where you (or NIST or anyone) analysed
all of the uses of TLS to check that there are no bad side
effects, I'll be interested in reading that analysis. In
the meantime, your personal evaluation of your risk is not
something that I find convincing, sorry.

S.



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

[Stephen Farrell]

Michael,

What, in your message below, has not been said a number
of times in this thread? (And countered effectively IMO.)
I don't see anything - repeating points already countered
is just disruptive noise, sorry.

Thanks,
S.

On 25/10/17 01:41, Ackermann, Michael wrote:
> Excellent points/questions and I just wanted to add that your final example, 
> regarding  hosting providers actually being a MitM,  is EXTREMELY prevalent 
> in Enterprises today and is a management/ monitoring issue specifically 
> pointed out by Steven Fenter in his presentation to the TLS WG in Prague.
> Without the ability to decrypt these sessions our ability to 
> manage/monitor/secure is severely reduced.
> And TLS, being a point to point protocol,  cannot help in its current form.
> 
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David A. Cooper
> Sent: Tuesday, October 24, 2017 6:39 PM
> To: tls@ietf.org
> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
> 
> On 10/24/2017 05:18 PM, Salz, Rich wrote:
> 
> 
>   *   And, I don't buy the idea that if this extension is standardized that 
> it will be implemented in commonly-used browsers.
> 
> And that is a risk you are willing for the entire public Internet to take?
> 
> I'm not taking any risk.  The ability for a server to allow a third party to 
> have access to data it is exchanging with a client already exists, and that 
> ability isn't going away whether this proposal (or something similar) is 
> standardized or not. As I've already pointed out, for the scenarios people 
> are concerned about, the "attacks" being described would be much more easily 
> carried out by some means other than draft-rhrd-tls-tls13-visibility.
> 
> So, no I am not worried about the "risk" of creating a complicated way for 
> servers and middleboxes to collude to do something that they can already do 
> now in a simpler way.
> 
> 
> And what about the fact that it provides a cleartext signal as to whether or 
> not a client is willing to let itself be MiTM’d, does that bother you?
> 
> No. As I noted before, servers can already allow middleboxes to MiTM 
> connections with clients with asking the client's permission. Public facing 
> servers that want to allow this (even if as a result of coercion) won't use 
> this extension. They'll just enable it without informing the clients.
> 
> There are also other ways a server could allow a middlebox to MiTM the 
> connections that it has with clients that don't require the client's 
> cooperation (or knowledge) and that wouldn't require any changes on the 
> client side; ways that would be easier than trying to use 
> draft-rhrd-tls-tls13-visibility.
> 
> If the only way (or the easiest way) these connections could be MiTM'd 
> required getting clients' permission, then this might be a concern, I don't 
> see servers that want to (or are coerced into) allowing connections to be 
> MiTM'd asking clients whether they are willing. Given this, we aren't going 
> to see browsers that are configurable to signal that the client is willing to 
> "allow" the connection to be MiTM'd.
> 
> I haven't even gotten into the question of what does it mean for a connection 
> to be MiTM'd. If Company X decides to have its web site operated by Hosting 
> Provider Y is the connection between the client and Company X being MiTM'd? 
> The client might think it has a secure end-to-end connection with Company X, 
> but in reality its data is being intercepted and read by Hosting Provider Y, 
> without the client's permission (and most likely without the client's 
> knowledge). How does TLS, currently, prevent this? Why isn't anyone demanding 
> that TLS cannot be standardized until it can be proven that such a scenario 
> is impossible?
> 
> 
> 
> 
> 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
> 



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

[Stephen Farrell]

On 24/10/17 20:31, Ted Lemon wrote:
> But it's delaying other work, because people who could be doing
> useful work in the IETF are engaging on this topic instead.
I'm not sure of the extent to which my work in the IETF is
useful or not, but it is certainly the case that these
repeated proposals have consumed the cycles I have for that
work. As both Ted and Ben have said this I know I'm not
alone in that, and the volume of mail on the topic alone
shows that others are spending valuable time rebutting the
ongoing break-TLS show.

Whether or not any of us would have contributed to TLS1.3 or
DTLS1.3 being done sooner or better instead is another question,
but the real linkage to TLS1.3 here is that if any of these
bad ideas did achieve more that forcing us to oppose them, and
the WG went mad and adopted any of it, then that would surely
and fully muck up TLS1.3 and DTLS1.3, both in terms of timing
and I believe in terms of utility. (Who'd want a new TLS version
that's designed as broken?)

S.



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

[Stephen Farrell]

Ralph,

On 24/10/17 20:36, Yoav Nir wrote:
> 
> 
>> On 24 Oct 2017, at 22:27, Ralph Droms  wrote:
>>
>>
>>> On Oct 24, 2017, at 3:23 PM, Salz, Rich  wrote:
>>>
>>> I use an airplane as an example of a “captive” population, substitute any 
>>> similar group you want.
>>>
>>> • Yes, any box that sits between the client and the server can drop 
>>> traffic for whatever reason it wants. Such a box could today drop any 
>>> traffic that is protected using TLS.
>>>
>>> True, but that’s not the point.  The point is by adding this extension into 
>>> the clientHello, we are providing middleboxes with another knob to control 
>>> traffic.  I think we want to avoid that. And keep in mind it’s not just 
>>> HTTP, but *any* TLS-using traffic, such as many VPN’s.  It wouldn’t 
>>> necessarily enable spying, but it could be used to guarantee that all 
>>> traffic is amenable to spying.
>>>
>>> As for how would such clients get promulgated?  Some simple scenarious 
>>> include “surf for free on your flight, but use our Chromium-based browser 
>>> to do so, available for free here.”How many people on the plane would 
>>> click and download?
>>
>> Just to make sure I understand, in this scenario the special-purpose browser 
>> could just as easily, today, be a browser with no TLS at all?   That is, I 
>> don't see why this scenario is specific to the visibility extension.
> 
> Think of the children.
> 
> We can’t just let them loose on the Internet, there’s predators out there. So 
> we will snoop on their traffic.  To do that, we block all traffic that isn’t 
> snoopable, and we do it at the edge router in schools.  All schools in our 
> state are required by law to install a firewall that does this. And we get 
> the mobile operators to do so as well (only for handsets in schools).
> 
> Now either the mobile OS vendors make a browser that works in schools (at 
> least with a setting), or the school recommends a third party browser that 
> works in school. And best of all, this is *more secure* than regular TLS 1.3, 
> because it also protects your children from Internet predators. Think of the 
> children.
> 
> You can’t make a claim like that for an HTTP-only browser, and worse still, 
> it won’t work on much of today’s Internet.

Just to note that the only substantive difference between
draft-green and this is the please-screw-me extension in
the ClientHello and Yoav's argument above (with or without
all the obvious corollaries/variations) destroys that as
a defence for your latest effort to square this circle. (This
has been stated at least a couple of times/ways already.)

If you Ralph or Russ have some new arguments for your draft
that have not been countered already or wrt draft-green
then I wish you would raise those, because I've not seen any
that have survived. And if you have no such arguments then
I think it'd be a fine thing to admit that truth openly.

The underlying idea remains as bad as ever, for all the
reasons I tried to summarise at [1] (to which I'll add Yoav's
description above when I get a chance as it's a nice
illustration).

S.

[1] https://github.com/sftcd/tinfoil

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

[Stephen Farrell]

Joe,

On 24/10/17 17:49, Joseph Salowey wrote:
> As is normal
> IETF practice, we will be giving this topic agenda time in Singapore to see
> if a consensus emerges one way or the other.

I would ask that you, as chairs, reconsider that. While I
do have strong opinions, the list traffic seems to me to
have been extremely clear on this draft and on this overall
topic. Personally, given recent traffic, and the clear lack
of consensus to even discuss the basic proposition of snooping,
I can't see agenda time for this as being other that a waste
of time. (Again.)

S.



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

[Stephen Farrell]

Sean/Joe, this is addressed to you...

On 24/10/17 00:31, 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.

So from the above we see that some of the proponents of
breaking TLS demonstrate a breathtaking ignorance of what
they are espousing. After 18 months of this WG dealing
with the "I want my static RSA" pony, I personally think
we are justified in demanding more from those who've been
actively engaged for some time in trying to break TLS and
therefore we ought consider postings such as the above,
or ones containing blatantly false/exaggerated statements
(e.g. about "guarantees" or "using TLS1.2 forever") as
being merely disruptive.

So in addition to asking you as chairs to close down this
discussion, I would also ask that you contact the folks
being disruptive like that and try to educate them as to
how to behave in IETF discussions and also let them know
about the IETF's processes for dealing with disruptive
postings.

Thanks,
S.

PS: Your (chairs') silence on the repeated requests to
close down this discussion is quite puzzling to me.

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



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

[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

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

[Stephen Farrell]

Hi Ted,

On 23/10/17 00:35, Ted Lemon wrote:
> On Oct 22, 2017, at 7:26 PM, Steve Fenter 
> wrote:
>> I have been saying to anyone who will listen that the IETF needs a
>> private forum for enterprises, to enable them to come forward and
>> discuss their real requirements. Without this input the IETF is
>> trying to architect and engineer solutions without knowing the
>> complete set of requirements, at least on the enterprise side.
>> This results in sub-optimal design decisions (from an enterprise
>> perspective), which in this case will break mission critical
>> enterprise monitoring and troubleshooting systems.
> 
> The reason we don't have that is that designing secure protocols in
> secret isn't a trustworthy approach.   Of course, you can always get
> together privately.

Well, to be fair, that ask - for (literally!) secret handshakes
does explain one part of this debacle that has puzzled me so far.
We've seen the following interactions:

snooping-proponents: "we need snooping, because "
others: "that has all sorts of bad side-effects, e.g. A,B,C..."
...
...silence from snooping proponents...

The ask for secrecy I think demonstrates that the silence in
response to explanations of derived demonstrable damage is not
due to a lack of understanding, but must be down to caring
only about one's own "constituency" and not at all about the
Internet more broadly.

I think I now understand some of this better (but deplore it
more), but am left more puzzled as to the what it was that
inspired draft-rehired authors.

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

[Stephen Farrell]

On 22/10/17 21:48, Steve Fenter wrote:
> The main problem with not addressing the TLS visibility issue now is
> that no one knows when a vulnerability will be discovered in TLS 1.2
> that forces enterprises to upgrade to TLS 1.3. We've had guarantees
> that TLS 1.2 and the RSA key exchange are going to be fine for 5 to
> 10 years, but nobody knows that, particularly in today's security
> environment. I've also learned that getting a solution in place
> through the IETF is a multi-year process, and then vendor adoption
> time has to be added on top of that.  Enterprises don't want to be
> caught in a position where a vulnerability is forcing us to upgrade,
> and we are starting at ground zero on a multi-year process to restore
> TLS visibility. We have to get out in front of this problem so we're
> not caught unprepared.

Wait. What?

One of your arguments for needing snooping is that you
claim a lack of competence in debugging applications that
use TLS.

So to solve that, you propose we introduce a rarely used,
sporadically supported method of leaking keys to third
parties. IOW, you add what's called a vulnerability and
do so in a complex manner in code paths that'll hardly
ever be used (according to the proponents, they'll only
be used in the "proper" places, or at least, none of you
have so far ever acknowledged the falsity of that "proper"
places magical thinking).

Rarely used complex code for leaking keys... hmm, now
what is that likely to lead to? Oh yes, bugs.

But now you claim that a well tested protocol with fairly
mature implementations (TLS1.2) might have bugs that cause
you to need to add your additional complex key-leaking
vulnerability feature which'll magically have no bugs?

I think you can fairly claim a worst argument of the year
prize for that one;-)

S.

PS: Your claim about "guarantees" is just false afaics. I
saw no such thing on the list. Please desist from inventing
statements that were not made, or point me at where someone
said something that is even remotely possible to confuse
with such a guarantee. (Combining risible argument and false
claims really isn't wise.)


> 
> Sent from my iPad
> 
>> On Oct 20, 2017, at 11:57 AM, "Salz, Rich" 
>> wrote:
>> 
>> 
>> 
>> 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.
>> 
>> 
>> 
>> ___ 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] Connection ID Draft

[Stephen Farrell]

On 22/10/17 17:04, Eric Rescorla wrote:
> On Sun, Oct 22, 2017 at 8:50 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie>
> wrote:
> 
>>
>>
>> On 22/10/17 16:41, Eric Rescorla wrote:
>>>
>>>> Maybe the thing we could agree at this stage is that the cid scheme
>>>> has to be usable in that one-message-per-day scenario and needs to
>>>> provide some way that such messages aren't easily linkable based on
>>>> cids.
>>>
>>> I think that's a requirement in some cases but not others. It might be
>>> best to settle for the others.
>>
>> Sorry, I'm not sure what you mean there. Are you saying that you think
>> the above requirement can't be met by a generally usable scheme?
>>
>> I agree that not all scenarios need to meet the req posited above.
>>
>> I'd worry that if DTLS1.3 can't meet the above requirement then folks
>> will invent something that does, which may be worse than using DTLS
>> in a bunch of cases. OTOH, one could equally, and maybe fairly, argue
>> that DTLS really doesn't scale down quite that far, which'd I guess
>> argue that there's a need for some other security protocol for those
>> situations.
>>
> 
> It's not a matter of DTLS versus non-DTLS. 

Not sure tbh, ISTM there's a bunch of challenges in trying to
use the kind of lpwan technologies being developed with DTLS,
with cid just being one of those. But time will tell I guess,
and that's a different discussion.

> I am unaware of any method
> of providing conn-IDs that simultaneously meets the requirements of:
> 
> - Unlinkability
> - Being able to survive multiple conn-ID changes in one round-trip
>   (which is implicit in both the one-packet per day and the unknown
>   address changes scenarios)
> - Low bandwidth
> - Good receiver-side scaling (both state and computational)
> 

Fair enough - I can buy that the last above suffers when one tries
to satisfy all the rest. Maybe that means a WG draft ought have an
applicability statement section that captures the scenarios where
that particular cid extension is suitable.

I'll be sad though if the end result is to sacrifice unlinkability
which I fear will be the likely outcome in practice.

> This is a generic problem, not one limited to DTLS. And as I said earlier,
> to the extent to which we either need specific schemes that meet different
> subsets of these requirements or we come up with a better generic scheme,
> the extension-based approach accommodates it.

Again, maybe some applicability text as per the above would make
it clearer that the draft is describing one (though hopefully the
most commonly useful) scheme and that others may be needed in
other situations.

Cheers,
S.

PS: In case it helps, with the additions discussed earlier and
above, and with the understanding that exploring other cid schemes
for cases where this one isn't fully satisfactory isn't ruled
out, I think this draft would be a fine starting point for a WG
document.


> 
> 
> PS: I fully accept your point that purely napkin-based schemes aren't
>> good enough and if those're the only kind of hash-chain based proposals
>>
> seen, then the WG oughtn't go for one of those.
>>
> 
> We've seen others, and they fail the receiver-side scaling test, IMO
> 
> -Ekr
> 



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

Re: [TLS] Connection ID Draft

[Stephen Farrell]

On 22/10/17 16:41, Eric Rescorla wrote:
> 
>> Maybe the thing we could agree at this stage is that the cid scheme
>> has to be usable in that one-message-per-day scenario and needs to
>> provide some way that such messages aren't easily linkable based on
>> cids.
> 
> I think that's a requirement in some cases but not others. It might be
> best to settle for the others.

Sorry, I'm not sure what you mean there. Are you saying that you think
the above requirement can't be met by a generally usable scheme?

I agree that not all scenarios need to meet the req posited above.

I'd worry that if DTLS1.3 can't meet the above requirement then folks
will invent something that does, which may be worse than using DTLS
in a bunch of cases. OTOH, one could equally, and maybe fairly, argue
that DTLS really doesn't scale down quite that far, which'd I guess
argue that there's a need for some other security protocol for those
situations.

S.

PS: I fully accept your point that purely napkin-based schemes aren't
good enough and if those're the only kind of hash-chain based proposals
seen, then the WG oughtn't go for one of those.




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

Re: [TLS] Connection ID Draft

[Stephen Farrell]

(Sorry for the slow response...)

Two things below...

On 13/10/17 16:58, Eric Rescorla wrote:
> On Fri, Oct 13, 2017 at 7:52 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie>
> wrote:
> 
>>
>> Hiya,
>>
>> On 13/10/17 15:29, Eric Rescorla wrote:
>>> There are a number of cases where this is actually much harder to
>> implement
>>> than a design where one side dictates the connection ID. For instance,
>>> consider a design where you have a pool of servers P1, P2, ... P_n with a
>>> load balancer in front.
>>> Each server i generates connection IDs of the form i || Random. The load
>>> balancer then just looks at the first byte and routes to the appropriate
>>> load balancer [0]. In this design, the LB can be totally stateless,
>> whereas
>>> in the design you propose, it has to (a) have a back-channel to the
>> server
>>> to get the initial conn-id (b), do crypto (c) store state for all the
>> live
>>> connections.
>>
>> Pre-pending a fixed length (known to both sides) load-balancer
>> ID would be fine, sure. That'd change the function to something
>> like:
>> next-id = lb-id || H(foo||prev-id)
>>
>> So long as each load balancer is busy enough that still has the
>> hard-to-link property I think. The length of the lb-id could be
>> fixed or part of the negotiation, with zero being a fine length
>> when there's no lb-id needed.
>>
> 
> Well, this is a lot more complicated for the client and unless you place
> very strict limits on lb-id, it ends up with the server just dictating an
> identifier to the client so you have the scheme in this draft.
> 
> 
> 
>> I think this'd work ok regardless of who controls the initial id
>> value, so long as we don't need ids to work like tickets (where
>> the id value would be the ciphertext of some state info).
>>
> 
> That's actually a design that people consider quite often and has been
> discussed
> for QUIC.

So, if the WG want to allow for such designs, then I think that'd
be better explicitly stated as some level of requirement, e.g. to
say that some aspect of the scheme needs to allow some cids to be
an encrypted form of something else. (I do think allowing for such
is quite reasonable.)

>> In addition, consider what happens when you get a CID you don't recognize.
>>> It might be nonsense but it might be that there was a cryptic CID change
>>> (e.g., the client did two changes but you missed a packet). You need to
>>> decide the number of changes you're willing to tolerate and then the
>> table
>>> has to be that big times the number of connections (or you need to fill
>> it
>>> in whenever you get an unknown CID, which the attacker can send you at
>> any
>>> time).
>>
>> Yes, schemes like this can be worse when packets go missing
>> around the time of an id change.
>>
>> However, I think with this scheme (which isn't even on a napkin
>> yet, just these mails:-),
> 
> 
> Sure but we contemplated a number of these designs for QUIC, so we're not
> starting from scratch here.
> 
> 
> 
> 
>> he sending side would just make the
>> change when they want, and wouldn't signal that it's changed the
>> id. So, in some cases (say if receivers store current and next,
>> and id changes and packet losses are infrequent) a single packet
>> drop would be just that and the id change wouldn't affect things
>> at all. In the putative nb-IoT case I mentioned before then it
>> could be a good bit worse unless the receiver stores a bunch of
>> future ids. (I agree some work is needed to figure out if there's
>> an acceptable scheme here, so for now I'm arguing that we not
>> preclude such schemes when adopting your draft.)
>>
>> In figuring this out, I'd argue that we ought be comparing ideas
>> like this against two things: 1) the simplest solution that does
>> allow linkabillity and 2) the costs of setting up a new TLS
>> session to avoid linkability. While this or similar schemes will
>> look bad compared to (1), they will likely look pretty good
>> compared to (2).
>>
>> Of course, how one evaluates such comparisons will depend on how
>> serious a threat one considers linkabillity. I'd argue that many
>> devices that'll need connections ids will be devices where the
>> possibility of linkability could be a significant threat and where
>> new TLS session establishment will be rare, so we therefore ought
>> provide some good method of avoiding linkability.
>>
> 
> I'd say three things here:
> 
> 1. First, as I said 

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

[Stephen Farrell]

On 20/10/17 17:00, Ackermann, Michael wrote:
> Expressly reacting to the viability of continuing to use TLS1.2 forever.

Sorry, that's just misquoting.

Rich asked "why do the WG need to debate this now"
Darin said "we must, because we need snooping..."
I said "no, you can use TLS1.2 and debate this after
TLS1.3 is done."

That is nothing like saying "use TLS1.2 forever."

Please don't misquote like that.

S



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

[Stephen Farrell]

Minor clarification...

On 20/10/17 14:44, Salz, Rich wrote:
>  Some members of the WG rose up and wanted explicit opt-in

I don't think "wanted" is quite right. Some
WG participants (e.g. me) wanted nothing like
this to ever be done in the IETF. Others did
comment that the lack of client opt-in was a
bad aspect of draft-green, but I'm not sure
that anyone clearly said "I do want draft-green
snooping, but with client opt-in."

S.



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

[Stephen Farrell]

I agree with Christian and Ben's points. I'd also add:

On 19/10/17 23:30, Darin Pettis wrote:
> The question has been raised: "Why address visibility now?"   The answer is
> that it is critical that the visibility capability is retained.  It is
> available today through the RSA key exchange algorithm. 

That yet again ignores the fact that TLS1.2 will continue to
be available, which utterly undermines your argument that we
need to disrupt the work on TLS1.3 with this divisive debate

S



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

[Stephen Farrell]

On 19/10/17 15:16, Paul Turner wrote:
> 
> 
>> -Original Message-
>> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
>> Sent: Thursday, October 19, 2017 09:07
>> To: Benjamin Kaduk <bka...@akamai.com>; tls@ietf.org
>> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
>>
>>
>> Hiya,
>>
>> On 18/10/17 18:41, Benjamin Kaduk wrote:
>>> P.S. I agree with Rich; can we try to defer these conversations until
>>> after 1.3 is actually published?
>>
>> FWIW, I also think it'd be a good plan if the chairs did that. I'm happy to
>> oppose these ideas any time, but later is better than now, given this would
>> further distract us from 1.3.
> 
> I don't think this is a good plan.

Why exactly? What here is so urgent that it needs
to be haggled over before TLS1.3 is done?

TLS1.3 is the major work item for which this WG is
chartered, and breaking TLS is something that is
outside this WG's charter entirely.

I think you'd need a very good argument that any WG
ought prioritise out-of-scope work at the expense
of the main goal of the WG.

S.


> 
>>
>> S.
> 



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

[Stephen Farrell]

Hiya,

On 18/10/17 18:41, Benjamin Kaduk wrote:
> P.S. I agree with Rich; can we try to defer these conversations until
> after 1.3 is actually published?

FWIW, I also think it'd be a good plan if the chairs
did that. I'm happy to oppose these ideas any time,
but later is better than now, given this would further
distract us from 1.3.

S.



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

[Stephen Farrell]

On 17/10/17 19:34, Ion Larranaga Azcue wrote:
> If the extension is not sent, the client does not realize there is a
> third party, but the third party does not have the session keys
> either, and the server has to provide them in a different way (for
> instance, using an OOB lookup as Florian suggested). In any case,
> it's not the same scenario as the draft proposes (the keys are shared
> in a different way) and can happen with or without this draft being
> accepted.
I agree.

My point is that if this draft were accepted, then the
infrastructure for the above scenario would all be in
place (the DH value for the snooper and the code to expose
session information to that snooper) and the above
scenario would be more likely to happen, more often.
IOW, by standardising draft-rehired, we'd *also* be
putting in place standard building blocks for an OOB,
client is never told mechanism.

S.



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

[Stephen Farrell]

On 17/10/17 16:46, Ion Larranaga Azcue wrote:
> The problem I see with a "server to third party" OOB look up or
> export of the keys is that the client will not be notified of this
> export taking place and so will lose the chance to reject
> surveillance...
IIUC, with the draft-rehired proposal, the client
can in any case not be told - the TLS protocol
extensions are mere politeness and the client does
not get to know what snooper(s) are involved, nor
can the client influence the snooping keys. Once,
any infrastructure for this was deployed, I think
it'd be used without telling clients for sure. (And
we would be fully complicit in helping that happen,
if the WG adopted this stuff, because we know that
such abuses would be inevitable.)

I think this WG was correct years ago when we
passed on the DNT proposal which had the same
"just politeness" aspect - the web is not really
such a friendly place that one can depend on the
kindness of strangers. Nor are many of the many
other applications using TLS.

S.



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

[Stephen Farrell]

Hiya,

On 13/10/17 17:28, Hubert Kario wrote:
>> So I think this ends up as bad as the design in draft-rehired. Which
>> of them is more obviously bad is another question.

> "draft-rehired"?

Apologies. That's how I've been verbalising/pronouncing
draft-rhrd. (*) I think it is useful to have a name that
can be pronounced, and I refuse to abuse language and talk
about this as if "visibility" was even an approximately
correct term;-)

S.

(*) I do have a weak justification:-)

$ grep "^r.h.r.d" /usr/share/dict/words
rehired
$





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

Re: [TLS] Connection ID Draft

[Stephen Farrell]

Hiya,

On 13/10/17 15:29, Eric Rescorla wrote:
> There are a number of cases where this is actually much harder to implement
> than a design where one side dictates the connection ID. For instance,
> consider a design where you have a pool of servers P1, P2, ... P_n with a
> load balancer in front.
> Each server i generates connection IDs of the form i || Random. The load
> balancer then just looks at the first byte and routes to the appropriate
> load balancer [0]. In this design, the LB can be totally stateless, whereas
> in the design you propose, it has to (a) have a back-channel to the server
> to get the initial conn-id (b), do crypto (c) store state for all the live
> connections.

Pre-pending a fixed length (known to both sides) load-balancer
ID would be fine, sure. That'd change the function to something
like:
next-id = lb-id || H(foo||prev-id)

So long as each load balancer is busy enough that still has the
hard-to-link property I think. The length of the lb-id could be
fixed or part of the negotiation, with zero being a fine length
when there's no lb-id needed.

I think this'd work ok regardless of who controls the initial id
value, so long as we don't need ids to work like tickets (where
the id value would be the ciphertext of some state info).

> 
> In addition, consider what happens when you get a CID you don't recognize.
> It might be nonsense but it might be that there was a cryptic CID change
> (e.g., the client did two changes but you missed a packet). You need to
> decide the number of changes you're willing to tolerate and then the table
> has to be that big times the number of connections (or you need to fill it
> in whenever you get an unknown CID, which the attacker can send you at any
> time).

Yes, schemes like this can be worse when packets go missing
around the time of an id change.

However, I think with this scheme (which isn't even on a napkin
yet, just these mails:-), the sending side would just make the
change when they want, and wouldn't signal that it's changed the
id. So, in some cases (say if receivers store current and next,
and id changes and packet losses are infrequent) a single packet
drop would be just that and the id change wouldn't affect things
at all. In the putative nb-IoT case I mentioned before then it
could be a good bit worse unless the receiver stores a bunch of
future ids. (I agree some work is needed to figure out if there's
an acceptable scheme here, so for now I'm arguing that we not
preclude such schemes when adopting your draft.)

In figuring this out, I'd argue that we ought be comparing ideas
like this against two things: 1) the simplest solution that does
allow linkabillity and 2) the costs of setting up a new TLS
session to avoid linkability. While this or similar schemes will
look bad compared to (1), they will likely look pretty good
compared to (2).

Of course, how one evaluates such comparisons will depend on how
serious a threat one considers linkabillity. I'd argue that many
devices that'll need connections ids will be devices where the
possibility of linkability could be a significant threat and where
new TLS session establishment will be rare, so we therefore ought
provide some good method of avoiding linkability.

Cheers,
S.






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

Re: [TLS] Connection ID Draft

[Stephen Farrell]

Hiya,

On 13/10/17 14:56, Eric Rescorla wrote:
> I've seen a number of designs like these, but in general they
> have quite poor scaling properties. Can you describe the precise
> design you have in mind so that we can analyze it.

Sure, I can try...

What I'm suggesting is that we define a way that a TLS
node can change the connection ID to a new value that
is hard to link to the old, as a function that can be
used when the implementation chooses to use it.

I'm not currently arguing that the ids should be changed
for each packet. E.g. if a node is able to detect that the
5-tuple has just changed, it could use this then. If a
node sends one packet per day over say an nb-IoT network
where it might have a different IP address each time (not
that we know how nb-IoT will operate, so I'm guessing:-)
then it might make sense to do this for every packet.

I assume ids are initialised in some reasonable way.

To change an id, pick a value foo that depends on the TLS
session, e.g. like an extractor, and that is not visible
to the network. Then set next-id to H(foo||prev-id) or
some similar construct.

Receivers can store a set of ids calculated when the
session is established. I'd guess storing two (current
and next) might be a sensible thing to do.

The inefficiently compared to simply incrementing the
id value is to add another column to the lookup table I
guess. I don't know if that's a big scaling deal or not.

Cheers,
S.



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

Re: [TLS] Connection ID Draft

[Stephen Farrell]

On 13/10/17 00:13, Eric Rescorla wrote:
> Hi folks,
> 
> I have just posted a first cut at a connection ID draft.
> https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
> 
> Comments welcome.

As a near-nit, I don't think "dismissed" is a good way
to describe the analysis of some of the ideas that came
up earlier.

In particular, I still think there's merit in some use
of a hash chains, to decrease linkability, even if that's
not done for every packet.

For example, considering a client that might detect an
occasional change of 5-tuple, it could use something like

   id_n=H(foo||id_(n-1)) where foo is something dependent
   on the TLS session secrets (exporter-like)

That way the TLS stacks can pre-calculate the next id
(or a bunch of those) and then only lookups are needed
(though the tables are bigger of course) just as with a
static connection id.

I'd argue that such designs not be dismissed.

I accept that the design needs to end up being efficient
enough to get used but I don't think that we need to go
for the simplest possible design, if that exposes 5-tuple
linkages in ways that setting up new TLS sessions would
not.

Cheers,
S.


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

[Stephen Farrell]

On 13/10/17 12:05, Hubert Kario wrote:
> On Thursday, 12 October 2017 15:16:08 CEST Stephen Farrell wrote:
>> (With the obvious caveat that I hate the whole
>> idea... :-)
> 
> to be clear: me too

IMO the more we hear of that the better

> 1. Alice sends a share to Bob: g^a
> 2. Bob sends Alice's and his share to Carol: g^a, g^b, g^ab
> 3. Carol replies to Bob with her share added to Alice's and his: g^ac, g^bc
> 4. Bob sends the Carol's reply to Alice as a Server Key Share: g^bc
> 5. Alice calculates the shared secret g^bca
> 6. Bob calculates the shared secret: g^acb
> 7. Carol calculates the shared secret: g^abc
> 
> so it doesn't look to me like it requires a lot of chamfer to fit that square 
> peg in the round hole, only the 2 and 3 need to happen out-of band.
> 
> of course, I haven't analysed how Carol would be authenticated in that 
> communication (if signing just the SKS by Carol is enough, transferred in the 
> encrypted extensions, with server signature of the handshake in certificate 
> verify being sufficient for integrity)

So the problems with that are numerous but include:

- there can be >1 carol, (and maybe all the carols also need to
  "approve" of one another), if we were crazy enough to try do
  this we'd have at least:
  - corporate outbound snooper
  - data-centre snooper (if you buy those supposed use-cases)
  - government snooper(s) in places where they don't care about
doing that openly
  ...port 80 would suddenly be quicker than 443 again;-(
- carol is quite likely to only have a name like: 2001:db8::bad:1dea
  or your.friendly-listener.bigcdn.example.net and authenticating
  those is essentially meaningless to the endpoints in most TLS contexts
  whether or not those endpoints have humans associated with them
- the TLS endpoints can't handle the semantics of allowing in Carol(s)
  as those endpoints were designed to use TLS and not bolloxed-TLS (be
  that mcTLS or draft-rehired)

So I think this ends up as bad as the design in draft-rehired. Which
of them is more obviously bad is another question.

Cheers,
S.





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

Re: [TLS] draft-rhrd (Was: Re: Update on TLS 1.3 Middlebox Issues)

[Stephen Farrell]

I did a bit of an update to [1].

As before PRs are welcome and I (still) wonder if the
WG would benefit from documenting bits of this stuff
as a work item to save time and repetition in future.

S.

[1] https://github.com/sftcd/tinfoil

On 08/10/17 23:35, Blumenthal, Uri - 0553 - MITLL wrote:
> +1 to Stephen.
> 
> Regards,
> Uri
> 
> Sent from my iPhone
> 
>> On Oct 8, 2017, at 18:34, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
>>
>>
>>
>>> On 08/10/17 23:22, Eric Rescorla wrote:
>>> You seem to be responding to some other thread. 
>>
>> Yep. I changed the subject line.
>>
>> Randy's substantive message however is crystal clear. And is
>> one that WG participants ought take to heart IMO. Pretending
>> that some changes to TLS would magically be limited in scope
>> to so-called "data centres" is BS. I'm really really puzzled
>> that some otherwise sensible folks appear unable to see that.
>>
>> S
>>
>>
>>> As both Adam Langley and I
>>> mentioned, none of the changes that anyone is investigating for reducing
>>> middlebox-induced breakage affect the cryptographic properties of TLS.
>>>
>>> -Ekr
>>>
>>>
>>>> On Sun, Oct 8, 2017 at 2:42 PM, Randy Bush <ra...@psg.com> wrote:
>>>>
>>>> there are a lot of us lurkers out here a bit horrified watching this wg
>>>> go off the rails.
>>>>
>>>> it would help if vendors of devices which break privacy would stop
>>>> speaking for 'datacenters' and let datacenters speak for themselves.  i
>>>> have not seen any doing so.  my $dayjob has >10 medium sized datacenters
>>>> serving everything from banks to telcos to scaled cloud services.  i can
>>>> not find folk in our datacenter groups who see a need to break e2e
>>>> encryption.
>>>>
>>>> if the interception proposals ensured that user is notified and able to
>>>> prevent session interception, then i would believe this.  but if they do
>>>> not, then let's face it, this is all about selling surveillance gear to
>>>> snooping enterprises and repressive regiemes where people with guns take
>>>> you away at 3am because your session was decoded.
>>>>
>>>> can we please provide real end to end privacy or call this wg something
>>>> else?
>>>>
>>>> randy
>>>>
>>>> ___
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>
>>>
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 



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

[Stephen Farrell]

On 05/10/17 09:54, Arnaud Taddei wrote:
> Being new to this community, can I actually ask for the analysis of
> the ‘hundred’s of applications’ which lead to the evolution of TLS
> 1.3 the way it is today? Was it captured somewhere or shall I
> reconstruct this history from all the discussions in the mailing
> lists?

It's more the latter. But, and it's a big but, tls1.3
is almost entirely (0rtt aside) aiming to provide the
same services as earlier versions, just to do it better,
so the need for that kind of broad survey of uses of
tls is far less. WRT 0rtt, people did, and are doing,
a bunch of work to figure out when it's (un)safe to
use that.

When it comes to breaking tls (as in this proposal),
since that'd change the security model (from an
essentially two party security protocol to an N-party
model), a lot more work would need to be done, and
has never been done, by any of the people proposing
to break tls, at least afaik.

S.


> 
> Thank you in advance
> 
>> Le 3 oct. 2017 à 00:48, Stephen Farrell <stephen.farr...@cs.tcd.ie>
>> a écrit :
>> 
>> 
>> Russ,
>> 
>> On 02/10/17 22:43, Russ Housley wrote:
>>>> For starters, though, I'd be interested answers from the
>>>> authors to two quick questions, though I suspect I can guess
>>>> 'em:
>>>> 
>>>> 1. TLS1.3 has had significant formal analysis. Did the authors
>>>> or other proponents here do any such work and if so can you
>>>> send a pointer to your results? If not, then I believe the onus
>>>> is on the folks who want to break TLS to do that work
>>>> themselves if they want to make a serious proposal and it is
>>>> not ok IMO to try put that work onto the community who have
>>>> been working hard for years to make TLS stronger.
>>> 
>>> I would be willing to work with the people that did the formal 
>>> analysis to show the impact of including the extension, and
>>> making changes to the extension that are indicated by that
>>> analysis.
>>> 
>> 
>> IMO, that's not a good answer. When improving the security 
>> properties of the protocol it may suffice. When weakening the
>> protocol, I strongly believe the onus is on you to have done that
>> work ahead of time, so that the damage you are proposing the
>> Internet suffers is clear and known and not discovered years
>> later.
>> 
>>>> 2. Which of the hundreds of applications making use of TLS did
>>>> you analyse before proposing this? If only a handful, then same
>>>> comment wrt where the onus ought lie.
>>> 
>>> Just like TLS 1.3 has been implemented and tested with many 
>>> applications during its development, I would expect the same to 
>>> happen in those environments where there is interest in making
>>> use of this extension.
>> 
>> The TLS WG has spent an awful lot of effort on (I think) every
>> single semantic difference between TLS1.2 and TLS1.3. (Ortt for
>> example.) You are now asking that everyone else do work to figure
>> out how your proposal damages their uses of TLS so that this
>> supposed use case is dealt with. I think you and other proponents
>> of breaking TLS need to spend that effort yourselves. (This is
>> because as you know there is no way to limit the damage of your
>> proposal to only the use-cases that are the claimed targets for
>> this bad idea.)
>> 
>> So yes, those answers are as I expected and are just as 
>> unsurprisingly, utterly unsatisfactory.
>> 
>> S.
>> 
>>> 
>>> Russ
>>> 
>>> 
>> 
>> ___ 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] Publication of draft-rhrd-tls-tls13-visibility-00

[Stephen Farrell]

Russ,

On 02/10/17 22:43, Russ Housley wrote:
>> For starters, though, I'd be interested answers from the authors to
>> two quick questions, though I suspect I can guess 'em:
>> 
>> 1. TLS1.3 has had significant formal analysis. Did the authors or
>> other proponents here do any such work and if so can you send a
>> pointer to your results? If not, then I believe the onus is on the
>> folks who want to break TLS to do that work themselves if they want
>> to make a serious proposal and it is not ok IMO to try put that
>> work onto the community who have been working hard for years to
>> make TLS stronger.
> 
> I would be willing to work with the people that did the formal
> analysis to show the impact of including the extension, and making
> changes to the extension that are indicated by that analysis.
> 

IMO, that's not a good answer. When improving the security
properties of the protocol it may suffice. When weakening
the protocol, I strongly believe the onus is on you to have
done that work ahead of time, so that the damage you are
proposing the Internet suffers is clear and known and not
discovered years later.

>> 2. Which of the hundreds of applications making use of TLS did you
>> analyse before proposing this? If only a handful, then same comment
>> wrt where the onus ought lie.
> 
> Just like TLS 1.3 has been implemented and tested with many
> applications during its development, I would expect the same to
> happen in those environments where there is interest in making use of
> this extension.

The TLS WG has spent an awful lot of effort on (I think)
every single semantic difference between TLS1.2 and TLS1.3.
(Ortt for example.) You are now asking that everyone else
do work to figure out how your proposal damages their uses
of TLS so that this supposed use case is dealt with. I think
you and other proponents of breaking TLS need to spend that
effort yourselves. (This is because as you know there is no
way to limit the damage of your proposal to only the use-cases
that are the claimed targets for this bad idea.)

So yes, those answers are as I expected and are just as
unsurprisingly, utterly unsatisfactory.

S.

> 
> Russ
> 
> 



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

[Stephen Farrell]

Sigh:-(

IMO the WG shouldn't touch this terrible proposal with a
bargepole.

And it remains outside the WG's charter I think. (It would be
a good idea if the chairs would clarify that a re-charter would
be needed were the WG to go bonkers and adopt a terrible idea
like this.)

I guess I'll need to update [1] too. I'll get back when I've
had a chance to do that but will happily accept PRs as before
and will keep an eye on the list.

For starters, though, I'd be interested answers from the authors
to two quick questions, though I suspect I can guess 'em:

1. TLS1.3 has had significant formal analysis. Did the authors
or other proponents here do any such work and if so can you send
a pointer to your results? If not, then I believe the onus is on
the folks who want to break TLS to do that work themselves if they
want to make a serious proposal and it is not ok IMO to try put
that work onto the community who have been working hard for years
to make TLS stronger.

2. Which of the hundreds of applications making use of TLS did
you analyse before proposing this? If only a handful, then same
comment wrt where the onus ought lie.

S.

[1] https://github.com/sftcd/tinfoil#latest


On 02/10/17 21:31, Ralph Droms wrote:
> We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS 
> extension defined in this I-D takes into account what we heard from the 
> discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 
> in Prague. Specifically, it provides an opt-in capability for both the TLS 
> client and server and makes it clear on the wire that visibility will be 
> enabled for the session.  The new mechanism does not depend on static 
> handshake or session keys.  
> 
> - Ralph and Russ
> 
> 
> ___
> 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] WG adoption call: SNI Encryption

[Stephen Farrell]

On 17/08/17 05:18, Martin Thomson wrote:
> https://tools.ietf.org/html/rfc7858
> 
> I hear that there are even implementations and deployments.

Yes, I used the resolver doing this at the last IETF meeting.
It worked. Not "just worked," but pretty good.

> 
> It's certainly time to have the discussion about closing the next gap.

Yes. I'm in favour of adopting as a strong signal that this
is a WG item. I don't think anyone needs to be allergic to
a wg draft-00 that still documents more than one proposal,
there's no specific place in the evolution of an RFC before
which such things MUST get sorted out, so while being a bit
concerned that we still have two options is very reasonable,
that's not IMO a winning argument against wg adoption.

S.



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

Re: [TLS] WG adoption call: SNI Encryption

[Stephen Farrell]

On 04/08/17 14:21, Daniel Kahn Gillmor wrote:
> On Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote:
>> At our IETF 99 session, there was support in the room to adopt
>> draft-huitema-tls-sni-encryption [0].  We need to confirm this support
>> on the list so please let the list know whether you support adoption
>> of the draft and are willing to review/comment on the draft before
>> 20170818.  If you object to its adoption, please let us know why.
> 
> I support wg adoption of this draft and am willing to review 

+1

> before
> 20170818.

Not sure about the date - if it's finished by then that'd
be pretty speedy:-)

S

> 
> --dkg
> 
> ___
> 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] 32 byte randoms in TLS1.3 hello's

[Stephen Farrell]

Hiya,

On 28/07/17 00:50, Eric Rescorla wrote:
> I used the term "separate" here, which was intended to convey this, but if
> people think "independent" or something is better, happy to change.

I think your change is a fine improvement over -21, thanks.
(And my suggested text was as imperfect as I usually manage:-)

I'm not clear if implementers will or will not get the
ramifications of "separate" (or "independent"), so I
think we ought describe (or reference) at least one way
in which that separation can be achieved.

I also think we ought at least RECOMMEND separate CSPRNGs.
I'd prefer a MUST myself but since there's no one good
way we can describe to achieve the effect that'd work in
all cases, I don't think we can say MUST.

Cheers,
S.


> 
> -Ekr
> 
> 
> On Thu, Jul 27, 2017 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
> 
>> Respectfully disagree. Having two cryptographically independent PRNGs, one
>> for public data and one for key material, IMHO is a good idea. Of course,
>> both should be properly seeded - but that's a different issue.
>>
>> Regards,
>> Uri
>>
>> Sent from my iPhone
>>
>> On Jul 27, 2017, at 19:33, Dan Brown <danibr...@blackberry.com> wrote:
>>
>>
>> I don't think 2 CSPRNGs is a good idea.
>>
>> Wasn’t there a few years back some RSA keys with separate p and q,
>> generated independently leading to an attack...
>>
>> Here if the seeds to initialize the RNGS are related, or one is weak, or
>> worst if the seed is a raw source that doesn’t change in the moments
>> between the two CSPRNG inits, that'd be bad, even if the CSPRNGs were good.
>> *From: *Eric Rescorla
>> *Sent: *Thursday, July 27, 2017 6:34 PM
>> *To: *Stephen Farrell
>> *Cc: *tls@ietf.org
>> *Subject: *Re: [TLS] 32 byte randoms in TLS1.3 hello's
>>
>> Spec updated here;
>> https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0acbc42
>> 942af9ca77
>>
>> -Ekr
>>
>>
>> On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell <
>> stephen.farr...@cs.tcd.ie> wrote:
>>
>>>
>>> I've suggested some text for this in a PR [1]
>>> based on what people have said in this thread.
>>>
>>> I'm sure that can be further improved.
>>>
>>> It might be no harm to add more pointers to that
>>> appendix from elsewhere in the spec, and/or to
>>> add a list of the various public/private random
>>> numbers that are needed to that appendix. (I'd be
>>> happy to do a pass to identify those if folks
>>> basically like this kind of addition.)
>>>
>>> I also need to figure out how to handle the
>>> reference properly:-) Can do that tomorrow.
>>>
>>> Cheers,
>>> S.
>>>
>>> [1] https://github.com/tlswg/tls13-spec/pull/1068
>>>
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
> 
> 
> 
> ___
> 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] 32 byte randoms in TLS1.3 hello's

[Stephen Farrell]

I've suggested some text for this in a PR [1]
based on what people have said in this thread.

I'm sure that can be further improved.

It might be no harm to add more pointers to that
appendix from elsewhere in the spec, and/or to
add a list of the various public/private random
numbers that are needed to that appendix. (I'd be
happy to do a pass to identify those if folks
basically like this kind of addition.)

I also need to figure out how to handle the
reference properly:-) Can do that tomorrow.

Cheers,
S.

[1] https://github.com/tlswg/tls13-spec/pull/1068



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

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Stephen Farrell]

On 25/07/17 04:53, Peter Gutmann wrote:
> Colm MacCárthaigh  writes:
> 
>> I think the fix for this is really at the application level; if you 
>> want defense-in-depth against PRNG problems, it's probably best to use 
>> separate RNG instances for public data (e.g. client_random, 
>> server_random, explicit_IV) and for secret data (keys) so that a leak 
>> in the public data doesn't compromise the private one. We do this in 
>> s2n, and I think BouncyCastle does it too. 
> 
> I do that too.  It's also specified in the LTS draft, it's just common 
> sense really.

I guess you mean this:

"
   TLS-LTS drops the requirement to generate the Client.random and
   Server.random using "a secure random number generator", typically the
   one used to generate encryption keys.  The use of a secure/
   cryptographic random number generator serves no obvious purpose (all
   that's required is a unique value), but exposes 224 bits of the
   cryptographic RNG output to an attacker, allowing them to analyse and
   potentially attack the RNG, and by extension any crypto keys that it
   generates:

   o  Implementations SHOULD NOT use the raw output from a
  cryptographic/secure RNG that's used to generate keying material
  to generate the Client.random and Server.random values.  Instead,
  they SHOULD employ a mechanism that doesn't directly expose
  cryptographic RNG output to attackers, for example by using the
  crypto RNG to seed a hash-based PRF such as the TLS PRF and using
  the output of that for the values.
"

I think something along these lines would be good advice to add
to appendix C.1 or to 4.1.2 where Random is defined.

That said, I'd still argue for an approach that a peer could
see was in use when "public" random byes aren't really needed but
fair enough if that doesn't resonate with people.

Cheers,
S.


> 
> Peter.
> 



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

[TLS] 32 byte randoms in TLS1.3 hello's

[Stephen Farrell]

Hiya,

I'm guessing many folks interested in TLS may have been
at the QUIC session in Prague and hence missed out on the
excellent talk by Stephen Checkoway on the juniper dual-ec
incident. (I highly recommend taking a peek at the slides [1]
or reading the paper [2] or watching the video wherever
that may be;-).

Anyway, in TLS1.3 we've gotten rid of the gmt time option
in the client and server hello, which is good, (and I do
recall that discussion) but we've also changed from:

   // RFC5246
   struct {
  uint32 gmt_unix_time;
  opaque random_bytes[28];
   } Random;

to:

   // tls1.3 -21
   opaque Random[32];

Now if some TLS1.3 deployment were affected by a dual-ec
attack, it'd seem like the -21 version of Random might be
even better than the TLS1.2 version, for the attacker.

I tried to see where that 28->32 change came from but
didn't find it (apologies if I missed that). I guess it
just ensures that the overall length of the struct is
the same.

So, a question and a possible suggestion:

Q: Why do we need 32 bytes of Random?

Suggestion: if we don't need that much, maybe we could
change the length there, (I can see that might trigger
bugs and middlebox issues) or encourage/require folks
to mask out some of those bits (e.g. with zeros or some
catchy hex encoded message about dual-ec:-).

Cheers,
S.


[1]
https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen-checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
[2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf



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

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

[Stephen Farrell]

It's fascinating that people cannot seem to stop picking at
the scab remaining after draft-green. I really think we'd be
wiser to just let the wound heal. (And get on with the work
that this WG has been chartered to do, which does not include
wiretapping.)

On 23/07/17 18:17, Felix Wyss wrote:
> How about requiring a record of a fixed size that either contains the
> session key encrypted with a “leaking key” or the output of a stream
> cipher keyed with the session key.  A 3rd party observer would not be
> able to determine whether the session key is being leaked but the
> client can tell and act accordingly.

The relevant signal is that a TLS deployment is able to be
wiretapped. It doesn't matter how that signal is sent, via
rfc1149 or in-band. Adding your putative field (which is
eerily reminiscent of a Clipper LEAF) is such a signal, and
it doesn't matter what content is in the field today, the
"local" authorities will see that and send you the key to
use for them.

See also the many earlier points about consent, naming etc
etc.

S.

> 
> --Felix
> 
> From: TLS  on behalf of Ted Lemon
>  Date: Sunday, July 23, 2017 at 16:34 To:
> "Blumenthal, Uri - 0553 - MITLL"  Cc:
> ""  Subject: Re: [TLS] datacenter TLS
> decryption as a three-party protocol
> 
> I did a little bit of rubber-duck debugging on this proposal with
> Andrea on the way back from Boston this morning.   It's actually
> better for the server to secretly use a static key than to negotiate.
> Stephen has already explained why: if this is a negotiation, then
> it's possible for a third party to simply block any negotiation that
> doesn't allow it.   We have no control over evil endpoints, and it's
> silly to pretend otherwise.   Pretending otherwise makes us less
> secure, not more secure.
> 
> 
> 
> ___ TLS mailing list 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 



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

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

[Stephen Farrell]

On 23/07/17 13:43, Blumenthal, Uri - 0553 - MITLL wrote:
> Ilari,
> 
> I got your point.
> 
> But in view of the request this WG is discussing now, I see only two
> reasonable (IMHO) opinion: 1. Tell those requestors to go away
> because TLS 1.3 has been designed to always be forward-secure; or 2.
> Add a *detectable* non-PFS key exchange so those requestors would
> have something they can live with, and the rest of us could at least
> agree or disagree to a non-PFS session establishment on a per-session
> or a per-entity basis.

In Prague some folks were considering another option:

3. Encourage folks who currently use static RSA keys for third
party decryption to put in place a migration plan that gets them
to FS without breaking TLS1.3. IOW, given they can continue to
use TLS1.2 for some years to come, there's no rush, and plenty
of time for transition plans to be put in place. (That'd I think
imply some work in the ops area of the IETF if there's any IETF
work needed at all, but nothing in the TLS wg.)

While I'd (probably entirely predictably:-) be against your
option 2 above, I'd also note that that'd entirely screw up any
ideas we might have of finishing TLS1.3 in the near term. Anyone
who'd argue for such changes needs to be clear that they're also
arguing for another year's delay.

Cheers,
S.

> 
> I do not know what mechanism could do the latter, or off it even
> exists. But folding an RSA method in seems to do the job. I'd say
> it's fine if it borrows from 1.0, as it isn't going to be the most
> secure setting anyway.
> 
> Regards, Uri
> 
> Sent from my iPhone
> 
>> On Jul 23, 2017, at 03:02, Ilari Liusvaara
>>  wrote:
>> 
>>> On Thu, Jul 20, 2017 at 08:42:10PM +, Blumenthal, Uri - 0553
>>> - MITLL wrote:
 On 7/20/17, 16:32, "ilariliusva...@welho.com on behalf of Ilari
 Liusvaara"  wrote: Maybe we are
 better off just retrofitting RSA-key-transport back into
 TLS-1.3?
>>> 
>>> This has in fact been requested. Kenny Paterson said about the
>>> request: 
>>> ---
>>>
>>> 
My view concerning your request: no.
>>> Rationale: We're trying to build a more secure internet.
>>> 
>>> My rationale to resurrect it: others are trying to push TLS-1.3
>>> into an invisibly-insecure state. If we must satisfy them (and
>>> I’m not at all sure we should), then this is the most obvious way
>>> to at least avoid the “insecurity” being silently pushed upon
>>> you. At the very least you’d have an option to continue under
>>> surveillance or abort connection.
>> 
>> This isn't just matter of what is considered "secure enough" to 
>> include. There are fundamential technical constraints that prevent 
>> adding static RSA back.
>> 
>> Early on, there were all sorts of really fundamential decisions on
>> how TLS 1.3 works. The results of these decisions are baked deeply
>> in the protocol, and are extremely hard to change. These decisions
>> were already very apparent in draft-02, over 3 years ago, despite
>> -02 being unimplementable.
>> 
>> One implication of those assumptions is that any asymmetric key 
>> exchange in TLS 1.3 is at least potentially forward secure[1] (the 
>> actual constraints on asymmetric key exchanges are even stronger 
>> than that, but this weaker version suffices here). Static RSA is
>> not even potentially forward-secure, so it can not be added.
>> 
>> If you try to add back RSA using the most straightforward method, 
>> what you get is not an analog of static RSA from TLS 1.2. The
>> result would be closer to RSA_EXPORT from TLS 1.0.
>> 
>> 
>> On the other hand, there is no way to construct a key exchange that
>> is always forward-secure. Either endpoint can always act in a way
>> that destroys forward-security (even without leaking any
>> per-connection information), but can not be detected (DH share
>> reuse is considered detectable) by the other end.
>> 
>> 
>> [1] "potentially forward secure" means that there exists
>> interoperating client and server implementations, so that the key
>> exchange is forward- secure.
>> 
>> 
>> -Ilari
>> 
>> 
>> 
>> ___ 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] datacenter TLS decryption as a three-party protocol

[Stephen Farrell]

On 20/07/17 18:08, Colm MacCárthaigh wrote:
> On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie>
> wrote:
> 
>> On 20/07/17 17:43, Colm MacCárthaigh wrote:
>>> that's the term that people keep applying,
>>
>> That term was appropriate for draft-green as justified in [1]
>> That's disputed by some folks but it's the correct term.
>>
> 
> If you maintain that draft-green is Wiretapping, then that is also the
> correct term for what is happening today. Today, operators are using a
> static key, used on the endpoints they control, to decrypt traffic
> passively. The only difference is DH vs RSA, and I know you'll agree that's
> not material.
> 
> Claiming that current browsers "support" wiretapping is plain
>> odd to me and not that useful for the discussion but isn't a
>> TLS protocol issue as we don't currently have, and don't have
>> a WG proposal for a draft-green like wiretapping API as part
>> of the TLS WG set of RFCs.
>>
> 
> It is odd ... and I'm being deliberately provocative to get at the
> doublethink. It is impossible to consider this mode wiretapping and not
> claim the browsers support it today. Plainly, they do.

In what sense does a browser "support" a server leaking a private
key via some proprietary interface? That makes zero sense to me
and seems sheer hyperbole, as you said yourself. And not useful.

> 
> We don't live in an abstract theoretical world in which this is not already

More hyperbole is less useful.

> happening, and is not already possible. 

When using crypto in a network protocol, it is impossible to know
or not know that a peer is implementing crypto well or badly.

> It will also continue to be
> possible to MITM traffic, if you have the RSA key, and some dh-static
> opponents even advocate for this. I have seen no intellectually consistent
> explanation for why that is ok, 

I never said it was "ok." I said it wasn't part of the TLS RFCs.

The point here is to not specify mechanisms that enable wiretapping
to the extent that is feasible (you seem to assume that all uses
of crypto "support" wiretapping, since it's always possible for an
implementation to leak keys - that's gibberish IMO, but I'm using
the term in your sense in this paragraph).

> why that won't be abused by coercive
> authorities, 

It could be. It'd still be abuse IMO.

> and hence why it is not better to have something in between;

"something in between" is just nonsense sorry. Your strawman
proposition that we define all crypto as "supporting" wiretapping
being nonsense, means that so is that bogus pseudo-compromise.

But given that this aspect isn't really useful discussion, I
hope we can leave it there.

Cheers,
S.


> that gives providers what they claim to need, but not the coercers.


> 



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

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

[Stephen Farrell]

On 20/07/17 17:43, Colm MacCárthaigh wrote:
> that's the term that people keep applying,

That term was appropriate for draft-green as justified in [1]
That's disputed by some folks but it's the correct term.

Claiming that current browsers "support" wiretapping is plain
odd to me and not that useful for the discussion but isn't a
TLS protocol issue as we don't currently have, and don't have
a WG proposal for a draft-green like wiretapping API as part
of the TLS WG set of RFCs.

S.

[1] https://github.com/sftcd/tinfoil#why-is-this-wiretapping



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

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

[Stephen Farrell]

On 20/07/17 16:23, Paul Turner wrote:
>> I'd assert there's no way TLS clients in general could know when to
>> set or unset the "please wiretap me" evil bit in a ClientHello,
>> regardless of how complex a configuration is used.
>  
> 
> It seems like the guidance would be for all TLS clients to NOT
> include the extension by default. Anyone who wanted to enable it on
> their TLS client would have to explicitly turn it on through
> configuration. Since the client wouldn’t include the extension and
> the server would know that the client would abort the connection if
> it included the extension in return (a violation of TLS 1.3), the
> server would simply proceed in killing the connection itself. It
> doesn’t seem like there would be the need for complex configuration
> decisions to be made by TLS client users who have no intention of
> enabling it. Is that correct?
No. What's correct is never even defining this at all.

If you think there's some other correct state of affairs I will
read the I-D you write describing that. (And then debunk it:-)

S.



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

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

[Stephen Farrell]

On 20/07/17 15:40, Paul Turner wrote:
> I’m assuming that you’re referring to multiple nations being between
> the TLS client and server. If a TLS client is set to not include the
> extension, it seems the TLS client would simply close the connection.
> It seems the client could choose whether it wanted to appease the
> nation states. 

Through how many nations states did this email travel between you
and I? Mail is maybe worse than the web, but that's just with our
current deployments but who knows when they'll migrate a 5G VM for
a web server close to my base station?

I'd assert there's no way TLS clients in general could know when
to set or unset the "please wiretap me" evil bit in a ClientHello,
regardless of how complex a configuration is used.

Cheers,
S.









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

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

[Stephen Farrell]

Hiya,

On 20/07/17 13:04, Paul Turner wrote:
> Let’s use the oppressive government institution that I believe you’ve
> mentioned (pardon me if I got that wrong) with a connection over the
> Internet in this case. 

Sorry, I'm not sure what you mean there, but guessing, yes,
there can be multiple nation state actors who would try to
compel use of this mitm, and for a proposal in this space
that also causes intractable problems when a connection is
supposed to be mitm'd by more than one of those, or one is
not clear which is the appropriate nation state attacker
to appease.

> Can you reply in that context? I’m truly
> interested in understanding. It wasn’t a “try”.
Hopefully the above helps, but it may also help to say that
the appropriate context I'd consider for TLS is essentially
all the applications of TLS and all the deployments that'd
eventually be updated with whatever proposal is on the table.
(Prior to getting it off the table when it's shown to be
a bad plan:-)

Cheers,
S.





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

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

[Stephen Farrell]

On 20/07/17 12:44, Paul Turner wrote:
> 
> I believe Russ was outlining a method where an extension would be
> added to TLS 1.3 that would provide for delivery of a decryption key
> to a third party during the handshake (correct me if I got that
> wrong, Russ). Because it would be during the handshake, it would seem
> to be visible to the TLS  Client—in fact, the client would have to
> include the extension to begin with. If the TLS client saw the
> extension and did not consent, it could abort the connection. If the
> TLS Server were attempting to provide access to the exchanged data to
> a third party, it would seem they could use 1, 2, or 3 above and not
> have to go to the trouble of attempting to subvert the mechanism that
> Russ proposes (and others have previously proposed).
Yeah, good try, but *which* third party?

The kind of (IMO) intractable questions that Would arise
include whether or not enterprise clients only want their
own snoopers to snoop and not everyone else's? And then
the naming issues become intractable. And of course in
many applications (e.g. SMTP) there's still >1 TLS session
in the mail e2e path. And in the web there can be >1 box
between the browser and content site. Yoav already brought
up another one about about:config, and, and, and...

In the end, this'd be another failed proposal is my bet.
I volunteer to help in the engineering of that if needed;-)

That's not to doubt or deride the folks posing illformed
requirements but because squaring circles is just not a
good plan.

S.



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

Re: [TLS] SAAG TLS working group report

[Stephen Farrell]

Hi Joe,

On 20/07/17 09:54, Joseph Salowey wrote:
> We had presentations on the pros and cons of a  proposed mechanism
> to decrypt TLS messages within the data center.   A hum indicated that
> there was roughly equal support on both sides.  Therefore, well will
> continue the discussion and it is unlikely that the draft will proceed in
> its current form.

Thanks for that. Having chatted with Russ also, it seems like
I ought change the tinfoil repo from describing draft-green as
a current proposal to one of our long list of failed proposals.
If that's right, that's good IMO.

I guess I'll leave a watch-this-space marker in "current proposals"
for the next one;-(

Cheers,
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] datacenter TLS decryption as a three-party protocol

[Stephen Farrell]

Just to note that Martin's mail contains specific examples
and detailed argument. That should be the lowest bar that
needs to be met in this discussion, not the arm-waving about
"TLS as a DoS attack" or "what about grandma" nonsense that
we heard today. The contrast between such non-argument and
the care that has been taken, and continues to be taken, in
the development of TLS1.3 is stark.

S.

On 19/07/17 21:25, Martin Rex wrote:
> I just watched the presentation on static DH / TLS decryption in Enterprise
> settings of todays TLS session
> 
>   https://youtu.be/fv1AIgRdKkY?t=4473
> 
> and I'm seriously appalled by the amount of cluelessness in the
> Networking & IT Departments on the one hand, and by what seems like
> woefully inadequate apps on the other hand.
> 
> I've been doing middleware development and customer support of
> SSL/TLS-protected communication for our company's (legacy) app
> as well as maintenance & customer support for the TLS stack we're
> shipping with it for the past 17 years, and I can't stop shaking
> my head about the perceived problems, that *NEVER*EVER* occurred
> to me, nor our IT & Hosting and neither any of our customers using our app
> (and I would definitely know about it).
> 
> Although we do ship our own TLS implementation, we don't have any APIs
> to export cryptographic keys, simply because it's completely unnecessary.
> 
> 
> With extremely few exceptions, an API-level trace at the endpoints
> is totally sufficient for finding app-level problems, such as
> unexpected "expensive" requests.  App-level traces on *EITHER* side
> should provide *ALL* information that is necessary to determine _which_
> particular requests are taking longer than expected.  If your Apps do
> not provide meaningful traces, then you have an *APPS* problem, and
> should be fixing or replacing apps, rather than mess around with TLS.
> 
> 
> There were a few issues with F5 loadbalancers (that were just forwarding
> traffic, _not_ acting as reverse proxy) related to a borked F5 option called
> "FastL4forward", which occasionally caused the F5 box to truncate TCP streams
> (the box received 5 MByte of TCP data towards the TLS Server, but
> forwarded only 74 KBytes to the client before closing the connection with
> a TCP FIN towards the TLS client.
> 
> And once I saw another strange TCP-level data corruption caused by some 
> Riverbed WAN accellerator.
> 
> 
> I remember exactly _two_ occasions during that 17 years when I produced
> a special instrumented version of our library for the server endpoint,
> which dumped stuff into a local trace file, but I never ever thought
> about exporting crypto keys (because it wouldn't help, and those
> weren't _my_ keys (but those of a customer):
> 
>(1) it dumped the decrypted RSA block from the ClientKeyExchange
>handshake message when encountering a PKCS#1 BT02 padding
>encoding failure
> 
>(2) it dumped the final decrypted block of a TLS record for
>when the CBC-padding-verification failed the check.
> 
> (1) was caused by a bug in the long integer arithmetic of an F5 load balancer
> which ocassionally produced bogus (un-decryptable) PreMasterSecrets
> 
> (2) was caused by a design flaw in JavaSE 1.6 by Java's SSL when it was used 
> with GenericBlockCipher over native-IO interfaces.
> 
> 
> I firmly believe that if you have a desire to decrypt TLS-protected
> traffic to debug APPS issues, then your APPS must be crap, and seriously
> lack capabilities to trace/analyze endpoint behaviour at the app level.
> 
> 
> With respect to "monitoring" SSL/TLS-protected traffic in the
> enterprise environment:
> 
> At least here in Germany, we're in the lucky position that wiretapping
> network traffic has been made a criminal offense in 2004.  If IT/Networking
> folks in the enterprise settings don't want to spend up to 4 years behind
> bars, they don't even try to decrypt SSL/TLS-protected traffic.
> 
>  
> -Martin
> 



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

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

[Stephen Farrell]

On 19/07/17 18:45, Colm MacCárthaigh wrote:
> For example, browser's
> incognito modes may refuse to support such sessions, if they knew what was
> going on.

That is a perfect example of the hideous dangers of all of this.
The implication in the above is that browsers would/should turn
on wiretapping support in the normal case.

S.



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

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

[Stephen Farrell]

On 19/07/17 17:58, Benjamin Kaduk wrote:
> On 07/19/2017 11:49 AM, Stephen Farrell wrote:
>>
>> On 19/07/17 14:09, Benjamin Kaduk wrote:
>>> As Stephen noted in his presentation, a lot of the proposals for passive
>>> decryption can be seen as trying to turn TLS from a two-party protocol
>>> into a three-party protocol.  Which is probably the right way to think
>>> about it, even when all (three) parties are within the same
>>> administrative domain.
>>>
>>> Stephen also said something about it being hard to shoehorn a
>>> three-party protocol into the API for a two party protocol.  But
>>> depending on the specifics, maybe it's not so bad.  For example, if the
>>> only semantics you need are a new API for "this is the list of third
>>> parties I authorize to wiretap this connection", the scope seems fairly
>>> limited.
>> I would question the size of the set of applications for which the
>> semantics of such a list/interface could make sense. For example,
>> asking a person if they're ok with some random IPv6 address spying
>> on a TLS session makes zero sense for example.
>>
> 
> Sure, some random IPv6 address makes no sense, and is not
> cryptographically bound to anything.
> On the other hand, "this (semi-)static DH key is one currently used by
> my enterprise's network monitoring system, and is allowed to read my
> traffic" seems closer to what is being asked for.

I don't know how that kind of identifier can be made meaningful
for almost any application where the identifier is not already
meaningful, and in many such cases I would guess there are
already hop-by-hop behaviours where TLS is not e2e for the
application layer (MTAs etc.) But sure, someone could do the
work to describe some applications that might have a need for
a multiparty security protocol like that I guess. As I said,
my guess is that the size of that set of applications is small.

> 
> As has been said downthread, the recommendation is not "you should
> always use this thing", it's "you should do TLS 1.3 without backdoors,
> but if you really need to, this is a way to do so with known and limited
> properties".

I can see why people might consider that some kind of compromise
that's less bad, but I think searching for "less bad" is not at all
the right approach. I don't mean that we oughtn't investigate
possible scenarios, but searching for a compromise is not in itself
a good goal here.

Cheers,
S.

> 
> -Ben
> 
> -Ben
> 



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

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

[Stephen Farrell]

On 19/07/17 18:10, Russ Housley wrote:
> The hum told us that the room was roughly evenly split.  In hind
> sight, I wish the chairs had asked a second question.  If the split
> in the room was different for the second question, then I think we
> might have learned a bit more about what people are thinking.
> 
> If a specification were available that used an extension that
> involved both the client and the server, would the working group
> adopt it, work on it, and publish it as an RFC?

I would almost certainly be opposed. There are enough generic
reasons to not break tls to go around for us all.

S.

> 
> I was listening very carefully to the comments made by people in
> line.  Clearly some people would hum for "no" to the above question,
> but it sounded like many felt that this would be a significant
> difference.  It would ensure that both server and client explicitly
> opt-in, and any party observing the handshake could see the extension
> was included or not.
> 
> Russ ___ TLS mailing
> list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 



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

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

[Stephen Farrell]

On 19/07/17 14:09, Benjamin Kaduk wrote:
> As Stephen noted in his presentation, a lot of the proposals for passive
> decryption can be seen as trying to turn TLS from a two-party protocol
> into a three-party protocol.  Which is probably the right way to think
> about it, even when all (three) parties are within the same
> administrative domain.
> 
> Stephen also said something about it being hard to shoehorn a
> three-party protocol into the API for a two party protocol.  But
> depending on the specifics, maybe it's not so bad.  For example, if the
> only semantics you need are a new API for "this is the list of third
> parties I authorize to wiretap this connection", the scope seems fairly
> limited.

I would question the size of the set of applications for which the
semantics of such a list/interface could make sense. For example,
asking a person if they're ok with some random IPv6 address spying
on a TLS session makes zero sense for example.

Cheers,
S.

> 
> Another thought spawned from today's session is that, given concerns
> about preventing/noticing if schemes intended for the datacenter leak
> out onto the internet, it's not really clear that "minimizes changes to
> the wire protocol" should be considered a benefit of proposals in this
> space.  If there are clear changes to the wire protocol, that makes it
> easy to detect when the scheme is in use.
> 
> -Ben
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



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

Re: [TLS] possible new work item: not breaking TLS

[Stephen Farrell]

Hiya,

Thanks to the chairs for allocating some agenda time for
discussion of this topic at tomorrow's session. I plan to
more or less present [1] instead of using slides, so if
folks have a chance to read it over before we get to that
agenda item tomorrow that should help speed things up a
bit.

I'm still happy to take corrections, comments and suggestions
however folks would like to provide those but plan to be at
the social event tonight so likely won't do more updates to
the text before tomorrow morning (semi-inebriated additions
being a bad plan, even if nowhere near as bad a plan as
draft-green:-)

Cheers,
S.

[1] https://github.com/sftcd/tinfoil

On 13/07/17 13:00, Stephen Farrell wrote:
> 
> Hi again TLS WG chairs,
> 
> I've done a bit more work on the collection of arguments
> against the latest break-TLS proposal. [1] I plan to keep
> working on that so more input is welcome. (Corrections
> where I've gotten stuff wrong are even more welcome.)
> 
> I'd like to again request some time on the agenda to
> allow discussion of those points in a more structured
> manner than will be possible during the mic-line scrum
> that'll likely follow a sales-pitch for draft-green.
> 
> I'd also like to ask the WG if we think it'd be useful
> to document the arguments against that and other "let's
> break-tls" proposals we've seen in the past in an RFC.
> If people think it would be useful, I'd be willing to
> do work to edit such a draft, or help edit that.
> 
> Thanks,
> S.
> 
> [1] https://github.com/sftcd/tinfoil
> 
> 
> 
> ___
> 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] draft-green-tls-static-dh-in-tls13-01

[Stephen Farrell]

Hiya,

On 15/07/17 20:49, Roland Zink wrote:
> TLS is a two endpoint protocol. It looks like many of the use cases
> describe problems with more than two endpoints but are using TLS because
> it is commonly available. So should TLS be extended to be an n-party
> protocol (or is this always considered wiretapping?) or should be there
> another protocol or something else?

Yes, if one wants different semantics than TLS and needs an
entirely different interface for applications, (which all N>2
party protocols do need) then one needs to define a different
protocol that is not TLS.

Of course, that's impractical, so people will continue to
ignore the fact that they're doing bad engineering and will
come along now and then and try convince us to break TLS.

Cheers,
S.


> 
> 
> Regards,
> 
> Roland
> 
> 
> 
> Am 15.07.2017 um 19:34 schrieb Colm MacCárthaigh:
>>
>>
>> On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor
>> > wrote:
>>
>>  * This proposed TLS variant is *never* acceptable for use on the
>> public
>>Internet.  At most it's acceptable only between two endpoints
>> within
>>a datacenter under a single zone of administrative control.
>>
>>
>>  * Forward secrecy is in general a valuable property for encrypted
>>communications in transit.
>>
>>
>> If there's anyone on the list who disagrees with the above two
>> statements, please speak up!
>>
>>
>> I agree with the second statement, but I don't really follow the logic
>> of the first. On the public internet, it's increasingly common for
>> traffic to be MITMd in the form of a CDN. Many commenters here have
>> also responded "Just use proxies". I don't get how that's better.
>>
>> A proxy sees all of the plaintext, not just selected amounts. All of
>> the same coercion and compromise risks apply to a proxy too, but since
>> it undetectably sees everything,  that would seem objectively worse
>> from a security/privacy risk POV.
>> Or put another way: if these organizations need to occasionally
>> inspect plaintext, would I prefer that it's the kind of system where
>> they have to go pull a key from a store, and decrypt specific
>> ciphertexts on demand offline, or do I want them recording plaintext
>> *all* of the time inline? It seems utterly bizarre that we would
>> collectively favor the latter. We end up recommending the kinds of
>> systems that are an attacker's dream.
>>
>> Here's what I'd prefer:
>>
>>  * Don't allow static DH. In fact, forbid it, and recommend that
>> clients check for changing DH params.
>>  * For the pcap-folks, define an extension that exports the session
>> key or PMS, encrypted under another key. Make this part of the
>> post-handshake transcript.
>>  * pcap-folks can do what they want, but clients will know and can
>> issue security warnings if they desire. Forbiding static DH enforces
>> this mechanism, and we can collectively land in a better place than we
>> are today.
>>
>> -- 
>> Colm
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



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

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

[Stephen Farrell]

Hiya,

On 16/07/17 05:41, Colm MacCárthaigh wrote:
> On Sat, Jul 15, 2017 at 5:39 PM, Stephen Farrell 
> <stephen.farr...@cs.tcd.ie> wrote:
> 
>> On 15/07/17 23:55, Colm MacCárthaigh wrote:
>>> So far responses on the mailing list have been saying "Don't use
>>>  pcap, instead run proxies".
>> Sorry, but that is incorrect. Some list participants have said "we 
>> need pcap" and others have said that "no, we do not need to use 
>> packet capture." And others, myself included, consider that there 
>> is dearth of evidence.
>> 
> 
> Can you be more clear what is lacking in evidence?

Sure, sorry for the late-night terseness:-)

In this debate, there is a fairly complete lack of evidence
being offered as to:

- the (in)effectiveness of proxies or key-leaking vs. one
  another and vs. not doing either
- the precise scenarios in which pcap+key-leaking is the only
  possible (*) answer, and how commonly those scenarios occur

(*) I am not asking that people tell me that "pcap+key-leaking"
might work, but for them to describe when that works but nothing
else works. And that has to include the details of what it is
they can only find in the recovered cleartext that cannot be
detected without access to cleartext using this particular
method.

> Are you skeptical that existing network operators don't do this kind
> of decryption?

I believe that people do this kind of key-leak+pcap decryption.

People do all sorts of other unwise things too (myself included,
and fairly frequently;-), that is not a reason to encourage more
of "it" for any "it."

> There's support for it in tools like Wireshark. Is that sufficient 
> evidence?

Yes and no. That is sufficient in that yes it says that people
can use this tool. It is nowhere near sufficient evidence that the
IETF should standardise (an API for) such a tool. The existence
of a wireshrark dissector for a protocol is also fairly weak
evidence as to the importance of such a dissector - it seems to
be fairly common for folks to write those for lots of other
reasons, e.g. during protocol development, as student projects
that require no thought from the prof etc:-)

> Are you skeptical that there's no evidence that using proxies
> instead would be a burdensome change?

No. All changes are burdensome, and it's clear that that one
would be. (My own belief is that adding proxies solely to help
with possible network debugging would be dim anyway - I'd
argue there ought to be a functional reason for each proxy
added.)

I would also note that the "use a proxy" argument seems to me
to mostly be offered as a strawman counter-argument by folks
who would like to break TLS via static DH, and doesn't seem to
be a common argument offered by those against breaking TLS.
(Adding proxies is of course another way to break TLS, depending
on how and where it's done.)

> I'm not skeptical of that at all, but would be interested in what
> acceptable evidence would look like.

I'm not sure of the phrase "acceptable evidence" but regardless
of that:

TLS is an important protocol, extremely widely used. For any attempt
to weaken or break TLS, I think the onus is on the proponents of the
break-TLS proposal to produce convincing evidence that their scheme
will at least be a net positive, considering the entire ecosystem
that is dependent on TLS. And even if there is evidence that a scheme
would be a net positive, it may still be a bad idea, if the negative
aspects of the scheme have serious enough impacts in some use-cases
for TLS.

That's a pretty high bar, yes. And so it should be. I'm not at all
clear it can be cleared, ever.

> Though I'll point out again: TLS 1.3 is the new thing that we want
> to gain adoption, so really we should be looking for evidence that
> it's /not/ a burdensome change.

Sure, that is another fine thing to do. It'd be helped along if we
had evidence about the precise scenarios in which the pcap+key-leak
wiretapping is the only possible usable approach. That hasn't been
described on the list. (It has been asserted that such scenarios
exist, and it has been claimed that we should all know and accept
all this already, but those were TBBA non-arguments.)

Cheers,
S.



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