Jonathan Hoyland writes:
> When someone tries to copy a message from a SCRAM handshake into some
> GSS-API run on a single TLS connection I want to be sure that it will be
> rejected, without having to understand exactly how every version of SCRAM
> and GSS-API ever (including ones that will be d
Hi Sam, all,
I'd like to again raise the issues I pointed out in
https://mailarchive.ietf.org/arch/msg/kitten/13pPj4E3-gYwpbu2K844uI1BPoU/ .
This draft hasn't received enough security analysis, and further, I pointed
out a specific security issue that remains unaddressed.
Using the same label for
m Security
Symposium (NDSS), 2015.
?
Just a thought?
Michael Ross
NIWC Atlantic
US Navy
From: TLS On Behalf Of Sam Whited
Sent: Sunday, October 3, 2021 9:37 AM
To: Salz, Rich ; Rob Sayre
Cc: tls@ietf.org
Subject: [Non-DoD Source] Re: [TLS] Fwd: Last Call:
(Channel Bindings for
TLS 1.3) t
8446 currently contains:
> However, it is also possible to bind such connections to an external
> authentication mechanism via out-of-band validation of the server's
> public key, trust on first use, or a mechanism such as channel
> bindings (though the channel bindings described in [RFC5929] are
Sorry to be difficult, but as I said, I'd prefer to focus not on the
question of the header of this document but rather on what we wish 8446
said. To that end, what text do you think should go in 8446-bis?
-Ekr
On Sat, Oct 2, 2021 at 6:29 PM Sam Whited wrote:
> Even if linking this in updates
I'd be okay with that provided we can release an update if such an analysis is
ever done?
Although this is such a low-stakes issue that I worry that the prejudicial
value of such a statement far outweighs the security value. I don't feel
strongly about it though.
—Sam
On October 3, 2021 1:06:
Perhaps adding text that says no security analysis has been done.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Even if linking this in updates implied confidence (though I don't think
it does), TLS alread implies confidence in its own EKM mechanism. I
don't believe this document expands on that. For example, it does not
detail any particular use of channel binding.
—Sam
On Sat, Oct 2, 2021, at 13:12, Eri
On Sat, Oct 2, 2021 at 10:13 AM Eric Rescorla wrote:
> I want to be clear that I don't think this is about credit. My concern is
> purely about accurately reflecting the level of confidence one should have
> in this mechanism.
>
Yes, that is how I feel also (although my opinion matters much less
I want to be clear that I don't think this is about credit. My concern is
purely about accurately reflecting the level of confidence one should have
in this mechanism.
-Ekr
On Fri, Oct 1, 2021 at 8:43 PM Sam Whited wrote:
> This is just a registration with IANA more than anything else; this
>
On Fri, Oct 1, 2021 at 8:04 PM Sam Whited wrote:
> I have to respectfully disagree with this.
>
> Anecdotally, RFCs are hard to discover. Having them linked from a
> logical place in other RFCs is one way that discovery happens, and if
> you're looking for how to do channel bindings with TLS the
This is just a registration with IANA more than anything else; this
required almost no work compared to the many people and many years spent
on TLS. I don't believe marking this as an update implies any flaw in
TLS, or any presumption that this is somehow its equal in terms of
effort. This isn't a
On Fri, Oct 1, 2021 at 8:18 PM Sam Whited wrote:
> No, I am saying that I have seen people implement custom solutions to
> problems in an RFC
Makes sense a goal—I think the objection is more that updating 8446 on
paper here is presumptuous, since that document took orders of magnitude
more work
No, I am saying that I have seen people implement custom solutions to
problems in an RFC because they don't realize that there is a related
RFC that fixes those problems (or suggests how to do whatever tangential
thing they needed to implement). Having a link in the related RFCs make
things easier
On Fri, Oct 1, 2021 at 8:04 PM Sam Whited wrote:
> I have to respectfully disagree with this.
>
> Anecdotally, RFCs are hard to discover.
What do you mean, exactly, here?
Are you saying that this draft “update” 8446 in order for readers to
understand it and 8446 itself?
thanks,
Rob
Having
I have to respectfully disagree with this.
Anecdotally, RFCs are hard to discover. Having them linked from a
logical place in other RFCs is one way that discovery happens, and if
you're looking for how to do channel bindings with TLS the first place
you're going to look is the TLS RFC (and its lis
On Fri, Oct 1, 2021 at 3:50 PM Eric Rescorla wrote:
> I don't believe that this document should update 8446.
>
Agree. This document should not update 8446.
thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
I don't believe that this document should update 8446. As noted in S 1, we
didn't define these bindings because we didn't have complete analysis. This
document doesn't seem to either contain or reference such analysis and
until we have that, I think RFC 8446 shouldn't be retconned into endorsing
th
This draft got some previous discussion on the WG list, but it's worth
having people take another look at it during last call.
In particular, note that it updates RFC 8446.
-Ben
On Fri, Oct 01, 2021 at 11:20:35AM -0700, The IESG wrote:
>
> The IESG has received a request from the Common Authenti
19 matches
Mail list logo
