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
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
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
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),
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
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.
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
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
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
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
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
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
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,
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
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
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
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,
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.
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
+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
+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.
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
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
What does it say that RFC 8404 doesn’t?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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
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
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 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
+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:
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
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
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
>
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
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
34 matches
Mail list logo
