Without taking a position on the security matter: this has been part of the
TLS design for 20+ years, and therefore has had multiple LCs and WG and
IETF consensus, so it would take a pretty strong set of arguments to change
now. I've debugged a lot of TLS interop issues, and as a practical matter,
Hi folks,
TLS 1.3 has been approved by the IESG and it's on its way to the RFC
Editor, so
I don't really see this changing any time soon for the base RFC.
I think there's some debate about whether this is a good idea, but in any
case,
the right way to pursue it would be to publish a new draft, pr
Thinking through this some more, I'm skeptical that this is going to be
that useful as a debugging-only feature.
In my experience, there are four major scenarios for diagnosing this kind
of failure. Under the assumption that you control one end, the other end
can be:
1. A live endpoint.
2. A test
On Sat, Mar 31, 2018 at 10:29 PM, Peter Gutmann
wrote:
> Eric Rescorla writes:
>
> >In my experience, there are four major scenarios for diagnosing this kind
> of
> >failure. Under the assumption that you control one end, the other end can
> be:
> >
> >
At Tue, 26 Feb 2008 12:53:42 +0200,
Miguel,
Thanks for your comments. I generally took these, but some
responses below.
Miguel Garcia wrote:
> Comments: The document is well written, as one could expect from a new
> iteration of an existing document. I have very minor comments and
> suggestions,
Thanks for reviewing this.
-Ekr
On Thu, Jun 5, 2008 at 2:40 PM, Ben Campbell <[EMAIL PROTECTED]> wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
>
> Suresh Krishnan provided a Gen-ART Review on 5-Nov-2008. While it
> is a bit late, I would like to see a response to the "substantial"
> concern that is raised. I have not taken the time to determine if
> the man-in-the-middle attack is possible, and I hope the authors
> can quickly tell i
At Thu, 06 Nov 2008 10:04:43 -0500,
Suresh Krishnan wrote:
>
> Hi Eric,
>Thanks for the quick response.
>
> Eric Rescorla wrote:
> >> Section 8.1: Responder identity
> >>
> >> When Bob does not respond with an UPDATE message, his identity is
> &g
At Thu, 06 Nov 2008 15:58:52 -0500,
Suresh Krishnan wrote:
>
> Hi Eric,
>
> Eric Rescorla wrote:
> > But then the attacker isn't *intercepting* their communications.
> > Alice calls Bob and ends up talking to someone but she knows
> > that she doesn't know
At Fri, 07 Nov 2008 10:53:16 -0500,
Suresh Krishnan wrote:
>
> Hi Eric,
>
> Eric Rescorla wrote:
> >> I still don't see how Bob detects the attack. Consider the following
> >> message flow.
> >>
> >> 1) Alice->Bob : INVITE (Fingerprint
At Fri, 07 Nov 2008 10:40:34 -0500,
Suresh Krishnan wrote:
>
> Hi Eric,
>
> Eric Rescorla wrote:
> >In some cases, answerers will not send an UPDATE and in many calls,
> >some media will be sent before the UPDATE is received. In these
> >cases, no
Steve,
can you send me a link to a permanent home?
-Ekr
On Mon, Dec 21, 2009 at 9:36 AM, Vijay K. Gurbani
wrote:
> Steve Dispensa wrote:
>>
>> I tried to send this the other day bit it doesn't look like it went
>> through. I was just going to say that PhoneFactor would be glad to provide a
>>
Thanks!
Now I just need to figure out how to get xml2rfc to spit out the URL.
-Ekr
On Tue, Dec 22, 2009 at 2:24 PM, Steve Dispensa
wrote:
> This will be a stable link:
>
> http://www.phonefactor.com/Renegotiating_TLS.pdf
>
> -Steve
>
> On Dec 21, 2009, at 6:37 PM, &
On Mon, Feb 10, 2020 at 8:14 AM Mohit Sethi M wrote:
> Hi Sara,
>
> I understand the desire to get this done with. However, I have some
> further comments in-line:
> On 1/24/20 5:29 PM, Sara Dickinson wrote:
>
> Mohit,
>
> I’m out of the office next week so in order to try to move the draft along
On Mon, Feb 10, 2020 at 11:44 AM Mohit Sethi M
wrote:
>
> On 2/10/20 9:18 PM, Eric Rescorla wrote:
>
>
>
> On Mon, Feb 10, 2020 at 8:14 AM Mohit Sethi M 40ericsson@dmarc.ietf.org> wrote:
>
>> Hi Sara,
>>
>> I understand the desire to get this
Stewart,
Thanks for your review.
I have changed all but the last point, which I believe is correct as-is.
The final issue asked if we should replace the reference to RFC 5077
to RFC 8446, but this text is correct because the reference is to part
of the internal example structure in 5077 and 8446
16 matches
Mail list logo
