The draft explains this in more detail.
To use your example, there is now confusion over the identity of the
server. The client thinks that they have connected to google.com,
when in fact they have connected to facebook.com.
That's where the attacks start. Requests made to facebook.com over
tha
I'm a bit puzzled by this "UKS" (Unknown Key Share) attack concept.
The attack scenario, presented in section 2 of
https://www.ietf.org/id/draft-barnes-dane-uks-00.txt
is that a user connects to the "attacker" site (say google.com) but
actually google.com has published Facebook.com's public k
On Tue, Oct 11, 2016 at 10:54:52PM -0400, Viktor Dukhovni wrote:
>
> What's odd is not that SMTP and XMPP are immune, but rather
> the astonishing subtlety of the Web security model, which
> makes web applications vulnerable.
It is combination of HTTP servers being pretty widely misconfig'd in a
> On Oct 11, 2016, at 8:31 PM, Martin Thomson wrote:
>
>> I believe your concept is much to narrow.
>
> I tend to agree, though that hinges on your definition of
> "cross-origin". In the web world, that has a very specific meaning.
> What you could say that "if the client doesn't care who it i
On 12 October 2016 at 01:45, Martin Rex wrote:
>> Well, the UKS issue is rather narrowly applicable to special TLS
>> applications in which cross-origin concerns apply. That's
>> basically just browsers, and browsers are not doing DANE, and
>> certainly not DANE-EE(3).
>
> I believe your concept
> On Oct 11, 2016, at 10:45 AM, Martin Rex wrote:
>
> Viktor Dukhovni wrote:
>>
>> Well, the UKS issue is rather narrowly applicable to special TLS
>> applications in which cross-origin concerns apply. That's
>> basically just browsers, and browsers are not doing DANE, and
>> certainly not DAN
Viktor Dukhovni wrote:
>
> Well, the UKS issue is rather narrowly applicable to special TLS
> applications in which cross-origin concerns apply. That's
> basically just browsers, and browsers are not doing DANE, and
> certainly not DANE-EE(3).
I believe your concept is much to narrow.
The issue
> On Oct 11, 2016, at 6:11 AM, Martin Thomson wrote:
>
> On 10 October 2016 at 20:24, Martin Rex wrote:
>> The description of the problem sounds vaguely familiar.
>>
>> https://www.ietf.org/mail-archive/web/dane/current/msg03737.html
>
> If only they had listened eh? And they went ahead and
On 10 October 2016 at 20:24, Martin Rex wrote:
> The description of the problem sounds vaguely familiar.
>
> https://www.ietf.org/mail-archive/web/dane/current/msg03737.html
If only they had listened eh? And they went ahead and published anyway.
I didn't do a complete search of mailing list arc
Martin Thomson wrote:
> Richard, ekr and I have submitted a draft describing UKS attacks on
> certain DANE usages:
>
> https://datatracker.ietf.org/doc/draft-barnes-dane-uks/
>
> The draft contains the details, but the short version is that usages 2
> and 3 are potentially vulnerable to an unkn
On 10 October 2016 at 15:35, Viktor Dukhovni wrote:
> For the record, in RFC7671, only DANE-EE(3) was in scope for skipping
> identity checks, no similar language is present for DANE-TA(2).
This is correct. The draft goes into this in more detail, and is more
correct than my short announcement w
On Mon, Oct 10, 2016 at 03:12:28PM +1100, Martin Thomson wrote:
> Richard, ekr and I have submitted a draft describing UKS attacks on
> certain DANE usages:
>
> https://datatracker.ietf.org/doc/draft-barnes-dane-uks/
>
> The draft contains the details, but the short version is that usages 2
>
12 matches
Mail list logo
