Nancy,
I support this work and think this draft should be published. This is a yet
another good write up on some of the requirements that are needed for
operational security.
Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhr
This draft contains substantial omissions in section 3.
Nothing in TLS 1.3 prevents scanning for servers and examining the
certificates they present. Nothing in TLS 1.3 prevents using reverse
proxies to provide WAF functionality. PCI-DSS compliance is not at odds
with deploying TLS 1.3. In fact th
On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) <
ncamw...@cisco.com> wrote:
> Hi,
>
> Thanks to all the feedback provided, we have updated the
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>
> draft. At this point, we believe the draft is stable and would like to
> r
On Sun, Jul 21, 2019 at 01:51:32PM +, Nancy Cam-Winget (ncamwing) wrote:
> Thanks to all the feedback provided, we have updated the
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
> draft. At this point, we believe the draft is stable and would like to
> request its publicati
I don’t have a preference for whether this draft should become a working group
item, or become an AD-sponsored or individual submission, but in any case it
contains important additions to the security considerations of RFC 8446. The
use-cases it details are real-life scenarios where the introdu
+1
And I would add that the pervasive effects of encryption are not limited to
security of systems, but limit the abilities of other system management,
monitoring and diagnostic platforms as well.
From: TLS On Behalf Of Mark O
Sent: Tuesday, July 23, 2019 4:28 PM
To: tls@ietf.org
Subject: Re:
On 7/23/19 2:35 PM, Watson Ladd wrote:
This draft contains substantial omissions in section 3.
Nothing in TLS 1.3 prevents scanning for servers and examining the
certificates they present.
Agreed, however there is no guarantee that the server will present the
same certificate and other TLS p
Tony,
While you may have concerns or otherwise disagree with the contents of this
draft, let’s please keep discussion on this list, on all issues, polite and
professional.
spt
(as co-chair)
> On Jul 23, 2019, at 16:05, Tony Arcieri wrote:
>
> On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget
On 7/23/19 4:05 PM, Tony Arcieri wrote:
On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing)
mailto:ncamw...@cisco.com>> wrote:
Hi,
Thanks to all the feedback provided, we have updated the
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
draft. At this poi
On 7/23/19 4:14 PM, Viktor Dukhovni wrote:
On Sun, Jul 21, 2019 at 01:51:32PM +, Nancy Cam-Winget (ncamwing) wrote:
Thanks to all the feedback provided, we have updated the
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
draft. At this point, we believe the draft is stable
What does it say that RFC 8404 doesn’t?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Tue, Jul 23, 2019, 1:51 PM Flemming Andreasen wrote:
>
>
> On 7/23/19 2:35 PM, Watson Ladd wrote:
>
> This draft contains substantial omissions in section 3.
>
> Nothing in TLS 1.3 prevents scanning for servers and examining the
> certificates they present.
>
> Agreed, however there is no guar
Thanks Sean.
It is critical that we understand and discuss all sides of an issue and address
all use cases that market has. Beating people down and trying to attack people
or their use cases is not something we should be doing in formal standards,
especially here at the IETF.
Thanks,
Bret
P
+1, neutrality is appreciated, thank you Sean
Collecting expressed views should prevail in a neutral way, there is no reason
why inappropriate behaviour should be tolerated and let the impression that the
loudest voice is prevailing
Sent with [ProtonMail](https://protonmail.com) Secure Email.
+1
From: TLS On Behalf Of Bret Jordan
Sent: Tuesday, July 23, 2019 5:52 PM
To: Sean Turner
Cc: Tony Arcieri ; tls@ietf.org
Subject: Re: [TLS] TLS Impact on Network Security draft updated
ALERT This email was sent from a source external to BCBSM/BCN.
DO NOT CLICK links or attachments unless yo
I really want the savings on the wire that TLS flags extension provides – and
so I think it’s really good for the future cTLS but I’m not sure when I get to
use it in TLS 1.3 negotiation. It goes in the clientHello message, but how
will I know that the server uses this extension? I envision a
Are on etherpad at https://etherpad.ietf.org/p/notes-ietf-105-tls
Cut/pasted here (but more readable there):
TLS at IETF 105
Tuesday
Status update (drafts, code points, etc) -- see the slides
CFRG working on PAKE selection; integration with TLS is obviously important,
come to CFRG meeting.
D
Document: draft-camwinget-tls-use-cases-05.txt
I have some technical comments on the current draft.
S 2.2.1.
Note that even _if_ the SNI is provided by the client, there is no
guarantee that the actual server responding is the one indicated in
the SNI from the client. SNI alone, withou
Before any technical or wording feedback, I am confused as to the nature of
this document. It does not seem to specify any protocol change or mechanism,
and it does not even focus on solutions to move the web further.
Instead, it looks like a well edited blog post, presenting the perspective of
Informational documents do not (usually) have normative statements. If they
had normative language, they would be standards track document.
Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that c
On Tue, Jul 23, 2019, 3:47 PM Filippo Valsorda
wrote:
> Before any technical or wording feedback, I am confused as to the nature
> of this document. It does not seem to specify any protocol change or
> mechanism, and it does not even focus on solutions to move the web further.
>
> Instead, it loo
RFC 791 is nearly 40 years old.
RFC 4074 lists 5 forms of deviations from RFC 1034 and explains
the correct behavior.
RFC 7021 describes a series of objective tests of RFC 6333 and
the results.
The above RFCs describe objective test results and how they
relate to earlier RFCs. In contrast,
Suppose the following sequence of events happen:
1: A CA uses a new intermediate for reasons (no longer cross-signing, etc.)
2: A site gets a certificate from the new intermediate.
3: An older firefox version connects and thinks it knows all the
certificates in the world.
This would seem to break
Thank you!
On Tue, Jul 23, 2019, 3:14 PM Salz, Rich wrote:
> Are on etherpad at https://etherpad.ietf.org/p/notes-ietf-105-tls
>
>
>
> Cut/pasted here (but more readable there):
>
> TLS at IETF 105
>
>
>
> Tuesday
>
>
>
> Status update (drafts, code points, etc) -- see the slides
>
>
>
> CFRG wo
On Tue, Jul 23, 2019 at 5:23 PM Watson Ladd wrote:
> Suppose the following sequence of events happen:
>
> 1: A CA uses a new intermediate for reasons (no longer cross-signing, etc.)
> 2: A site gets a certificate from the new intermediate.
> 3: An older firefox version connects and thinks it know
On Tue, Jul 23, 2019 at 3:09 PM Chris Inacio wrote:
> I really want the savings on the wire that TLS flags extension provides – and
> so I think it’s really good for the future cTLS but I’m not sure when I get
> to use it in TLS 1.3 negotiation. It goes in the clientHello message, but
> how wi
As a professional organization and part of due diligence, we need to try and
understand the risks and ramifications on the deployments of our solutions.
This means, understanding exactly how the market uses and needs to use the
solutions we create. When we remove or change some technology, we sh
I repeat my question: What does it say that RFC 8404 doesn’t?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 24/07/2019 02:55, Bret Jordan wrote:
> As a professional organization and part of due diligence, we need to try
> and understand the risks and ramifications on the deployments of our
> solutions. This means, understanding exactly how the market uses and
> needs to use the solutions we create. Wh
On Wed, Jul 24, 2019 at 03:35:43AM +0100, Dennis Jackson wrote:
> On 24/07/2019 02:55, Bret Jordan wrote:
> > As a professional organization and part of due diligence, we need to try
> > and understand the risks and ramifications on the deployments of our
> > solutions. This means, understanding ex
This should not be dismissed as small segments of industries.This
represents ubiquitous use cases at all large organizations in Insurance, Health
Care, Banking, Automotive and many others.
We as the IETF should not lightly dismiss such significant numbers and volume,
even (or especially), i
On Tue, Jul 23, 2019, 6:55 PM Bret Jordan wrote:
> As a professional organization and part of due diligence, we need to try
> and understand the risks and ramifications on the deployments of our
> solutions. This means, understanding exactly how the market uses and needs
> to use the solutions we
On 24/07/2019 04:13, Benjamin Kaduk wrote:
> On Wed, Jul 24, 2019 at 03:35:43AM +0100, Dennis Jackson wrote:
>> On 24/07/2019 02:55, Bret Jordan wrote:
>>> As a professional organization and part of due diligence, we need to try
>>> and understand the risks and ramifications on the deployments of
Hi.
Following today’s session, I’ve updated and submitted the draft.
It contains the proposal from slide #5 in my presentation.
It does not contain any fancy way of reserving bits for future popular
extensions.
It uses a single numbering of the flags, not the more efficient separate
numbering
Hello,
I would like to suggest that this draft is expanded to cover the use cases
of governments, such as those recently seen in Kazakhstan. This will
ideally leave the reader with a fuller impression of the risks inherent in
the technology being described here.
- section 1: add a sentence to the
35 matches
Mail list logo
