Re: [Drip] Paul Wouters' No Objection on draft-ietf-drip-auth-47: (with COMMENT)

[Robert Moskowitz <[e-mail]>]

ASTM F3411 defined the Authentication messages but punted the actual 
content to others.  They did not / do not have the expertise to do 
this.  They DO show how an Internet-based validation service could work; 
but it has holes.

So Yes, it "fell" to the IETF to do the heavy lifting to make this 
available to the aviation community.

ASTM F3411-22a actually references the DRIP work (and Qualcomm's IEEE 
1609.2) as registered Authentication methods.  A year ago, I was 
consulting one EU cellular company on how they could get their approach 
approved by the F3411 experts.  Nothing has come from this.  I got the 
drift that senior management felt they would have to expose too much of 
their "secret sauce" to get approvals.  And no way to make billions on 
the effort.

With all due regard to others that have worked on trust for the UA 
Broadcast Remote ID, only the DRIP works is complete and open.  Here we 
have that open, peer review, that keeps us focused on all the nits.

Bob


On 2/16/24 09:03, Paul Wouters wrote:
> On Feb 15, 2024, at 06:09, [e-mail] wrote:
>> 
>>> I'm a little puzzled why this is an IETF document. It feels more like
>>> a [F3411]
>>> extension ?
>> [Med] The WG discussed that issues in "Explain why it makes sense to define an IETF extension to a scheme that is defined in an external body (ASTM)" (https://github.com/ietf-wg-drip/draft-ietf-drip-auth/issues/2) and the justification is recorded in the draft:
> It justifies why a standard and registry is needed. It does not really say why the IETF should be that body. I just noticed that the entire document is basically about non-ietf protocols.
>
>
>>> I understand transports being out of scope but not DNS security
>>> options? If
>>> pulling key material from DNS, I think one should call out DNSSEC, or
>>> even
>>> mandate it.
>>>
>> [Med] DNSSEC is called out in the sentence right after the one you quoted:
>>
>>    [drip-registries] is the main specification for DNS operations in
>>    DRIP and as such will specify DRIP usage of best common practices for
>>    security (such as [RFC9364]).
>>
>> Do you think mentioning of RFCs 4033, 4034, and 4035 is better than BCP 237?
> No, BCP237 is the right quote. But perhaps remove or reduce the sentence so it doesn’t exclude dns security options and then references something about dns security options ?
>
> Note that these were non-blocking comments. The authors are free to choose to take no further action on this.
>
> Paul
>