Re: [dane] [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd)

[Paul Wouters <[e-mail]>]

On Thu, 17 Nov 2011, Ondřej Surý wrote:

The -02 draft went out before I could respond to this....

> could you please drop this sentence from your draft?
>
>  For example, if public keys were obtained using [DANE] it
>  is appropriate to use DNSSEC to authenticate the public keys.
>
> I know that it's just an example, but I can see that this could
> lead to chaos and mayhem if the DANE protocol makes different
> assertion in the future.  So unless DANE protocol blooms into the
> RFC before your draft, please don't make any assumptions, thanks.

Though I see your point, I cannot really see any case where a TLS
implementation would obtain a public key from DNS without any PKIX
information and without any DNSSEC protection. In this case there is
not even the PKIX fallback information to go on, so regardless of what
DANE decides to do for "validatable PKIX", a TLS client MUST NOT use
a TLSA record containing just a public key if it did not authenticate
that data with DNSSEC.

Perhaps it can be reworded? But I think it is a valid security concern
to point out people should not just pluck spoofable TLSA records from
DNS and build a TLS trust relationship based on that. Even if DANE
decided to always mandata DNSSEC, I think it is a good reminder to
make that explicit in the Security Considerations here?

> And one minor nit, change
>
>   Some small embedded devices use the UDP based [CoAP], a specialized
>   constrained networks and nodes for machine-to-machine applications.
>
> to
>
>   Some small embedded devices use the UDP based Constrained Application
>   Protocol [CoAP], a specialized web transfer protocol for use with
>   constrained networks and nodes for machine-to-machine applications.
>
> or simpler
>
>   Some small embedded devices use the UDP based Constrained Application
>   Protocol [CoAP] for use with constrained networks and nodes for
>   machine-to-machine applications.
>
> for better readability.

Thanks. I've made the changes and the will be in the next draft.

Paul

> On 1. 11. 2011, at 7:21, Paul Wouters wrote:
>
>>
>> This is the new version of the draft incorporating the feedback from Quebec City
>> and the TLS list since then. It changes the draft from a new TLS extension to a
>> new Certificate Type for raw keys.
>>
>> It also merges in the unpublished draft material from Hannes Tschofenig
>> and Tero Kivinen <[e-mail]> whom had also been working on raw RSA
>> TLS keys for use with CoAP (eg devices with no real time clock where
>> PKIX validation cannot work)
>>
>> I did not yet change the draft ofrom individual submission to working group item,
>> as I was waiting for confirmation on the TLW WG list of the last Quebec City
>> meeting.
>>
>> http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01
>>
>> Paul
>>
>> ---------- Forwarded message ----------
>> Date: Mon, 31 Oct 2011 17:44:35
>> From: [e-mail]
>> Cc: [e-mail], [e-mail], [e-mail],
>>    [e-mail], [e-mail]
>> To: [e-mail]
>> Subject: New Version Notification for draft-wouters-tls-oob-pubkey-01.txt
>> X-Spam-Flag: NO
>>
>> A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been successfully submitted by Paul Wouters and posted to the IETF repository.
>>
>> Filename:	 draft-wouters-tls-oob-pubkey
>> Revision:	 01
>> Title:		 TLS out-of-band public key validation
>> Creation date:	 2011-10-31
>> WG ID:		 Individual Submission
>> Number of pages: 11
>>
>> Abstract:
>>   This document specifies a new TLS certificate type for exchanging raw
>>   public keys or their fingerprints in Transport Layer Security (TLS)
>>   and Datagram Transport Layer Security (DTLS) for use with out-of-band
>>   authentication.  Currently, TLS authentication can only occur via
>>   PKIX or OpenPGP certificates.  By specifying a minimum resource for
>>   raw public key exchange, implementations can use alternative
>>   authentication methods.
>>
>>   One such method is using DANE Resource Records secured by DNSSEC,
>>   Another use case is to provide authentication functionality when used
>>   with devices in a constrained environment that use whitelists and
>>   blacklists, as is the case with sensors and other embedded devices
>>   that are constrained by memory, computational, and communication
>>   limitations where the usage of PKIX is not feasible.
>>
>>   The new certificate type specified can also be used to reduce the
>>   latency of a TLS client that is already in possession of a validated
>>   public key of the TLS server before it starts a (non-resumed) TLS
>>   handshake.
>>
>>
>>
>>
>> The IETF Secretariat
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
> --
> Ondřej Surý
> vedoucí výzkumu/Head of R&D department
> -------------------------------------------
> CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
> Americka 23, 120 00 Praha 2, Czech Republic
> mailto:[e-mail]    http://nic.cz/
> tel:[phone]       fax:[phone]
> -------------------------------------------
>