[Security] Reminder :: Draft feedback on "C2C authentication using TLS"

Peter Saint-Andre stpeter at stpeter.im
Sun Aug 31 19:15:26 CDT 2008


Overall it looks good. Thanks, Dirk!

Dirk Meyer wrote:
> Pavel Simerda wrote:
>> On Sun, 24 Aug 2008 20:59:22 +0200
>> Dirk Meyer <dmeyer at tzi.de> wrote:
>>
>>> Johansson Olle E wrote:
>>>> Could this functionality benefit from some sort of Disco support to
>>>> check what the other side supports, before setting up the
>>>> connection?
>> +1
>>
>>> You could put the stuff I added as <offer> to the disco stuff. But it
>>> must also work serverless. And when I work link-local I can not use
>>> disco#query before connecting.
>> I don't know much about link-local messaging but if it uses DNS (which
>> it does), it can use it for discovery. (I don't say it's good or bad.)
> 
> We could hook into the txt records and add the offer there.

Right. In link-local you don't have disco or caps before you try TLS, 
but these features can be put in txt records (see XEP-0174).

>> But then I would expect a real-world usecase with XML examples for
>> better understanding.
> 
> Yes, I know. But since all people on the list know what it is about I
> skiped that part. It will be added later.
> 
>> And it would be good to resolve the "SRP vs. SAS vs. whatever else"
>> issue or leave this possibility out of the spec before it's resolved
>> (so we aren't pushed by the developers to keep what we put there
>> already).
>>
>> A short paragraph about other possibilities to be included would do.
> 
> Agreed. The list in 'Requirements' is based on what is a RFC now. I
> should add a note that anything that can be used with TLS can also be
> used at this point. And if there will be SAS support in TLS it can be
> used. If a client does not support it, it can simple ignore the <sas>
> offer. So a note: 'ignore offers you do not know' and 'there can be
> more in the future' is needed.

Agreed.

>> Furthermore, it's important to hear from Peter Saint-Andre and maybe
>> others about the disco features and other interoperability issues.
> 
> Yes. If we can put the offer from starttls in the disco feature and
> use txt records, that would be nice to have. Or offer disco#query as
> feature before starttls. But the second offer in proceed can not be
> avoided since only at this point the receiver knows what it wants to
> support for that specific client based on what it can verify.

I think we worked out the disco+caps / txt-record issue -- advertise 
multiple disco features (not items).

BTW I think it's not only c2c, is it? In the future we might use e2e 
streams for things like encrypted MUCs (if you trust the groupchat 
service to securely hold a key -- perhaps a big if).

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080831/774db7dd/attachment.bin 


More information about the Security mailing list