[Security] Reminder :: Draft feedback on "C2C authentication using TLS"
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
>>> 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
>> 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.
>> 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).
-------------- next part --------------
A non-text attachment was scrubbed...
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