[Security] About the Firefox 3 Security Dialog & others

Hannes Tschofenig Hannes.Tschofenig at gmx.net
Sat Aug 23 14:25:41 CDT 2008


Thanks for the good summary.

I recall the problems in the SACRED and the EAP/EMU group  when they try 
to pick secure password based authentication mechanisms. There is still 
a lot of uncertainty about this subject as far as I can tell from the 
ongoing work on EMU.

Eric Rescorla wrote:
> I mentioned that in my original post on the topic, but sure, I'll mention it
> again. SRP is one of a broad class of password based key agreement
> (PAKE) protocols.
>
> 1. The general concept of a PAKE protocol was invented by Bellovin
>     and Merritt with EKE. EKE is patented.
> 2. Phoenix technologies holds a variety of patents on PAKE protocols.
> 3. Stanford has a patnet on SRP but they have agreed to royalty-free
>     terms.
>
> The relevant question is the extent to which the EKE and Phoenix
> patents apply to SRP. Advocates of SRP claim no but there is some
> question on this topic. There are also other PAKE protocols which claim
> to be unencumbered. On the other hand, nobody has volunteered to
> indemnify you.
>
>
>
> -Ekr
>
>
> On Sat, Aug 23, 2008 at 10:14 AM, Hannes Tschofenig
> <Hannes.Tschofenig at gmx.net> wrote:
>   
>> Should someone mention the IPR issues with SRP that prevented widespread
>> usage?
>>
>>
>>
>> Eric Rescorla wrote:
>>     
>>> On Sat, Aug 23, 2008 at 5:46 AM, Pedro Melo <melo at simplicidade.org> wrote:
>>>
>>>       
>>>> Hi,
>>>>
>>>> On Aug 23, 2008, at 1:18 PM, Jonathan Schleifer wrote:
>>>>
>>>>
>>>>         
>>>>> Am 23.08.2008 um 11:04 schrieb Dirk Meyer:
>>>>>
>>>>>
>>>>>           
>>>>>> SAS does not work for me when I use bots. It also reduces it to one
>>>>>> way removing the option of X.509 certificates which is something I
>>>>>> need.
>>>>>>
>>>>>>             
>>>>> I never said SAS should be the only way, we need multiple ways. I
>>>>> suggest
>>>>> those:
>>>>>
>>>>> * SAS with mnemonics
>>>>> * Fingerprint verification
>>>>> * CA, but no CA added in the client by default (so the user has to trust
>>>>> the CA manually, for example useful in a company so you don't have to
>>>>> verify
>>>>> every co-worker)
>>>>>
>>>>>           
>>>> Exactly. For bots, I personally would create my own CA and tell those
>>>> pesky
>>>> little devils just to trust certificates signed by that.
>>>>
>>>> Profit!.
>>>>
>>>>
>>>>
>>>>         
>>>>>>> Having a 32-bit SAS encoded with Mnemonics (like already suggested
>>>>>>> here) really sounds like a great idea.
>>>>>>>
>>>>>>>               
>>>>>> Why not encode a key fingerprint with Mnemonics? Looks like the same
>>>>>> to the user.
>>>>>>
>>>>>>             
>>>>> Only taking 32 bit of the fingerprint and using Mnemonics is insecure as
>>>>> this is easy to forge - we already discussed it here.
>>>>>
>>>>> BTW: It was argued a lot that ESessions misses a cryptanalysis, but if
>>>>> we
>>>>> are going to do extensions to TLS, we might need a cryptanalysis for
>>>>> this
>>>>> stuff too. TLS is useless if we add a verification method that is
>>>>> insecure.
>>>>>
>>>>>           
>>>> Well, SAS and SRP are IETF (draft?) extensions. SRP has more than 10
>>>> years
>>>> of field tests and debate (up to current SRP-6, I believe).
>>>>
>>>>         
>>> SRP isn't a draft. It's an RFC.
>>>
>>> I agree we would need to do an SAS extension to TLS if we wanted SAS
>>> and yes, that would need analysis. However, it's a relatively small
>>> piece of work compared to a whole new protocol.
>>>
>>> -Ekr
>>>
>>>       
>>     



More information about the Security mailing list